Workflows allow administrators to control the movement of data as well as define what data is displayed, where it’s displayed, and which users the data is displayed to through applications, activities, search results, data visualizations, and assignments. Workflows are often used for processes, but can also be used to mark or flag certain objects (e.g. moving a Vehicle object into a Stolen state or a Person object into a Deceased state). Each object type must have a workflow.
Workflows are comprised of the following elements and are created in the order outlined below:
- States: The various stages of the data collection process (e.g. Create, Triage, Review, Investigate, Close). You can create multiple states, but you must have at least two states in order to save an object. The Creation, Draft, Active, and Archived states are auto-created on every object type. When object types are added to roles, you must configure the workflow permissions for each state. Once created, workflow states can be used as variables in formulas and workflow conditions.
- Triggers: The act that prompts the movement of an object from one state to another once a trigger is activated, which appears as button on a configurable form (e.g. clicking Create on a new Incident will move the object from the Creation state to Triage). The state an object moves to is determined by the transition saved to the trigger. Triggers may also include orchestration events, which move multiple objects into other states.
- Transitions: Transitions are created on triggers and define the state the object will be moved to and any actions that will be taken (e.g. after a user clicks the Create trigger, the transition determines that the object is moved to the Triage state and an email notification is sent out to the managers who need to review it). You can create multiple transitions for each trigger.
- Conditions: Conditions are added to transitions and determine which workflow state an object is moved to depending on whether certain parameters, based on variables from fields, formulas, or states, have been met (e.g. if an incident is flagged as “Injury Occurred” you can specify that the object is sent to the HR state, while other incidents that aren’t flagged are moved through a standard triage workflow). You can also apply conditions to actions.
- Actions: Actions are added to transitions to allow administrators to add an automated process to an object as it moves through its workflow states. Actions include sending an email or assigning users within a selected role, clearing fields, roles, or relationships from an object, adding values to select list or date and time fields, orchestration events, which move multiple objects into other states, creating an object upon transition, or duplicating data across objects.
All new object types are saved with four auto-created states: Creation (the object’s entry state), Draft, Active, and Archived. You can’t delete the Creation state, but you can rename it and change or add additional triggers and transitions. You can edit or delete the other auto-created states, however, you must create another state for Creation to transition to.
Administrators can also create multiple workflows for object types that have been added to an assessment as dimensions. See Configure Assessment Workflows for more information.
| EXAMPLE |
| You need to create a number of states, triggers, and transitions to ensure the Incident object type goes through the proper data collection and review process. To start, you create two states: Submit for Review and In Review. On the Submit for Review state, you create the Submit for Review trigger (which is the button the user can click on the configurable form to move the object to the next state) and on that trigger, you create the Submit for Review transition with an In Review destination state. This means that when a user clicks on Submit for Review, the Incident object is automatically moved to the In Review state. |
The default workflow.
A custom workflow.