Hi everyone,
I’m working on a BPMN process in Camunda 8 where I use a parallel gateway followed by multiple user tasks. On the front end, the user is presented with these parallel paths and can choose one of them to continue.
What I want to achieve is:
When the user selects a specific path — say path A — I want to ensure that the following user tasks shown to the user are only from that same path A, not from other parallel branches.
However, when I use the /v1/tasks/search API from Tasklist, it returns all active user tasks for the user, regardless of the path. I’m looking for a way to differentiate the user tasks from different paths.
So far, the only workaround I’ve found is using input mappings to set some sort of flag (e.g., "path": "A") on each user task and then filter by this in my application logic. But this feels a bit hacky and I’m wondering:
- Is there a better or cleaner way to tag tasks based on which path they’re in?
- Can I use custom headers, input/output mappings, or maybe extension elements to make this more manageable?
- Has anyone faced a similar scenario?
Any guidance or best practices would be really appreciated!
Hi @Hassan_Mohseni,
Could you clarify a bit more what exactly you’re trying to achieve? You mentioned that the user selects a path. Regarding this, I’m wondering if the tasks from the other paths are still relevant later in the process.
If not, maybe an event-based gateway could help. It would wait for the user’s selection, and depending on the path chosen, trigger only the corresponding user task(s). As an effect, your api-call would only return one and not multiple user-tasks.
However, this means only one path will continue, not all — unlike with a parallel gateway, which always activates all paths.
That’s why it would be helpful to know:
- Should the tasks from the unchosen paths still be available later?
- Or is it really just one path that matters, based on the user choice?
If you could share more details or a screenshot of your process, it might be easier for me to help.
Kind regards,
Marco
1 Like
Thank you for your response.
For example, this is the process I’m working with: the scenario is that the user sees two parallel paths and can choose either path A or path D.
Now, let’s assume the user selects and completes user task A-A (from path A). After that, I want to guide the user to the next active user task in the same path, which is user task A-B.
However, when I use the Tasklist Search API, it returns two active user tasks: one is A-B (from path A), and the other is D-A (from path D).
What I’m looking for is a way to filter or identify the correct task — in this case, A-B — based on the path the user previously selected (path A). Also, at any point, the user should be able to exit the current user task and reselect between path A or path D if needed.
Okay, in this case, I believe we have a limiting factor in your requirement to “always switch to another path”.
We could model that with an event-based gateway as well — for instance, using interrupting boundary events that lead back to the path decision. However, when I look at the resulting model, I’m not sure if I would do this because of the model complexity that would result in.
Furthermore, I am not a big fan of controlling the behavior of an UI heavily through a process—and I would feel that I am doing so here (however, that is a very subjective opinion - so don’t let it influence you too much 
).
Therefore, I would also see an opportunity in a solution where we configure the tasks with variables holding information about the path, and then we just query the tasks with the respective value - which is what you’ve suggested in your initial message.
Without investing more time and gaining more knowledge about the business use case, I can’t think of any other solution at the moment – but maybe someone else from the community has one 
However, In the end, it’s hard to say what the best solution is. As always, the answer is: it depends. Every option has pros and cons, so you’ll need to assess what fits your situation best and which trade-offs you’re willing to accept in exchange for certain benefits.
Some helpful questions to ask might be:
-
Is the idea of modeling different paths technically motivated, or are the tasks truly different in terms of business logic?
-
Does the process really end after “A-B” and “D-A,” or are there follow-up tasks that need to happen regardless of the chosen path? If so, you may need a merging gateway.
-
Have you considered rollback scenarios when a user cancels a task (as shown in the screenshot)? For example, if a user cancels at task “A-B,” do we need to undo something from “A-A”? And if yes, is that worth modeling due to business impact or the need to orchestrate it?
I would probably model it something like the following.
Remember that Gateways aren’t actually a selection or choice. They simply evaluate data and take the appropriate path(s). Similar to how when you’re driving, you don’t want to get to an intersection and then decide where you’re going… you want to plan where you’re going to go, and when you get to the intersection – follow the route you planned.
1 Like
Really like this suggestion. Shame on me, I did not take that into account Probably thought too technically at this point However, after a little thought, it seems like the most natural solution to me 
From a technical point of view, it also results in only user tasks from one path being instantiated (assuming the user can only select one). As an effect, the api will only return one UserTask.
And from a business perspective, it models the decision as what it most probably is based on your description: A task performed by the user, instead of an event we wait for.
All in all, this suggestion results in less model complexity. Furthermore, it leaves more room for, e.g. an (easier) automation of the path selection using service tasks or DMN. And it‘s still working with a boundary event for the restart of the path selection - as in the example of the event-based gateway.
The only question I’m asking myself when looking at your suggestion is (in case you did this on a specific purpose, other than keeping the example broader, to support a scenario, in which the user could also select multiple paths at once): why would you model it using an inclusive gateway and not an XOR gateway?
I might have misread the initial request, but it sounded like a user could select more than one path. If we don’t know how many paths could be taken, then an exclusive gateway wouldn’t be appropriate. If we assume that a user could take less than all the paths, then a parallel gateway wouldn’t be appropriate. That leaves the easiest one to model as the inclusive.
