Cancelling parallel call activity instances via BPMN without blocking the parent process.

Hello,
I am working with a BPMN process in Camunda 7 where multiple instances of the same process are started in parallel using call activities (based on a dynamic list).

At runtime, a user may decide that one of the called process instances is no longer needed and should be cancelled from within the called process itself.

If a called process instance is cancelled externally (e.g. via admin), the parent process gets stuck, since it is waiting for all parallel call activity instances to complete before continuing.

I am not able to use engine-level APIs or custom code, so I am looking for a pure BPMN modeling solution that allows a called process to end early or be cancelled while still letting the parent process continue normally.

What BPMN patterns or modeling approaches are recommended for this scenario?

Hi @OUSSAMA_ELHADRAMI

Could you please share your model or a minimized version of it

You may consider, instead of Cancelling the process instance, terminating early, even through a specific End Event. This way the Call Activity will finish normally and the engine will be able to resume properly.

Hi @OUSSAMA_ELHADRAMI

Canceling a called process instance interrupts it abnormally, preventing token propagation from the call activity to the parallel join gateway

Add an event sub-process with an interrupting conditional start event: #{canceled} and end event

Admins can gracefully cancel a called instance by setting canceled=true via Cockpit, triggering normal completion and proper token flow

My initial thought was similar…

1 Like

Hello @hassang , @GotnOGuts

Thank you for your responses, i have found a workaround using an interrupting event subprocess and built a utility workflow that sends a message only to the subprocess we want to skip.

The reason for this approach is to give the process owner the ability to skip an unused subprocess without the need to contact support or a process administrator.

Additionally, the subprocess status is not always known at the start of the process. A user may decide, while the subprocess is already in progress, that it is no longer valid and needs to be cancelled. This is why I did not use a decision task as the first step

@OUSSAMA_ELHADRAMI

When only a process administrator can cancel the instance, a conditional event eliminates the need to build a utility service, since cancellation can be performed directly from the Cockpit app.