In reply to: Maksymilian Stachowiak
Thank you for the ideas!
I'm much more in favor of the 2nd one, as it scales better, no limit for the size of the group, although it tricked my brain into thinking that it could be also possible to achieve without any additional forms, just an SQL statement should do the job too.
We're able to fetch the tasks that are assigned from WFTasks, and search tasks just for specific process/workflow/form, by joining with WFElements, WFDocTypes, WFSteps, WorkFlows.
The order of assigning the tasks would be alphabetical, so i can just go with give me the last person from group x, who had a task in step y. This gives me the position to who should get the task next 🤔
Although by implementing it this way would require that there is only one path assigning the task, so the order won't get messed up.
Hi,
nice idea too with SQL.
But how do you link user groups to different steps? Do you really want to define this statically in the SQL query? It’s not that nice having to change such things (in the case of new workfkows, steps) in the Studio instead of the portal, is it?
Or do you want to read out the assignees of the task of the step with SQL too without manual definition?
If you have multiple paths entering one step you could check if there already has been a task created in this step if the instance and if yes assign the same user and if not use your round robin, couldn’t you?
And what if you don’t want a static alphabetical order? You would need a kind of switch to have different cases in the SQL query.
I’m looking forward to your solution. 😉
Kind regards
Sébastien
13.04.2026
13:55
