Hello team,
is there any best practice on how to auto-release a task which was accepted by somebody from a specific group after some time, lets say 1 hour. In my case i have a group called "Processors" which contains approx 50 users. When a task is assigned to this group the users accept a task a work on them. I want to ensure that when somebody from the group accept a task but not complete it in 1 hour it will be autoreleased and reassign back to the whole group so somebody else can take care of it.
Thanks
Discussion posts and replies are publicly visible
This can easily be done by configuring a task escalation with a timer. Did you already try that?
no not yet, i have no previous exprience with escalation. can you advise please?
The Appian documentation search bot at your service:
docs.appian.com/.../Process_Node_and_Smart_Service_Properties.html
docs.appian.com/.../Process_Model_Recipes.html
appreciate your help, thank you
Stefan do you think its possible to trigger an escalation only when the task was accepted? so is it possible to somewhere define such a condition? thanks
ladislavm0002 said:trigger an escalation only when the task was accepted?
I don't think it's possible to build this complexity into the task-internal escalation, but i've done this sort of thing manually using an "external" escalation in the past. Essentially simultaneously to launching the task, you launch a timer node, which upon expiration checks whether the task is accepted already (and also not completed yet), and if so, it uses the "reassign task" plug-in smart service to reassign the task (by ID) back to the initial group.
To do this of course you need to use Query Process Analytics and query into a report that gives task information for a process instance, both to get the task instance ID as well as the task's acceptance status.
I also strongly recommend you don't implement such a short timer that a user could be interrupted if they're mid-completion (imagine they're 90% done then wander away to get a coffee, then come back, do the last 10%, only to find it's been reassigned). When I've implemented this sort of thing, I make the reassignments occur overnight the next night, reducing the likelihood of this to approaching zero.