Workflow
- Chris Jones
- Thomas Legowo
- 1 Overview
- 2 Implementation specifics
- 2.1 User action
- 2.2 Approval
- 2.3 Scriptable Activity
- 2.3.1 Script context
- 2.4 Scriptable Async Activity
- 2.4.1 Script context
- 3 Execution
- 3.1 Order
Overview
Servicely provides the ability to create complex custom workflows.
Activity Type | Icon | Description |
|---|---|---|
Comment | 
| Allows the placing of comments onto Workflows |
User Action | 
| Represents a status and a set of actions that are to be made available to users. Typically used to present a set of options to the user when the workflow is at a point where there are manual actions or decisions that must be made by the user. Available actions will be presented to the user on the form to allow the user to advance the workflow. |
Approval | 
| Allows approval steps to be added to a workflow. |
Complete | 
| Represents the end/completion of a workflow. |
Scriptable | 
| Provides the ability to run a custom script as part of the workflow. Designed to be a synchronous script that executes once per pass. Does not generate a Workflow Status by default, as the workflow does not pause here. |
Scriptable Async | 
| Provides the ability to run a custom script as part of the workflow. Designed to be used when the action is asynchronous (e.g. triggering an integration or awaiting other tickets/actions). Generates a Workflow Status so the associated record indicates the wait state. |
Timer | 
| Allows a timer to be scheduled to progress the ticket (e.g. could be used for auto closure or any other time based progression). |
If/Else | 
| Provides the ability to branch the workflow based on a simple conditional query. |
Switch | 
| Provides the ability to branch the workflow based on a custom script. Designed to be a synchronous script that executes once per pass. Does not generate a Workflow Status by default, as the workflow does not pause here. |
Switch Async | 
| Provides the ability to branch the workflow based on a custom script. Designed to be used when the action is asynchronous (e.g. triggering an integration or awaiting other tickets/actions). Generates a Workflow Status so the associated record indicates the wait state. |
Run Action | 
| Provides the ability to Run an Intelligent Action. |
Exception | 
| Provides the ability to respond to an exception anywhere in the workflow. |
Implementation specifics
User action
The User Action workflow activity provides the ability for end users to control the workflow, by presenting the the user with multiple options to progress the workflow status.
Adding transition options
Press the ‘Add new transition’ button, an enter the new transition name:
A transition can run a Before script for purposes such as making a field to be mandatory before the status transition can take place. An example is, to make the Assignee field on Incident table before moving the Incident off from New to Work in Progress status.
You would code something like below:
You will need to end the Before script with a return true; statement, so that the rest of the form checks can run to completion.
Linking to next activity
Drag from the circle in the Transition to the left most corner of the target workflow activity.
Approval
This activity requests approvals and will stop the records running the workflow from proceeding any further.
What you can configure:
Item | Description | Example |
|---|---|---|
Approval Mechanism section | ||
Approval requirement | Whether this approval step only requires one or more approvers to approve before the associated record can proceed to the next step of the approvals. Options are:
| One approval required |
Approval requirement script | Appears when “Approval requirement” is set as “Scripted”. This is to handle more complex scenarios that the other 3 approval requirement types cannot. The script needs to return the answer variable, a value of true indicates an approval while a value of false is for a rejection |
|
Complete on first rejection | Appears when the “Approval requirement” is set as “One approval required” or “Percentage of approvals required”. If set to Yes, this will move the workflow to the next step on first rejection. | Yes |
Force Comment | If set to Yes, both approval and rejection reasons will ask for comment | No |
Approvers section | ||
Assignees | Users that will be requested to approve |
|
Groups | Groups whose members will be requested to approve |
|
Advanced approval | Set to Yes if the approver list is not static, e.g. approver should be ticket’s requestor’s manager | Yes |
Business logic | Appears when “Advanced approval” is set to Yes. This needs a script and should return a queried Table record object. More information on Table record, please view Table API (Server) | When approvers are members of a group whose ID is defined in an Application Property. let approverArr = Table("Group").get(ApplicationPropertyManager.getProperty("change.approval.cab_group_id")).relation("Member").map(approver => approver.Id());
if (approverArr.length !== 0) {
Table("User").IN("id", approverArr).map(r => r);
}
When approver is a manager selected in a catalog item. if (current.questions().EOManager.hasValue()) {
Table("User").EQUAL("id", current.questions().EOManager.value()).map(r => r);
} |
Approve if no assignees | If set to Yes, the approval will be automatically approved if no one is found to be the approvers. Otherwise the approval will be rejected. | No |
Templating section | ||
Subject | Used in forms and notifications to describe the purpose of the approval | CAB approval |
Instructions | Used in forms and notifications to provide instructions to the user about the purpose of the approval | Approve/reject once CAB meeting had been held |
Scriptable Activity
The ‘Scriptable’ activity allows the Workflow author to run arbitrary code. This activity is typically transient and does not have a Workflow status associated with the Activity.
Script context
The ‘Scriptable Activity’ receives the following script context items:
Item | Description |
|---|---|
| A TableRecord object representing the object associated with the Workflow |
| A plain JSON Map object which can be used to store state associated with the Workflow |
| A Script Logger that allows logs to be written to the WorkflowHistory log |
Scriptable Async Activity
The ‘Scriptable Async’ activity allows the Workflow author to run arbitrary code. Usage is similar to the ‘Scriptable Activity’ with the primary difference being that this activity is designed to be used when the result of the script is asynchronous (i.e. the activity needs to wait on something external happening). This activity creates an associated Workflow Status.
The Scriptable Async activity exposes two scripts: an Initialization Script and an Evaluation script.
The initialization script is called once when the Activity is initiated, and is designed to be used to perform any initialization associated with the activity (initiate an integration, raise subtasks, etc.).
The evaluation script is called asynchronously to determine whether the activity has completed. This needs to be performed by an external action (e.g. on completion of an integration). A convenience method is available to automatically evaluate paused workflows for related tickets (e.g. for subtasks or other related information).
Table Property | Description | Example |
|---|---|---|
workflow.trigger.parent.field | A Table property that specifies a relationship that will trigger an asynchronous workflow evaluation of the related record. Can also be a comma delimited list of relationships.
| On the HRCaseTask table, specifying the value “ParentHRCase” will enable the evaluation of the Workflow related to HRCase records. |
Script context
The ‘Scriptable Async Activity’ receives the following script context items:
Item | Description |
|---|---|
| A TableRecord object representing the object associated with the Workflow |
| A plain JSON Map object which can be used to store state associated with the Workflow |
| A Script Logger that allows logs to be written to the WorkflowHistory log |
| Constants used for the return value or other items within the script. Scriptable Async Actions that have not yet completed their requirements should return the value: Scriptable Async Actions that have completed their requirements should return |
Execution
Order
When there are multiple workflows for the same table, e.g. ITSM Request table having multiple workflows for different catalog items, please ensure that they are ordered accordingly. This is necessary for the use case where the workflow is attached to the table not because of service catalog, e.g. raising ITSM Request directly. When a record such as ITSM Request is directly created, Servicely will select the Workflow with lowest Order number. This means a workflow with Order of 10 will take precedence over the one with Order of 20.
Related content
Servicely Documentation