Overview
Workflows play a key part in the overall Rootly experience. They allow teams to automate manual actions based on a series of trigger events and run conditions. There are endless possibilities designed to fit your exact use cases. Some common automations are:
-
Automatically spin up a Slack channel when new incident is declared
-
Automatically remind Slack channel to update status page every 30 minutes
-
Automatically email legal team whenever a SEV0 incident occurs
-
Automatically create Jira tickets on the corresponding project boards based on the impacted teams
-
Automatically spin up Zoom or Google Meet bridges for high severity incidents to enable high bandwidth conversations
-
Automatically page the on-call responders via PagerDuty or Opsgenie whenever a certain service is down
-
Automatically create retrospectives using different templates depending on the types of incidents
-
…thousands of other combinations to fit your exact incident process!
If you need help configuring a Workflow or don’t see what you’re looking for, reach out via Slack or support@rootly.com.
Workflows at Glance
| No. | Description |
|---|---|
| 1) Name | Give your workflow a name for easy identification. If you do not set a Slack Command (in field 5) for the workflow during initial creation, Rootly will hyphenate the Name field as the default command value. |
| 2) Description | Add a detailed description to inform users what the workflow does. |
| 3) Workflow Folder | Place the workflow in a specified folder. If a workflow is not in any folder, you will be able to find the workflow by filtering for All Workflow on the workflows page. |
| 4) Enabled | When a workflow is disabled, it will not automatically run when trigger conditions are met. Disabled workflows can still be triggered by manual Slack command. |
| 5) Slack Command | Every workflow can be triggered via Slack command. Choose an easy-to-remember command if your process calls for a workflow to be triggered in this fashion. If you do not set a value here, Rootly will hyphenate the Name field as the default command value. |
| 6) Command Feedback Enabled | Selecting this field will result in a message output in Slack every time the workflow is run via manual Slack command. |
| 7) Repeat Every | Each workflow can be run on a recurring schedule. This field must be used alongside the Repeat On field. The value set in this field indicates how often the workflow is initiated (e.g. 30min, 2h 30min, 1 day). The very first run of the workflow will initiate when the trigger events are met (field 10). However, subsequent runs will initiate once the repeat interval is reached - regardless of the trigger events. Recurring workflows will stop as soon as the run conditions (fields 11 & 12) are no longer true. |
| 8) Repeat On | This field must be used alongside the Repeat Every field. When a value is set for the Repeat Every field, use this field to select the days of the week on which the workflow will run repetitively. For example, if the following values are set: - Repeat Every = 5h - Repeat On = M, W, F The workflow will run repetitively every 5 hours on Mondays, Wednesdays, and Fridays. |
| 9) Wait Before Executing | Each workflow can be configured with a delay. The minimum delay that can be set is 10 seconds. Condition checks for workflows with delays will follow this pattern: - Condition Check: Pass → Delay → Condition Check: Pass → Run → End - Condition Check: Pass → Delay → Condition Check: Fail → End - Condition Check: Fail → End |
| 10) Trigger events | Trigger events determine when a workflow is initiated. Once initiated, the run conditions (fields 11 & 12) will be checked before executing any of the actions (fields 13). You can find the full list of trigger events on this page. |
| 11) Run condition operator | Once a workflow initiates, the platform will check for the run conditions. The run conditions must be met in order for the workflow to progress to the actions. Each run condition can be joined by the following operators: - all of - every condition must be true - any of - if any condition is true - none of - if every condition is false |
| 12) Run conditions | Run conditions are set based on incident, action item, retrospective, alert, or pulse parameters. The Workflow Type determines what parameters are available to condition off of. Run conditions must be met before a workflow can proceed to take any action. |
| 13) Actions | Workflow actions are what actually execute once the run conditions are met. Available actions are dependent on the applications that are integrated for the organization. |
How Workflows are Executed?
Workflows can be broken down to three major phases: Initiation, Condition Check, and Execution.
Phase 1: Initiation
Each workflow can be initiated by a series of trigger conditions. They are considered initiated when one of their trigger events is met. You can find a full list of trigger events here.
Selected trigger events are joined by OR conditions. So, as long as one of the events are met, the workflow will be initiated. For example, if you have a workflow that’s configured with the following triggers:
The workflow will initiate…
-
when the status of the incident is updated,
-
OR when the severity of the incident is updated,
-
OR when the team of the incident is updated
Phase 2: Condition Check
Once a workflow is initiated, it must pass conditions before any action takes place. Conditions are dependent on the Workflow Type: Incident workflows will check for conditions on incident properties. While action item workflows will check for conditions on action item properties.
Run conditions can be joined by the following operators:
-
all of- every condition must be true -
any of- if any condition is true -
none of- if every condition is false
The default operator is all of, as that is the most popular and restricted operator.
If you run into a workflow that is running when not all of the configured conditions are met, this should be the first place to check. It is very likely that it’s set to run when any of the conditions are met.
Each individual condition has their own operator as well:
-
is- true if the property is exactly a set value -
is one of- true if a single-select property is ANY of the set values -
contains any of- true if a multi-select property includes ANY of the set values -
contains all of- true if a multi-select property includes ALL of the set values -
contains none of- true if a multi-select property includes NONE of the set values -
none of- true if a single-select property is NONE of the set values -
is set- true if a field contains a value -
is unset- true if a field does NOT contain a value
The field type of a property can impact which operator can be used.
A boolean field can only be used with is set and is unset since it’s either true or false.
A single-select field only allows a single value to be selected, so it is commonly conditioned with the is, is one of, and none of.
A multi-select field allows multiple values, therefore it is often conditioned with contains any of, contains all of, and contains none of.
is set and is unset are flexible enough to be used with any field type. It is commonly used to check if a field has been set or not set.
Here is an example of how this phase will behave given the following conditions:
The workflow will run if…
-
Incident Kind is Incident,
-
AND incident Status is Resolved OR Cancelled,
-
AND incident Severity is SEV0 OR SEV1,
-
AND incident Team is anything but Test
Phase 3: Execution
Once a workflow has successfully met its run conditions, its configured actions will officially start. The available actions are dependent on the Workflow Type and integrated applications.
A single workflow can have multiple actions. The order in which the actions are placed will dictate the run order of actions.
Each action can be independently disabled.
By default, when a single action fails within a workflow, the entire workflow will be halted. This behavior can be changed by turning on the Skip on Failure flag. This will result in the workflow continuing, even if the action fails.
For example if the following actions are configured for a workflow:
The workflow will attempt to…
-
Send a Slack message
-
Regardless of the result of step 1, send an email
-
IF the email fails to send, the workflow ENDs
-
IF the email successfully sends, the workflow continues to step 5
-
Skips adding a message to the incident timeline
-
Adds an action item
-
IF the action item is successfully added, workflow marked as SUCCESS
-
IF the action item fails to be added, workflow marked as FAILED
Organizing Workflows
Workflows will be the backbone of your automations. It is important to keep them organized, so it’s easy to locate and manage. On the workflows page, you’ll see the following sections:
| No. | Description |
|---|---|
| 1) All Workflows | You can quickly view all of the workflows in your organization. |
| 2) Folders | You can create folders to place your workflows in. Workflows are not impacted by which folder they are placed in. This is purely used for organization purposes. |
| 3) Enabled / Disabled | This is an easy way to enable/disable each workflow. You don’t have to click into the edit page for each workflow to do so. |
| 4) Expand / Collapse | Expanding the tile will show a summary of the workflow - giving you a quick way to view them without having to click into each workflow. |
| 5) Workflow Summary | It’s not always easy to recognize what a workflow is configured to do purely based on its name. When expanded, you’ll be able to see a summary of the workflow containing its trigger events, run conditions, and actions. |
| 6) Filter & Sort | To quickly locate workflows, you can filter and sort workflows. |
Support
If you need help or more information about this integration, please contact support@rootly.com or start a chat by navigating to Help > Chat with Us.