Skip to main content

​
Overview

Rootly workflows are grouped into six workflow types. The workflow type determines two things:
  1. What object the workflow runs against (incident, alert, action item, etc.)
  2. Which trigger events are available (because not every object emits the same events)
Most workflow types are tied to a Rootly object and are triggered by changes to that object. For example, an Incident workflow can trigger when an incident’s status changes, while an Action Item workflow can trigger when a due date changes. Standalone workflows (called Simple workflows in Rootly’s internal model) are different: they do not depend on any Rootly object and can only be triggered manually through a Slack command.
You can chain workflow types together. For example, an Alert workflow can create an incident, which can then trigger one or more Incident workflows configured for Incident Created or Incident Started.

​
How Trigger Events Work

Workflows are not executed in a fixed order. A workflow runs when:
  1. One of its trigger events occurs (triggers are evaluated using OR logic), and then
  2. Its run conditions pass (if configured)
Because workflows are event-driven, two workflows can run “in parallel” if they share the same trigger, and a workflow configured with multiple triggers will run whenever any of them occur.

​
Avoid Overlapping Triggers

Some triggers are catch-all events (for example, Incident Updated) that already include more specific triggers (like Status Updated or Severity Updated). Rootly prevents overlapping configurations to avoid duplicate runs and hard-to-debug behavior.

​
Workflow Types and Trigger Events

Below are the trigger events grouped by workflow type. These names reflect how Rootly defines triggers internally and how they appear in the workflow builder.

​
Incident Workflows

Incident workflows trigger from incident lifecycle changes, field updates, timeline events, channel events, and subscriber changes.
TriggerWhen it’s triggered
Incident In TriageWhen an incident enters triage (used for triage-first workflows).
Incident CreatedWhen an incident record is created in Rootly.
Incident StartedWhen an incident is started (for teams that distinguish creation vs start).
Incident UpdatedCatch-all trigger for incident updates. Use this instead of specific field update triggers when you want “any incident change.”
Status UpdatedWhen incident status changes.
Severity UpdatedWhen incident severity changes.
Title UpdatedWhen incident title changes.
Summary UpdatedWhen incident summary changes.
Visibility UpdatedWhen incident visibility changes (for example, public vs private, depending on your configuration).
Environments AddedWhen a value is added to environments.
Environments RemovedWhen a value is removed from environments.
Environments UpdatedWhen the environments list changes (covers add/remove).
Incident Types AddedWhen a value is added to incident types.
Incident Types RemovedWhen a value is removed from incident types.
Incident Types UpdatedWhen incident types list changes (covers add/remove).
Services AddedWhen a service is added.
Services RemovedWhen a service is removed.
Services UpdatedWhen services list changes (covers add/remove).
Functionalities AddedWhen a functionality is added.
Functionalities RemovedWhen a functionality is removed.
Functionalities UpdatedWhen functionalities list changes (covers add/remove).
Teams AddedWhen a team is added.
Teams RemovedWhen a team is removed.
Teams UpdatedWhen teams list changes (covers add/remove).
Causes AddedWhen a cause is added.
Causes RemovedWhen a cause is removed.
Causes UpdatedWhen causes list changes (covers add/remove).
Role Assignments AddedWhen an incident role assignment is added.
Role Assignments RemovedWhen an incident role assignment is removed.
Role Assignments UpdatedWhen a role assignment changes (assign/reassign/unassign).
Timeline UpdatedWhen a timeline event is added, updated, or removed.
Status Page Timeline UpdatedWhen a status page timeline event is added, updated, or removed.
Slack Channel CreatedWhen an incident Slack channel is created for the incident.
Slack Channel ConvertedWhen an existing Slack channel is converted into an incident channel.
Microsoft Teams Channel CreatedWhen a Microsoft Teams channel is created for the incident (if enabled).
User Joined Slack ChannelWhen a user joins the incident Slack channel.
User Left Slack ChannelWhen a user leaves the incident Slack channel.
Subscribers AddedWhen a subscriber is added.
Subscribers RemovedWhen a subscriber is removed.
Subscribers UpdatedWhen subscriber list changes (covers add/remove).
Slack CommandWhen the workflow is manually triggered via Slack command.

​
Important: “Created” vs “Slack Channel Created”

If you select Incident Created, you generally should not also select Slack Channel Created for the same workflow unless you explicitly want separate runs. Rootly guards against trigger overlap patterns that would produce redundant firing.

​
Post-mortem Workflows (Retrospectives)

Post-mortem workflows trigger based on retrospective creation/updates and retrospective status changes.
TriggerWhen it’s triggered
Post Mortem CreatedWhen a post-mortem (retrospective) is created.
Post Mortem UpdatedCatch-all trigger for post-mortem updates.
Status UpdatedWhen post-mortem status changes.
Slack CommandWhen the workflow is manually triggered via Slack command.
Post-mortem workflows do not use a dedicated “Causes Updated” trigger. If your process depends on causes, use Post Mortem Updated (with run conditions) or condition on causes directly where supported.

​
Action Item Workflows

Action item workflows trigger based on action item lifecycle changes and field updates. They also support a catch-all update trigger.
TriggerWhen it’s triggered
Action Item CreatedWhen an action item is created.
Action Item UpdatedCatch-all trigger for action item updates.
Assigned User UpdatedWhen the assigned user changes.
Summary UpdatedWhen the summary changes.
Description UpdatedWhen the description changes.
Status UpdatedWhen the status changes.
Priority UpdatedWhen the priority changes.
Due Date UpdatedWhen the due date changes.
Teams UpdatedWhen the assigned team(s) changes.
Incident UpdatedWhen the linked incident updates (useful when action items are incident-driven).
Slack CommandWhen the workflow is manually triggered via Slack command.

​
Alert Workflows

Alert workflows trigger from alert creation and alert lifecycle changes.
TriggerWhen it’s triggered
Alert CreatedWhen an alert is received in Rootly.
Alert Status UpdatedWhen an alert status changes.

​
Pulse Workflows

Pulse workflows trigger from pulse ingestion events.
TriggerWhen it’s triggered
Pulse CreatedWhen a pulse is received in Rootly.

​
Standalone Workflows (Simple)

Standalone workflows do not run against a Rootly object. They are manually triggered and are ideal for “utility” workflows (for example, running a set of Slack actions on demand).
TriggerWhen it’s triggered
Slack CommandWhen the workflow is manually triggered via Slack command.

​
Best Practices

  • Prefer specific triggers when possible. If you only care about severity changes, use Severity Updated rather than Incident Updated.
  • Use catch-all triggers intentionally. Catch-all triggers are powerful, but can lead to high execution volume if paired with broad conditions.
  • Avoid redundancy. If two triggers represent the same functional event for your use case, pick the one you actually want to represent “start.”
  • Design for chaining. A common pattern is: Alert workflow → create incident → Incident workflow → run structured response actions.
  • Test with narrow scopes first. Start by scoping run conditions tightly (severity/team/service), confirm behavior, then expand.

​
Frequently Asked Questions

Workflows are event-driven. They execute when their trigger event fires and their conditions pass—not because they are “first” or “second” in a sequence. If multiple workflows listen to the same trigger, they may run around the same time.
Use a catch-all trigger when you truly want to react to any update on that object, then refine behavior using run conditions. If you only care about a specific change (like Status Updated), prefer the specific trigger to reduce noise and unintended execution.
Slack Command triggers are available on several workflow types (including Incident, Post-mortem, Action Item, and Standalone). Alert and Pulse workflows are designed to run from ingestion and lifecycle events instead of manual command triggers.
Yes. If a workflow action causes another object event (for example, creating an incident from an alert), any workflows listening for that downstream event can run. This is a common way to build multi-stage automation.
Some triggers are broad and implicitly include other triggers (for example, an object-level “Updated” trigger covering multiple specific field changes). Overlaps can cause duplicate workflow runs and confusing behavior, so Rootly prevents or warns on combinations that represent the same logical event.