Skip task in flowable process and reach end state

I have a process that does Service Task 1 → User Task 1 → Service Task 2 → User Task 2 → and so on and finally reaches end state.
However, if the user abandons the flow mid-way, is there a way to reach an alternative end state so that we can later find the list of processes that were not completed by the user - for MIS purposes.
Thought of looking for open processes at the end of each hour but not clear how to move them to a pre-defined end state using an API. Could you please help

Hi Lakshmi,

If I understand you case correctly, I would prefer at least 2 end states (“regular” and “skipped”) based on the end state you can easily distinguish between “regular” and “skipped” process instances.

But to answer your question:

RuntimeService:

    /**
     * Create a {@link ChangeActivityStateBuilder}, that allows to set various options for changing the state of a process instance.
     */
    ChangeActivityStateBuilder createChangeActivityStateBuilder();

Regards
Martin

Many thanks Martin, will try out and update. And on the 2 end states, that will get us what we want. But not clear on how to model the flow.
So, the main process (simplified) would be
Start state → Service Task 1 → User Task 1 → Service Task 2 → User Task 2 → … and finally Regular end state
And just a standalone task ‘Skipped end state’ which will be transitioned to using the ChangeActivityStateBuilder if we find that a process has been abandoned by the end user - did I get that right please.

Exclusive gateway and based on the decision end the process.

Yes, but I do not recommend this approach.

Martin

I know you asked about moving the processes to an end state using an API but assuming there is a set amount of time that you want to allow for the user to complete each user task (i.e. you were going to check each hour) would boundary timers on the user tasks work for your use case? Ensure that the Cancel Activity is set on the timer so that the user task is cancelled. That way it would be “built-in” to your model as opposed to relying on an external process.

If you didn’t want to include a bunch of boundary timers on the individual tasks you might be able to wrap the various tasks in a sub-process scope and put a single timer on the sub-process. Though with that approach, the time it takes your service tasks to complete would also need to be taken into account.

And thanks for the tip about the ChangeActivityStateBuilder Martin. That will definitely come in handy at some point!