Workflow User Task
A user task is used to model work that needs human input, interacting with the process using an iCM form. When the process execution arrives at a user task the execution pauses and waits for user input.
Products like Self Service and User Requests are used to display lists of tasks to the appropriate users. These groups and users are always defined as website users in iCM. Should an iCM user need to perform a task, they will need to have an associated site user created for them and linked via their "alias".
| Property | Description |
|---|---|
| ID | An optional unique ID for this element. The modeller will assign a random ID if left blank |
| Name | A name for the task - this will appear in site templates like Self Service and User Requests but will be overridden by the description |
| Description | An optional description for this element. The description can include process variables, see Process Variable Tokens and Expressions in the knowledge base for more information |
| Asynchronous | When execution reaches a task that has been marked as asynchronous the engine will commit the current transaction and schedule a background job to continue the process from the asynchronous task |
| Candidates | The users or groups eligible to claim this task (or have it directly assigned to them, see below). This lists excludes any users that have random GUID-type usernames generated by the site authentication service when users log into your site using an external provider - as there's no way of knowing who these users are from this menu there is little point in showing them. In general candidates should be assigned by group |
| iCM Form | A pop-up that allows you to select the iCM form that will be used to interact with this process |
| Due date | Either an ISO-8601 formatted date and time or an expression such as ${dateVariable}. Due dates are used when querying the workflow worker using the API and are displayed in versions 12 onwards of the Self Service templates |
| Priority | Used to order tasks when querying the workflow worker using the API |
Candidate Assignment
There are three options when defining candidates for tasks: assignee, candidate users and candidate groups.
Assignee
A single user can be selected as the assignee. If an assignee is present the task will be assigned directly to them, ignoring any values entered in either of the two candidate tabs. This option bypasses the "claimable tasks" stage of the various GOSS Self Service products.
Candidate Users and Groups
If there are no direct assignees selected, the user task will show up as a claimable task for all selected site users, or all site users who are members of the selected groups. Even if only a single eligible site user is selected as a candidate, unlike the assignee option, they will still need to claim the task before being able to take the required action. Once the task has been claimed it will be removed from the claimable task lists of other users.
Assignment Expressions
As well as selecting site groups and users from the available lists, it is also possible to define a candidate using an expression. A commonly used expression assigns a task back to the person who started the process instance, for example:
${initiator}
Where "initiator" is the standard process variable storing the name of the user that started the process instance. The name of this variable can be set in the start event of your model, but we don't recommend changing it.
Preventing Tasks from being Unclaimed
When a user claims a task, they become responsible for it - the task is assigned to them. The Self Service template allows users to manage the tasks currently assigned to them, claiming tasks from a list of tasks they are eligible to complete and unclaiming tasks previously claimed.
You might want to prevent a user from unclaiming a task once it has been claimed. This is especially true if a task only has one candidate.
To prevent a task from being unclaimed:
- Open the "Advanced" tab of the user task activity
- Click on "Task listeners"
- From the default behaviour drop-down select "Prevent Un-Claim"
- Press the plus icon, then save
If a task doesn't have any candidates - ie it only has an assignee - it will automatically prevent the assignee from unclaiming it. This is to prevent processes from being orphaned, where an assignee unclaims a task and there aren't any defined candidates to pick it up again.
Task Chaining
If a workflow model includes sequential user tasks which are carried out by the same user, it is possible to chain the tasks together, immediately displaying the form of the second task after the first has been submitted.
The same effect can be achieved by using a multi-page form, which is easier to implement and delivers much of the same functionality. Task chaining should generally only be used when workflows are more complex.
To enable chaining, open the "Advanced" tab of the user task activity you would like to chain to. Click on "Task listeners". From the default behaviour drop-down select "Allow Chaining" and press the plus icon, then save.
The task candidate must be an assignee rather than a candidate user or group. The Task Chaining reference article includes a working example that also shows how to assign a task to the user who completed the previous task.
Workflow chaining will not work if any activity between the two user tasks is marked as asynchronous. The user must only have one task assigned at a time, otherwise the engine won't know which one to chain to. Chaining cannot work if the second task needs to be claimed.
Auto-Claiming Tasks
In normal use tasks are either directly assigned to a user as the "assignee" or made available to a user or group of users by selecting them as potential "candidates". Candidates have to claim a task (either working in iCM or using one of the Self Service products), and then act upon it.
It is possible to set a task to be "auto-claimed". This still makes the task available to candidates, but removes the claiming step.
Typically auto-claim tasks are used in combination with a mail task. Potential candidates are emailed a link to complete the task (ie emailed a link to the appropriate task form), and whoever clicks on the link first will automatically have the task assigned to them. They are then able to complete the task form.
To enable auto-claiming, open the "Advanced" tab of the user task activity you would like to be auto-claimed. Click on "Task listeners". From the default behaviour drop-down select "Allow Auto-Claim" and press the plus icon, then save.
Candidate users should be emailed a link to an article using the Forms Service template. The link needs to include the business key of the workflow instance as a parameter, for example, http://www.mywebsite.com/myform?bk=${_businessKey}. When the form is displayed to the user they will only be able to carry out the task, and see any relevant information from the process, if they are an eligible candidate.
When a task can be auto-claimed you will often need to build in the ability for users to unclaim the task, or for it to return to a claimable state after a certain amount of time has elapsed.
The Linking Directly to Workflow Tasks reference article looks at auto-claiming in more detail.
