Tasks can either be standalone, run only by the owner or other people with permission on the group, or they can be collaborative in which case the owner sends the task to a partner for completion.
Collaborative process
Happy path
The "happy path" through which a collaborative task passes is illustrated by the following diagram. (This is only a high-level illustration, the executable process is much more complicated.)
- The owner initiates the task. They prepare it in the usual way, and then assign it to a partner.
- The assignment sends the task process to the partner. The partner reviews the task to determine if it is something they can do. Assuming that it is, they send an acceptance back to the owner.
- The owner indicates the task is ready.
- The partner starts the task and when it is complete they submit it to send it back to the owner.
- The owner validates the task and assuming it is OK marks it as finished.
- The partner process is marked as finished when the owner task is marked as finished.
Redo
During validation, the owner might decide that the task has not been completed satisfactorily. In this case, both the owner and partner end of the task are set to a redo phase. This is treated the same as in progress, and the partner must do more work and submit the work again for validation.
Timing of assignment
The happy path shows assignment taking place in a separate phase, before the owner marks the task as ready. Assignment could alternatively take place in a ready or wait phase. If the assignment takes place later, the appropriate status is shown to the partner as soon as they accept the task, i.e. the task may be in an assign, ready or wait state after the partner accepts the assignment.
Decline and refer
The partner may be unable or unwilling to do the task. In this case, they can decline the task, and the owner must assign the task to a different partner for it to be completed. Once declined, the task is retained in the partner's client but is treated as if it were cancelled and can be deleted from the partner account if required.
A refer is similar to a decline, but the partner suggest an alternative party for completing the task. Referrals are sent back to the partner, and may in some cases be automatically sent on to the referee.
A partner can decline or refer the task event after it has started, and in a redo state. In those cases, the owner process will revert to a ready state when the decline or refer is received.
Recall
The owner may need to stop the partner completing the task, either to cancel the task or to assign it to someone else. They may recall it at any time between assignment and completion. If it is recalled and has been started the phase is reverted to ready.
The recall acts a bit like a decline, but initiated from the owner end. The recall is treated like a cancel at the partner end. The owner can reassign a recalled task, or can cancel it.
Assignment status
There is a need to keep track of assignment activity independently of task phase and independently of worker status. The assignmentStatus property within the task data is used for this. This can be set to the following values.
| initial (or omitted) | Not assigned |
| assigned | Assigned, not yet sent. |
| ready | Send has been requested and the connection has been set up. |
| sent, received | Process sent to partner but partner has not yet reviewed it. This is shown as "received" at the partner end. |
| accepted | Assignment has been accepted by the partner. |
| declined | Assignment has been declined by the partner. |
| referred | Assignment has been declined by the partner, but the partner has suggested an alternative assignee. |
| recalled | Assignment has been recalled by the owner. |
| connectionRequired | Send has been requested and a connection request has been made to create a new connection. |
| connectionRequested | A connection request has been sent. |
| connectionDeclined | A connection request has been declined. This is different from declining the task once a connection has been made. |
All the assignment statuses except received are used by the owner. The partner uses received, accepted, declined, referred and recalled.
The assignment status is separate from the assignment phase. At the owner end, the assignment phase allows assignments to be managed prior to marking a task as ready, and at the partner end the assignment phase controls the acceptance or declination of the task. However, the assignment status may be set during other phases, too.
Worker status
The worker status is used to describe the status to the process and, through status rules, to control what menu options are available to the user. The status is conventionally split into a reference which controls menu options and a name which describes the status.
The worker status can be totally different from the task phases, but in most cases it makes sense to connect them.
In a standalone task, the phase can be used as the worker status, appending a Hold suffix if the hold indicator is set.
Collaborative tasks have the additional complexity of assignment status. A suggested approach is to use the assign phase as the status reference but to modify the status name to take account of the assignment status.
- Generally use the phase plus optional hold suffix.
- In the owner process:
- In assign phase, use a status reference of assign and set the status name to describe the assignment status.
- In the phases before assign (initial and prepare), suffix the status name with the assign status, but only if the assign status is not "initial" - i.e. show the assignment status if assignment has started.
- In the active phases after assign (wait, ready, progress, submit, redo), suffix the status name with the assign status, but only if the assign status is not "accept" - i.e. show the assignment status if assignment has not been accepted.
- In the partner process, if the phase is cancel, use status reference as cancel but set the status name according to the assignment status (which gives the reason for the cancel).
Because of the complexity of worker and assignment statuses, it is not feasible to present different assignment menu options for different assignment statuses. Instead, a single assignment action is provided by the task step type which can be used by the owner to assign or recall an task, or by the partner to accept, decline or refer a task.
Assignee selection
The assign task action allows the owner user to select a partner.
The partner is by default selected using a role of "partner*". The rules for selecting connections and group paths for the role are defined in Group Connections Script.
Connection request
The assign task action also allows an assignee to be identified by name and email address. This can be used by a suitably configured Request connection step type to request a connection for that person, creating an account and installing a portal product as required. See Connection requests for details.