BPM: Problems with "Conditional Intermediate Event (Boundary)" on multi-instance task

[hi-ko]

I have a Problem with Advance Pack 3.7.2 / EspoCRM 9.0.4 using a "Conditional Intermediate Event (Boundary)" event on a multi-instance sub-process:



My goal is to stop the multi-instance sup-process for review if a user selects in the review task "changes" as resolution.
In the sub-process a script task checks the user task's outcome and once the "resolution" is "changes" the entity property "status" is set to "changes"
I created a canceling "Conditional Intermediate Event (Boundary)" (Changes) which has the condition "status"="changes".

Once this event fires I have 2 issues:
* the event is not only cancelling the sub-process but also the main process. Then in a later "Send Message Task" fails with status 500 because the process already ended:
[2025-03-06 12:02:46] ERROR: (500) Attempted to continue flow of not active process 67c98ec68d02ef31e. :: /var/www/html/espocrm/custom/Espo/Modules/Advanced/Core/Bpmn/BpmnManager.php(892)
* If the "Conditional Intermediate Event (Boundary)" (Changes) fires, the multi-instance subprocess does not write the "Collection Return Variable", so I have no way to read the outcome in the main process. I tried to add a inclusive gateway to wait until the sub-process ended but it looks like the final logic to write the outcome into that collection variable does not run on a boundary event. At least this worked in a previous version.

Am I doing something wrong or are these bugs in the latest version of the Advance Pack?

Thanks for any help

[yuri]

> the event is not only cancelling the sub-process but also the main process. Then in a later "Send Message Task" fails with status 500 because the process already ended

Did it work before v3.7?

A minimum reproducible example would be very helpful. From the experience, I can say that it can take hours to reproduce without having a concrete min example.

[yuri]

> the multi-instance subprocess does not write the "Collection Return Variable",

Do you mean it's not available in the flow outgoing from the boundary event? I believe it never worked that way.

[yuri]

I'm also not sure whether it's correct to use the inclusive gateway. Maybe a parallel gateway is needed instead.

[yuri]

The converging inclusive gateway requires parallel flows to be active. If there's no two parallel flows in the moment one of the flows arrived to the gateway, it will fail by design.

[hi-ko]

Hey Yuri,
thanks a lot for your prompt response. I will create and attach a minimal example asap.
to your questions:

• The effect that the main process ends too early (probably due to the boundary event) is a new - even with the inclusive gateway. I added the inclusive gateway in the hope that we can wait for the multi-instance sub-flow to complete the variable collection.

• Do you mean it's not available in the flow outgoing from the boundary event? I believe it never worked that way.

  yes, that's what I mean. In another workflow we had at least access to "return variables" set in the multi-instance sub-flow.
  The use case is to run the review many times in parallel but to stop the sub-flow if any sub-instance chooses "changes" but then we need access to the "changes" details to inform the others. As a work around I could try to write to a variable in the parent process via script but I would prefer to always have access to the instance-collection from the parent process.

The bug would then still be that the parent process ends as soon as the boundary event fires. The parent process should continue until the end.
I'll try to isolate/reproduce that issue in a minimal workflow ...

[yuri]

It will be easier if we handle issues separately. Concentrating on a single issue in a moment.

I'd start with the parent process being stopped.

Did it start to happen only after upgrade? Did it work before?

[yuri]

I managed to reproduce the "Attempted to continue flow of not active process" error.

[yuri]

I found the reason. It interrupted the sub-process node before preparing nodes outgoing from a boundary event. From code, it seems as it was done intentionally. I changed the logic (execution order) for all boundary event types. Did some manual testing and run integration tests. Seems works. I'm going to make a release.

[hi-ko]

Hi yuri, thanks a lot for your prompt fix! Now the flow continues as expected.

Since return variables are not returned to the parent process for an subprocess which is interrupted by an boundary event:
do you have a tip/advice how to access the outcome of the review task inside the multi-instance sub-process from the main process?

[yuri]

Using an entity to store needed data could work.

[hi-ko]

That's what I ended up for now. I write in a hidden entity text field in the sub-flow task and then read that in a later in a script task of the parent flow into variables to have them available in email templates.

My suggestions for improvement would be:

• access the variables of a subflow via a script or always expose return variables / return collection variables as a finally method before continuing
• pass flow's linked entity into the context when executing an email template in an email task (currently I read all required entity data required in the template into flow variables).