Process triggering on Task Accept

@aksharc As of now Appian hasn't provided us with the capability of capturing the events in the SAIL Form such as 'Save Changes', 'Reassign Task', 'Accept', 'Reject', 'Return to Original Assignees' etc. I don't think that's possible.Would you be able to explain the use case though?

One way is, you can trigger a process as soon as the task is assigned(using the escalation) and hold the process execution for a while. Query the status of the task using a!queryProcessAnalytics for every few minutes/seconds using the timer. When the status of the task changes, make the process proceed further. Problem is that this kind of processing is expensive and also it may not be reliable as there is a chance of submitting the task within the window which the status is being checked.

What we have discussed might not apply in the case of a single user assignee and you might directly trigger a process as the status of the task turns accepted(I might be wrong,but check this if needed) if the task is assigned directly to a user.

@sikhivahans: Thanks for the response.

Use Case: Our main process will need to send task information (who accepted the task, at what time the task was accepted) to an external system. This system uses OAuth for authentication. So, the communication happens with the valid session ID. I was also told that using the same session ID (until it expires) would be the best practice. So, I designed a process (login_process) that saves the session ID in Appian constant and uses that until it expires. On expiry it will queue the requests by the time it gets the new session ID. I was looking for a way to initiate the login_process from the task form on accept so that I can make use of the queuing mechanism I have already designed.

I already considered the options you provided and because of the expensive nature of them it is best not to go for that. Also, all of the tasks of the main process would be assigned to a user group only. So, user has to accept the task before starting to work on it.

@aksharc -

I have a approach in mind which might fulfill this requirement of yours.
You can have an exception configured in the User Input Task which will get triggered when tp!owner gets initialized.

Or in the same process model you can have another flow parallel to this User Input Task. Prior to this you can create a task report where in you can pass the task id if the User Input Task and check whether anybody accepted the task or not.

Once you determine that whehter the task was accepted or not using any of the above method, then you can use a!startprocess or use sub-process to trigger another process.

Hope the information was useful.

I am not sure how far the above-mentioned approach works and here are a few points re it:

1. Here the use case is to know whether the task has been accepted and initiate a new process accordingly. Whereas the Exception terminates the current task and choses a alternate path and this defies the requirement. Also, this termination will result in an error being displayed to the User on the SAIL form stating that 'This task is no longer active or valid' and the process continues further skipping the current user input task.

2. Even if the parallel flow is created, there is no guarantee that the user input task id is received. What happens when the user input task isn't initiated because of an error or if the parallel flow isn't initiated because of an error? I doubt the reliability here as this may fail in some cases. I believe the origination point should be the User Input Task and it is very much possible by making use of the Escalation.

3. Even to determine the task status in the parallel, we mostly require timer here as we need to monitor task status at certain intervals as it is changeable at any point in time and this can't be a one-time check.

4. tp!owner is not a property that is available(and off-course can't be monitored) in the User Input Task. Afaik, first of all, we lack the possibility of getting a task id(or tp!id) now in the Escalations or Exceptions of the User Input Task and that's how User Input Task is designed. Just to get Task id, either we need to depend on a!queryProcessAnalytics/Shared Components that gets the task from process id or a combination of process id and task uuid or a combination of process id and task name.

@aksharc Unfortunately, we can't associate anything with the events on the SAIL Form which we have discussed above. We could follow some other alternate approaches on the form which but again these are not user-friendly, are associated with some extra efforts, slightly deviates from Appian OOTB behavior and requires educating the user:
1. Have a replica of the task in read-only mode with a question on the form which captures the user acceptance. This task should be assigned to Group as usual. Once if the user accepts the task and submits the form, a new task(current task but in editable mode) will be assigned to him/her and at the same time you can also initiate the process.
2. Also, block the Reassignment privilege and make sure that it is handled from the interface only for these particular tasks. This way you can keep track of the acceptance afresh in the case of reassignment which is otherwise not possible.

Let's see if any other practitioners have got an elegant solution.

Thanks Sikhivahan and Sidhant for your inputs. I came up with the solution (below):

(1) Create a Web API which will initiate the process of that process model.
(2) Use the httppost method (available in 'Send HTTP Request Plug-in' shared component) in the task form. (Use the httppost in the value attribute of textField and have a mechanism so that it doesn't get evaluated every time form is refreshed after task is accepted - so it will be evaluated once when the task is initially accepted).

Let me know if this is not a very good idea.

@aksharc It doesn't sound bad. But as I am not much familiar with the integrations, I would like to leave it with the community here to pick up any loopholes in your thought process.