Create the parent workflow object
[POST] /workflows
{
"name": "Ariella API -- Alarm Response (HQ)",
"details": "",
"type": "DISPATCH",
"isGlobal": true,
"region": 2,
"status": "ACTIVE"
}
Result:
Adding Workflow Statuses
You can POST each of the Workflow Statuses that will be a part of the workflow:
[POST] /workflow-statuses
{
"name": "AB API - New Alarm",
"tag": "abapinew",
"workflow": 28,
"formatBackgroundColor": "RED",
"formatTextColor": "WHITE",
"warningThresholdInMinutes": 5,
"alertThresholdInMinutes": 15,
"showTimestampInReports": true
}
Result in the web portal:
NB: we haven’t yet defined the transitions yet so there are no arrows showing order.
Mapping your integration to workflow-statuses : use the tag
If you want to map your integration to the workflow statuses when following the progression of a Dispatch Task via its Workflow, as workflow-instance-logs records, it's best to map on the "tag" key, and not the "name". The name is for the user journey and TrackTik application UIs. The tag key is meant to be used as a unique code and is more likely to remain stable during everyday administration.
Creating Workflow Transitions (order of flow steps)
When defining the order that Workflow steps transition, you need to identify the FROM and TO ID numbers of the workflow-statuses created above, in the order you’d like them to executive once deployed. In the example below is a transition from New Alarm to Assigned:
[POST] /workflow-status-transitions
{
"event": "AB_API_Assigned",
"eventLabel": "Assigned",
"fromStatus":176,
"toStatus": 177
}
NB: the “event” must be a Unique ID. It’s what is used when using Workflow transition actions via API.
Result:
The Assigned Workflow step now comes AFTER that of New Alarm in the web application: