When using the batch modification feature it is not possible to define that only specific activity instances of the process instances to modify should be canceled. This leads to the situation where it is not possible to go back in a process, for example in case of the "invoice" process we want to execute the modification instructions:

1. start before activity Assign Approver Group
2. cancel activity Approve Invoice

Then for a process instance to modify the following happens:

1. The start before activity instruction is executed -> a new "token" is created in the activity Assign Approver Group.
2. This activity is executed synchronously. The token move on to activity Approve Invoice
3. The second instruction is executed: all tokens in Approve Invoice (including the freshly created ones) are canceled.
4. As there are no remaining tokens in the process instance, it is "finished".

To avoid such a situation, there should be a flag cancelCurrentActiveActivityInstances (the name of the flag can be different ) which can be set when a cancellation instruction is provided. When the flag is set true, then before any of the modification instructions is applied, a lookup happens, to get all current active activity instances (for the activity to cancel). Then the cancellation only cancel all the previously fetched activity instances.
If the flag is not set (= false), then no lookup happens, and all activity instance for the given activity are canceled.