Triggers

Triggers define how the workflow should be run – manually or automatically. Both options can be selected together as well.

• Manually: If you select manually, then the workflow can be run from the "Run Workflow" option under the "More" dropdown button on the incident details page.
• Automatically: If you select automatically, then you will be prompted to also select the events after which it will be run:
  • After an incident is created
  • After an incident is acknowledged
  • After the urgency is amended

Workflow

The actual workflow is almost like a computer program. You tell it what to do directly or you can tell it what to do if certain conditions are met. There are two basic statements available:

• Action statement to define the action to perform.
• If/Else statement to define what to do if some conditions are met and what else to do otherwise. They can be nested inside other If/Else statements along with Action statements.

These two statements give users the flexibility needed to define any type of workflow. We have put together an example to help you understand how Action statements and If/Else Statements can be combined to form an execution chain.

In the above example, there are two main steps, where the second step is conditional and contains multiple options and sub-actions. The instructions are executed as explained below:

1. Add a note.
2. The second step is conditional. If the Payload Field source_payload.key equals datadog-eu, then
   1. Run the custom action Restart EU Server.
   2. If the server is restarted successfully and responds with a HTTP status of 200, then resolve the incident. Otherwise,
      1. Add more responders to the incident.
      2. Post a status update.
      3. Add a conference bridge.

If/Else Statements

If/Else statements consist of three parts – (IF) if conditions, (THEN) actions to take if the conditions are met and (ELSE) actions to take if the defined conditions are not met.

• IF: Under the IF component you should define all the conditions that must apply for that step. Any type of logic can be formed. You can group certain conditions together and use logical operators to tie them together to form the complete logic.
  
  For example, the condition ((Service equals Apache Server and Urgency equals Medium) or (Service equals CloudFront and Payload Field tags contains us-region-2)) can be represented by:
  
  
  
  
• THEN: Here you define the actions that must be performed if the condition defined before is met. Here you add Action statements or more If/Else statements.
• ELSE (optional): This is optional. Only if you need actions to be performed if the conditions described in the IF section are not met. Both Action and more If/Else statements can be added here as well.

Condition Types

Any value from the payload of an incident can be used to form the conditions. Values from actions already performed in the workflow can also be referred. The list of available condition types are:

• Service: Service the incident occurred on.
• Status: Status of the incident.
• Urgency: Urgency level of the incident.
• Email From: If the incident is created by an email integration, then the email address of the sender.
• Email To: If the incident is created by email integration, then the (TaskCall) email address it was sent to.
• Payload Field: Refer to any field from the source payload of the incident. Besides just the top layer keys, you can refer to nested keys inside the payload as well by connecting the parent key and the child key by a dot. For example, if the json is {"a": {"b": 2}} you can get to "b" by setting the value to "a.b". You can view the source payload from Automation > Conditional Routing.
• Workflow Not Run Already: If this condition type is selected, then it will be checked that the workflow has not been run for this incident already. This is to avoid running the workflow multiple times on the same incident.
• Previous Action HTTP Status: The HTTP status of the very last action that was performed (e.g. 200, 201, 400, 403, etc). It will only apply for custom actions that require TaskCall to send an outbound request to an external service. For example, if you run an action that creates a Jira Issue and if that action fails you want to add a note, then after the Create Jira Issue action, you can include an If/Else statement with if Previous Action HTTP Status not equals 201 then Add Note.
• Previous Action JSON: The JSON response received from the last executed action. It will only apply for the custom actions that require TaskCall to make outbound requests just like the Previous Action HTTP Status condition type. In the example above, where we define an action to create a Jira Issue, you can refer to a field in the JSON response received back from Jira.

Condition Evaluation

Conditions can be evaluated using the following 8 comparators:

• Contains (could be used for lists and texts)
• Equals
• Exists (could be used to check if a key exists)
• Matches (could be used when the value is a regular expression)
• Not Contains
• Not Equals
• Not Exists
• Not Matches

Workflow Actions

Workflows support the following actions:

• Add responders: add new responders to the incident
• Subscribe users: subscribe new users to the incident to receive status updates
• Subscribe teams: subscribe teams to the incident
• Add conference bridge: add a conference bridge
• Post status update: post a status update
• Add note: add a note
• Add business impact: add an impact to show that a business service has been affected by the incident
• Reassign to: reassign the incident to another user or escalation policy
• Resolve incident: resolve the incident
• Send email: send an email (multiple email addresses should be separated by comma)
• Run custom action: run a custom action like Create Zendesk Ticket, Restart Server, Run Diagnostic Test, etc (only actions that you have already configured on your services can be run)

Internal Field References

Field references can be made to dynamically insert incident data into actions that utilize a text filed like posting a status update, sending an email, etc. This will allow the actions to be more contextualized.

Field references can be made by putting the desired in between starting and ending double curly braces {{ field }}. The following internal fields are supported at the moment:

• {{ incident_id }}: ID of the incident.
• {{ title }}: title of the incident.
• {{ description }}: description/text details of the incident
• {{ status }}: status of the incident

Field References with Regular Expressions

Field references can be made even more dynamic by using regular expressions to capture specific portions of the field itself. This can be done by adding the regular expression after the field name preceded by "|".

{{ field | regular-expression }}

You should test the regular expressions beforehand to make sure they generate the correct outcome.

Field References from Actions

Field references can also be made to the output of custom actions (actions that are executed on external systems and receive a response back). References to action outputs can be made as:

{{ step["action name"].field["field"] }}

If the same action was run multiple times, then you can refer to a specific run by its number. Numbering starts from 0. To add the run number, add a hyphen right after the action name followed by the run number (without any spaces).

For example: {{ step["Create Jira Issue-1"].field["self"] }}

Regular expressions can also be added just like in internal field references as:

{{ step["action name"].field["field"] | regular-expression }}

Permissions

Since workflows can be used to run intricate actions on your system, permissions can be imposed to restrict access to it. Permissions can be managed from the Permissions tab on the workflow details page. Two types of permissions can be imposed: