Relay provides a range of standard task templates. Each task template is built from components that provide process definitions and status rules. For performance and ease of navigation, all the components for a template are built into a single collection component.
This includes:
- Task which uses the Standard standalone collection.
- Collaboration - full which uses the Standard owner collection for the owner end of the task and the Standard partner collection for the partner end. It can also use the Standard shared chat partner collection for chat processes sent to the sharing partner.
- Collaboration - simple which uses the Standard simple collaboration owner collection for the owner end of the task and the Standard simple collaboration partner collection for the partner end. It can also use the Standard shared chat partner collection for chat processes sent to the sharing partner.
- Outline and Notes, both of which use the Standard info only collection.
- Group chat which uses the Standard group chat owner collection and uses the Standard shared chat partner collection for the partner end of the chat.
- Share which uses Standard data share owner collection to create a data sharing task. Partners use Share partner which uses Standard data share partner collection.
- Send which uses Standard send owner collection to create a task to send information to a partner. Partners use Send partner which uses Standard send partner collection.
See Selecting the right task type for a short user-focused guide on which task type to use.
Parts
The components that are combined into the collection components, and the processes and status rules in those components, have an informal naming convention of Mode Part Type, e.g. "Owner Notify Process" or "Partner Chat Status Rules". Where parts apply across different modes, the mode is omitted from the name.
Part | Description |
Common | Common to all processes. Includes initialise, consume of published messages, delete, reinitialise and redirect. |
Cancel | Standard cancel functionality. Kept out of common because some tasks might not need a cancel step. |
Init | Initialisation. This must come after common, because it overrides default steps defined in common. |
Collaboration | For owner and partner processes, additional steps for collaboration, such as assignment and sending. |
Send | For owner processes, send the process to the partner. This is separate from the Collaboration step because this is where the partner process is specified, and where it can be overridden. |
Validation | Validation of responses received from the partner. This overrides the auto-validation in the collaboration processes. |
Auto accept | For partner processes, automatically accept tasks when they are first sent. |
Auto assign | Attempts to assign the partner automatically, if it is not already assigned. |
Data | A trilogy of data handling components, that manage forms, provide access to data held in the task, and make data handling the default display action. |
Decline complete | For owner processes, set the task as complete if the partner declines. Use this when it would not make sense to send the task to someone else. |
Set response | For owner processes, provide a step that the partner can call to set the response, separate from a submit. |
Change template | Change the task template. This is implemented as group-level process with task-level status rules. |
New sub task | Create a new sub task. This is implemented as group-level process with task-level status rules. |
Reminder | Reminder processing. |
Hold | Hold/release processing. |
Request response | Adds handling of a request and a response, both of which are a block of text and optional attachments. |
Chat/Log | Adds chat functionality, or log functionality for the standalone process. |
Notify | Adds notifications. These work by listening to events and raising notifications as required. Notifications for chat and reminders are handled in their respective parts. |
Share | Adds share functionality, chat sharing in all the standard types. |
Send | Adds send functionality, i.e. a simplified collaboration partner just for receiving and optionally confirming data. |
WBS | Mainly a group-level component, but provides the Move functionality. |
Copy | Copy functionality, not used for partner processes. |
Resolved processes and status rules
Some of the collections are also used to create a resolved process and a resolved status rules node, which can be used to reference the entire resolved process or status rules (particulary when sending a partner process). This is now redundant because the worker templates will create resolved processes and status rules automatically.
These resolved items all have names based on the collection, suffixed with Process or Status Rules. So that resolved process for the Standard partner collection is Standard Partner Process, etc.