There are two typical scenarios in which you add an exception to a user input task. The initial form and the confirmation dialog. Below, both patterns in a one process model. I will describe the patterns, the issue, and the solution below.
Initial Form
To allow a user to initiate a process entering some data, you create a process model and an interface. Then you assign that interface as the Process Start Form. This way, the process will initiate as the user submits the interface. In case the user closes the browser, navigates away or clicks the top-right X to close a popup dialog, nothing happens.
Now, there are scenarios in which you cannot use the Process Start Form feature. You then add a User Input Task to the model and enable chaining to navigate the user directly to this interface as he initiates the process. The problem here is that you then have an active process instance, even if the user navigates away. This task will then be listed in the user’s task list.
To get rid of this task, you then add an exception, which works like a timeout. The issue here is, that you need to give the user enough time to fill out the form, but also want to keep the timeout as short as possible to prevent the task from showing up in the task list.
Confirmation Dialog
Appian will show a small “Action completed” after you submit a task. Every so often this is not enough, and you have to show a more sophisticated confirmation dialog. For example, to allow the user to navigate to a just created case record.
You then add a User Input Task using the same Exception pattern as for the Initial Form. This time you can keep the timeout shorter, but still risk the task to show up in the task list.
The Solution
Appian has a rarely used feature which is called Quick Tasks. Follow this link to the Appian documentation: https://docs.appian.com/suite/help/latest/Process_Model_Recipes.html#creating-a-quick-task
Background: When you create a Process Backed Record, Quick Tasks will be displayed as related actions in the record. They are not assigned, but initiated by a user any time.
The important detail is, that a Quick Task will never show up in a user’s task list, as it is not meant to be assigned. Make both tasks Quick Tasks as shown below.
This modification is also visible in the Process Model, indicated by a small icon.
As a result, you can relax the timeout period and do not have to worry about a confusing task showing up in the user’s task list.
I’ve added a confirmation form as a quick task to my process. And after that the process does not stop when it reaches an end node, as a new instance of the quick task gets activated immediately after a user completes the previous instance.
If I just add an exception as you describe, then the second instance is still activated and gets terminated after a specified timeout. But as I have some nodes to be run after user’s confirmation, the process model will try to run them again.
I’m thinking about adding a termination event to the end node, but not sure if it’s a good solution.
What would you advise?
I think that a confirmation dialog should be the end of the process and not have any follow up activity. I described this task to not have any option to submit it. I am not sure I understand which scenario you describe in your second sentence. In my mind there is no place for more than one instance.
I made it a last node before the end node. It stills activate a new instance of this task but it seems to be a nature of quick tasks. Though a user doesn’t see that task I can see it activated in the process model. When it runs out of time specified in task’s exception the process gets terminated. I could leave it like this probably, but in this process I’ll use a subprocess with a start form.
Thank you for a nice introduction of quick tasks with exceptions.
Got it. Make the end node a “Terminate” end node. It will then also stop the quick task.