> ## Documentation Index
> Fetch the complete documentation index at: https://docs.rootly.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Workflow Types
> Understand the six workflow types (incident, post-mortem, action item, alert, pulse, and standalone) and the trigger events available for each.
## 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.
| Trigger | When it’s triggered |
| - | - |
| **Incident In Triage** | When an incident enters triage (used for triage-first workflows). |
| **Incident Created** | When an incident record is created in Rootly. |
| **Incident Started** | When an incident is started (for teams that distinguish creation vs start). |
| **Incident Updated** | Catch-all trigger for incident updates. Use this instead of specific field update triggers when you want “any incident change.” |
| **Status Updated** | When incident status changes. |
| **Severity Updated** | When incident severity changes. |
| **Title Updated** | When incident title changes. |
| **Summary Updated** | When incident summary changes. |
| **Visibility Updated** | When incident visibility changes (for example, public vs private, depending on your configuration). |
| **Environments Added** | When a value is added to environments. |
| **Environments Removed** | When a value is removed from environments. |
| **Environments Updated** | When the environments list changes (covers add/remove). |
| **Incident Types Added** | When a value is added to incident types. |
| **Incident Types Removed** | When a value is removed from incident types. |
| **Incident Types Updated** | When incident types list changes (covers add/remove). |
| **Services Added** | When a service is added. |
| **Services Removed** | When a service is removed. |
| **Services Updated** | When services list changes (covers add/remove). |
| **Functionalities Added** | When a functionality is added. |
| **Functionalities Removed** | When a functionality is removed. |
| **Functionalities Updated** | When functionalities list changes (covers add/remove). |
| **Teams Added** | When a team is added. |
| **Teams Removed** | When a team is removed. |
| **Teams Updated** | When teams list changes (covers add/remove). |
| **Causes Added** | When a cause is added. |
| **Causes Removed** | When a cause is removed. |
| **Causes Updated** | When causes list changes (covers add/remove). |
| **Role Assignments Added** | When an incident role assignment is added. |
| **Role Assignments Removed** | When an incident role assignment is removed. |
| **Role Assignments Updated** | When a role assignment changes (assign/reassign/unassign). |
| **Timeline Updated** | When a timeline event is added, updated, or removed. |
| **Status Page Timeline Updated** | When a status page timeline event is added, updated, or removed. |
| **Slack Channel Created** | When an incident Slack channel is created for the incident. |
| **Slack Channel Converted** | When an existing Slack channel is converted into an incident channel. |
| **Microsoft Teams Channel Created** | When a Microsoft Teams channel is created for the incident (if enabled). |
| **Google Chat Space Created** | When a Google Chat space is created for the incident (if enabled). |
| **User Joined Slack Channel** | When a user joins the incident Slack channel. |
| **User Left Slack Channel** | When a user leaves the incident Slack channel. |
| **Subscribers Added** | When a subscriber is added. |
| **Subscribers Removed** | When a subscriber is removed. |
| **Subscribers Updated** | When subscriber list changes (covers add/remove). |
| **Slack Command** | When the workflow is manually triggered via Slack command. |
### Important: "Incident Created" vs "Slack Channel Created"
These two triggers fire at slightly different points in the incident lifecycle, and the choice matters for any workflow that touches the Slack channel.
* **Incident Created** fires when the Rootly incident record is created. This can happen a beat before the Slack channel is fully created.
* **Slack Channel Created** fires only after the incident's Slack channel is fully ready to receive messages, invites, and bookmarks.
**Which to pick:**
* If the workflow's actions only touch the incident record itself — set fields, page on-call, create a Jira ticket, send an email — use **Incident Created**.
* If any action depends on the Slack channel existing — sending a message into the channel, inviting users, adding bookmarks, archiving the channel, posting to a thread — use **Slack Channel Created** instead.
If your team creates incidents by converting an existing Slack channel (not by auto-creating a new one), pair **Slack Channel Created** with **Slack Channel Converted** so the workflow fires in both cases. The `slack_channel_created` trigger only fires for auto-created channels; conversions are covered by `slack_channel_converted`.
Don't select both **Incident Created** and **Slack Channel Created** for the same workflow unless you explicitly want it to run twice. Rootly guards against trigger overlap patterns that would produce redundant firing.
The same timing distinction applies to **Microsoft Teams Channel Created** and **Google Chat Space Created** for workflows that interact with those platforms.
***
## Post-mortem Workflows (Retrospectives)
Post-mortem workflows trigger based on retrospective creation/updates and retrospective status changes.
| Trigger | When it’s triggered |
| - | - |
| **Post Mortem Created** | When a post-mortem (retrospective) is created. |
| **Post Mortem Updated** | Catch-all trigger for post-mortem updates. |
| **Status Updated** | When post-mortem status changes. |
| **Slack Command** | When 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.
| Trigger | When it’s triggered |
| - | - |
| **Action Item Created** | When an action item is created. |
| **Action Item Updated** | Catch-all trigger for action item updates. |
| **Assigned User Updated** | When the assigned user changes. |
| **Summary Updated** | When the summary changes. |
| **Description Updated** | When the description changes. |
| **Status Updated** | When the status changes. |
| **Priority Updated** | When the priority changes. |
| **Due Date Updated** | When the due date changes. |
| **Teams Updated** | When the assigned team(s) changes. |
| **Incident Updated** | When the linked incident updates (useful when action items are incident-driven). |
| **Slack Command** | When the workflow is manually triggered via Slack command. |
***
## Alert Workflows
Alert workflows trigger from alert creation and alert lifecycle changes.
| Trigger | When it’s triggered |
| - | - |
| **Alert Created** | When an alert is received in Rootly. |
| **Alert Status Updated** | When an alert status changes. |
***
## Pulse Workflows
Pulse workflows trigger from pulse ingestion events.
| Trigger | When it’s triggered |
| - | - |
| **Pulse Created** | When 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).
| Trigger | When it’s triggered |
| - | - |
| **Slack Command** | When 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.
***
## Related Pages
The umbrella page covering trigger events, run conditions, actions, and execution phases.
How run conditions gate whether a workflow's actions execute after a trigger fires.
The complete catalog of actions available across all workflow types.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.