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
}2023-01-30 The API documentation says that you can set these values: slaAction, chargeAction, cancelAction, but you can’t.
If you try an integer to point to an element in a list of enums, it fails.
If you try to define the string value of the enum like "slaAction": "NOT_SET" it also fails.
For now, leave these empty and use the web application to set them.
Result in the web portal:
NB: we haven’t yet defined the transitions yet so there are no arrows showing order.
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: