Overview

​

Overview

Workflows are Rootly’s automation engine. They let you run structured actions automatically (or manually) based on:

• Trigger events (what starts a workflow run)
• Run conditions (what must be true before actions execute)
• Actions (what Rootly and your integrations do when conditions pass)

Workflows are designed to remove repetitive coordination tasks during incident response and standardize follow-up processes across teams.

​

Common automation patterns

Examples of things teams commonly automate with workflows:

• Create or manage an incident communication channel (Slack or Microsoft Teams)
• Post periodic reminders to keep status pages and stakeholders updated
• Notify internal teams (for example, legal, security, or customer support) when high-impact incidents occur
• Create tickets in external systems (for example, Jira or Linear) based on impacted services or teams
• Create a conferencing bridge (for example, Zoom or Google Meet) for high severity incidents
• Page on-call responders via your paging provider when specific services are impacted
• Create or update retrospective documents and templates after resolution

If you need help configuring a workflow or cannot find a supported pattern, contact Rootly via Slack or email [email protected].

---

​

Workflows at a Glance

This section maps the key fields you configure on a workflow to how Rootly behaves when it runs.

​

Slack command defaults and uniqueness

If you do not define a Slack command explicitly, Rootly generates a default command derived from:

• The workflow kind and the workflow name (not just the name)

If the generated command collides with an existing command in the same team, Rootly appends a suffix to keep commands unique.

---

​

How Workflows Execute

Workflow execution has three major phases:

1. Initiation
2. Condition check
3. Execution

These phases are consistent across workflow types (incident, post-mortem, action item, alert, pulse, and standalone).

---

​

Phase 1: Initiation

A workflow run begins when one of its configured trigger events is met.

​

Trigger events are OR-joined

When you select multiple trigger events, Rootly evaluates them using OR logic:

• If any selected trigger event occurs, the workflow run initiates.

Example: if you select “Status Updated” and “Severity Updated,” the workflow initiates when either status changes or severity changes.

​

Trigger overlap rules

Some triggers are intentionally considered “catch-all” triggers and overlap with more specific triggers. Rootly enforces rules to prevent redundant or confusing configurations. Common examples:

• A catch-all “updated” trigger covers all attribute updates and should not be combined with field-specific update triggers.
• Some channel creation triggers overlap with incident creation triggers and cannot be selected together.

---

​

Phase 2: Condition Check

After initiation, Rootly evaluates run conditions before taking action.

​

Run condition operator

Rootly supports three join operators for combining run conditions:

• all of: every condition must be true
• any of: at least one condition must be true
• none of: every condition must be false

​

Per-condition operators

Each condition also has its own operator, which determines how Rootly compares the target field to the configured value(s):

• is: true if the value matches exactly
• is one of: true if a single-select field matches any provided value
• contains any of: true if a multi-select field includes at least one provided value
• contains all of: true if a multi-select field includes all provided values
• contains none of: true if a multi-select field includes none of the provided values
• none of: true if a single-select field matches none of the provided values
• is set: true if the field has a value
• is unset: true if the field has no value

​

Operator selection depends on field type

• Boolean fields typically use is set and is unset
• Single-select fields commonly use is, is one of, and none of
• Multi-select fields commonly use contains any of, contains all of, and contains none of
• is set and is unset can be used broadly to test presence

---

​

Phase 3: Execution

If run conditions pass, Rootly executes actions in order.

​

Action ordering

Actions run sequentially in the order they are listed in the workflow editor.

• If the workflow has multiple actions, the earlier actions run first.
• Actions can be individually disabled.

​

Failure behavior and Skip on Failure

By default:

• If an action fails, the workflow run halts and later actions do not execute.

If Skip on Failure is enabled for an action:

• Rootly records the failure for that action
• Rootly continues executing subsequent actions

---

​

Scheduling Behavior

Workflows support delays and repeating schedules. These controls are often used for reminders and periodic coordination messages.

​

Wait before executing

• Workflows can delay execution after initiation.
• The minimum wait is 10 seconds.
• Rootly re-checks run conditions after the wait period before executing actions.

Practical execution patterns:

• Condition check passes → wait → condition check passes → execute actions
• Condition check passes → wait → condition check fails → stop
• Condition check fails → stop

​

Repeat every and repeat on

Repeat behavior supports:

• A limited set of repeat intervals (minimum repeat interval is 10 minutes)
• A day-of-week selector where day codes are used internally (including a dedicated code for Thursday)

Repeating workflows behave as follows:

• The first run initiates only when trigger events occur.
• Subsequent runs occur when the repeat interval is reached.
• Repeating stops when run conditions are no longer true.

---

​

Manual Runs (Slack and Web)

Workflows can also be triggered manually, which is useful for ad-hoc operational tasks.

• Slack command runs require the workflow to include Slack Command as a trigger.
• Incident workflows have additional context requirements and permission checks.
• Web UI triggering from an incident runs the workflow immediately for that specific incident and only lists enabled incident workflows.

See Manually Running Workflows for a complete, code-aligned guide.

---

​

Organizing Workflows

Workflows are easier to maintain when they are organized consistently.

---

​

Best Practices

• Use descriptive names and descriptions. Treat workflows like operational code: explain intent, scope, and expected behavior.
• Avoid trigger overlap. Do not combine catch-all update triggers with field-specific update triggers unless you are intentionally broadening behavior.
• Start with conservative conditions. Begin with strict conditions, validate behavior, then widen scope intentionally.
• Validate failure behavior. Decide which actions should halt the run versus which can be skipped safely.
• Use wait and repeat carefully. When repeating workflows, confirm the run conditions stay true long enough for your reminder cadence.
• Document ownership. Use folders and naming conventions so teams know which workflows are actively maintained versus legacy.

---

​

Troubleshooting

​

A workflow runs when not all conditions are met

Most commonly:

• The run condition operator is set to any of rather than all of.
• A catch-all update trigger is firing more frequently than expected.

​

A Slack command cannot find the workflow

Most commonly:

• The Slack command value does not match the workflow’s configured command.
• The workflow does not include Slack Command as a trigger.

​

A workflow does not run automatically

Most commonly:

• The workflow is disabled.
• The trigger event selected is not the event that is actually occurring.
• Run conditions are too restrictive.

---

​

Frequently Asked Questions