Get task assignee status inside the running process

Hi All,

Thanks in advance.

In this sample process , the task is assigned to group . How to get the status of task  and once accepted by a member .Is it possible to   get the assignment status ,assigned to and the task id in the script task or any other component inside the same process down the line (Even before completion of task) . Is there any trigger event available in Input task so that I can use to update the table ? it can be separate process flow. How to do this ? Any idea is really helpful.   

Rajesh

  Discussion posts and replies are publicly visible

Parents
  •  

    How to get the status of task and once accepted by a member? - This isn't possible until and unless you write a process that polls Analytics frequently.


    Is it possible to get the assignment status, assigned to and the task id in the script task or any other component inside the same process down the line (Even before completion of task)? Yes it is possible, as said above, wait for few seconds and then try to fetch the task attributes. I would suggest not to rely on this kind of mechanisms for executing any crucial business processes as this isn't 100% accurate - What if the task cancels by exception?

    Is there any trigger event available in Input task so that I can use to update the table? - No such trigger events available in Appian as of now.


    How to do this? - Here are some ideas:

    Option 1: Rely on Analytics. If you need the data in reports, get data from analytics as long as the task is active. (Any attempt to replicate this would be re-writing the reporting behaviour of Appian IMO.) Once when the task is completed, push the data to database and report on it if needed.

    Option 2: Create a task and assign to the group. And have a button on the task which indicates that the work is going to start and once when this button is clicked, go to a new user input task and assign it to the user who actually finished the group task. In this way, you can also easily record in DB. If the user who accepted the task is interested in re-assigning or rejecting the task, have the buttons on the new task which will route the flow back to the original task. Disable the Reassign/Reject privileges on the tasks.

    I would prefer option 1 as the workarounds such as option 2 sound really weird and aren't 100% accurate or fool-proof.

Reply
  •  

    How to get the status of task and once accepted by a member? - This isn't possible until and unless you write a process that polls Analytics frequently.


    Is it possible to get the assignment status, assigned to and the task id in the script task or any other component inside the same process down the line (Even before completion of task)? Yes it is possible, as said above, wait for few seconds and then try to fetch the task attributes. I would suggest not to rely on this kind of mechanisms for executing any crucial business processes as this isn't 100% accurate - What if the task cancels by exception?

    Is there any trigger event available in Input task so that I can use to update the table? - No such trigger events available in Appian as of now.


    How to do this? - Here are some ideas:

    Option 1: Rely on Analytics. If you need the data in reports, get data from analytics as long as the task is active. (Any attempt to replicate this would be re-writing the reporting behaviour of Appian IMO.) Once when the task is completed, push the data to database and report on it if needed.

    Option 2: Create a task and assign to the group. And have a button on the task which indicates that the work is going to start and once when this button is clicked, go to a new user input task and assign it to the user who actually finished the group task. In this way, you can also easily record in DB. If the user who accepted the task is interested in re-assigning or rejecting the task, have the buttons on the new task which will route the flow back to the original task. Disable the Reassign/Reject privileges on the tasks.

    I would prefer option 1 as the workarounds such as option 2 sound really weird and aren't 100% accurate or fool-proof.

Children
No Data