BpmnError context in ErrorBoundaryEvent

We would like to model a generic error handling for BPMN errors. Each of our tasks can throw BPMN error with different error code and error message. Then we would like to have generic boundary error event, which catches all BPMN errors (without filled errorCode).

Our boundary event successfully catches all error code. Unfortunately we haven’t found a way how to access the BPMN error context in error handling.

How can we get the error code and error message that we caught in error handling? We try to avoid having numerous specific boundary error events, so we can keep the error handling generic.

Thank you,

1 Like

Afaics in the code, that’s currently not possible. A boundary event without error code will catch any error … but that information is lost once the boundary event is triggered (here: https://github.com/flowable/flowable-engine/blob/master/modules/flowable-engine/src/main/java/org/flowable/engine/impl/bpmn/helper/ErrorPropagation.java#L234)

I like the use case, it’s a useful thing to have :slight_smile:

I guess the most flexible way would be to store the errorId (the errorCode can be looked up from the BpmnModel) in a variable?

That would need some extra attributed on the errorEventDefinition which normally is defined like

<boundaryEvent ... >
  <errorEventDefinition errorRef="errorId"  />


  • storeErrorVariable (by default false, for backwards compatibility)
  • errorVariableName (by default it would use the id of the eventDefinition or parent construct and adding .errorId or something
  • errorVariableTransient (by default true, as it’s probably going to be used in an exclusive gw after the event)
  • errorVariableScope (local or global, for setting is execution local or not)

wdyt? Would that cover your use case?

We are facing the same problem, and yes this solution can cover our use case

There is no workaround ?


Hello, I’m sorry to take up this old conversation, but is there something new about this aspect? Someone has provided some workaround for it?


No this is not implemented yet.
The workaround for now would be to override the default error boundary event behaviour class. If it’s needed by more users then we can definitely raise the priority of this. It would already help to create a Github issue so we can discuss it a bit more and track progress.

Best regards,


1 Like

I see.
Just for my own understanding, do you think it is tricky the implementation which enables the error context to pass through the boundary event or is there another motivation to avoid the bpmn error propagation?


No, I don’t think the implementation of passing the error context should be tricky. It’s a good feature for the Flowable Engine and definitely makes working with BPMN errors more powerful.

Best regards,


1 Like

I am more than interested to see this feature implemented. It would really make error handling a lot easier.
So, I’m wondering if I can create a github issue and offer my contribution by implementing it as @joram proposed?

Best regards,

Hey @bpran,

We are always happy to receive contributions from the community. You don’t have to create an issue though. You can work on an implementation and then open a PR where we can talk about it.


Ok. Thanks. Will do that!

Best Regards

We has this feature been implemented, we would like to use the error context in bnmperror to build our error workflow from generic exceptions


No, it hasn’t been implemented. It’s still would be a very nice feature to have … :slight_smile:

Seems like this has been worked on, at least partly:

Leaving this as a reference here, as I find the use case interesting and valuable too.

Verified it works with a simple model:

Test Case passes

The startEvent of the eventSubProcess just needs the attribute to store the BPMN Error code in a variable:

 <startEvent id="startErrorEvent1" isInterrupting="true">
        <errorEventDefinition flowable:errorVariableName="error_code"></errorEventDefinition>

There are also flowable:errorVariableTransient="true|false" and flowable:errorVariableLocalScope="true|false"attributes available.