/workflows

name: "Rootly Workflows"
description: >
  Rootly's incident-response automation model: workflow tasks (each with a concrete
  `task_type` like `create_slack_channel` or `page_rootly_on_call_responders`), the
  trigger-type/`triggers`-event structure (incident, post_mortem, action_item, alert,
  pulse, simple), the ID-list based condition/matching fields, and the `enabled` flag
  used to turn a workflow on or off (there is no separate enable/disable tool).
when_to_use: >-
  When building, enabling, or auditing automated incident-response
  workflows. Use when: rootly workflow, automated workflow, workflow
  trigger, workflow action, incident automation, response automation, workflow condition, or
  runbook automation.

Rootly Workflows

Overview

Rootly workflows automate repetitive incident response tasks. Each workflow has a trigger type (what kind of event starts it, e.g. `incident`, `post_mortem`, `action_item`, `alert`), a set of specific trigger events within that type (e.g. `incident_created`, `status_updated`), matching filters (which severities/services/environments/teams it applies to), and one or more **workflow tasks** -- each task carries a specific `task_type` such as `create_slack_channel`, `page_rootly_on_call_responders`, or `send_email`.

Anti-triggers

"Workflow" means automation *inside Rootly, fired by incident/alert/action-item/postmortem events*. Several neighbouring things share the word.

• **Claude Code automation** — subagents under `agents/*.md` and slash

commands under `commands/*.md` are plugin authoring concerns, not Rootly resources. Nothing in this skill configures Claude.

• **PSA workflow rules** — ticket routing, board automation, and

notification rules inside a PSA are `connectwise-psa-tickets`, `halopsa-tickets`, or `autotask-tickets`.

• **PagerDuty's automation** — event orchestrations and incident

workflows are a separate product surface; use `pagerduty-incidents` and `pagerduty-alerts`.

• **RMM scripts and scheduled jobs** — running a script on an endpoint is

`datto-rmm-jobs`, not a Rootly action.

• **What a workflow did on a specific incident** — execution history is

read from `list_workflow_runs`, not this skill's conceptual reference.

Key Concepts

Workflow Structure

A `workflow` record has:

• `name`, `description`, `slug`
• `enabled` -- Whether the workflow is currently active (there is no separate enable/disable tool -- toggle this field with `update_workflow`)
• `trigger_params` -- The trigger type and specific events (see below)
• Matching filters: `environment_ids`, `severity_ids`, `incident_type_ids`, `service_ids`, `functionality_ids`, `group_ids` (teams), `cause_ids`, `sub_status_ids`
• `workflow_group_id` -- Optional grouping for organization
• `repeat_every_duration`, `continuously_repeat`, `repeat_condition_number_of_repeats` -- Repeat/retry behavior

Trigger Types

`trigger_params` is one of six shapes, selected by `trigger_type`:

| `trigger_type` | Fires on | |---|---| | `incident` | Incident lifecycle and field-change events | | `post_mortem` | Retrospective (postmortem) lifecycle events | | `action_item` | Action item lifecycle events | | `alert` | Alert events | | `pulse` | Pulse (recurring check) events | | `simple` | A minimal manual/generic trigger |

Each trigger type has its own `triggers` array of specific event names. Confirmed values include:

• **`incident`**: `incident_created`, `incident_started`, `incident_in_triage`, `incident_updated`, `title_updated`, `summary_updated`, `status_updated`, `severity_updated`, `services_added`/`removed`/`updated`, `environments_added`/`removed`/`updated`, `incident_types_added`/`removed`/`updated`, `functionalities_added`/`removed`/`updated`, `teams_added`/`removed`/`updated`, `role_assignments_added`/`updated`/`removed`, `timeline_updated`, `slack_command`
• **`post_mortem`**: `post_mortem_created`, `post_mortem_updated`, `status_updated`, `slack_command`
• **`action_item`**: `action_item_created`, `action_item_updated`, `assigned_user_updated`, `status_updated`, `priority_updated`, `due_date_updated`, `slack_command`

Condition Matching

Rootly does not use a `severity_is` / `severity_gte` style condition object. Instead:

• Matching is expressed by populating the workflow's `severity_ids`, `service_ids`, `environment_ids`, `group_ids`, etc. with the specific records the workflow should apply to
• Within `trigger_params`, per-field condition operators (e.g. `incident_condition_status`, `incident_condition_kind`) support `IS`, `ANY`, `CONTAINS`, `CONTAINS_ALL`, `CONTAINS_NONE`, `NONE`, `SET`, `UNSET`
• A top-level combinator (`incident_condition`: `ALL` / `ANY` / `NONE`) controls how multiple conditions combine

Workflow Task Types

A workflow's actions are separate `workflow_task` records (see [Common Query Patterns](#api-patterns)), each with a `task_type`. Confirmed `task_type` values include:

| `task_type` | Description | |---|---| | `create_slack_channel` | Create a dedicated incident Slack channel | | `invite_to_slack_channel` | Add responders to a Slack channel | | `send_slack_message` | Post a message to a channel | | `page_rootly_on_call_responders` | Page via Rootly's own on-call/schedules | | `page_pagerduty_on_call_responders` / `page_opsgenie_on_call_responders` | Page via a connected paging tool | | `create_jira_issue` | Create a tracking issue in Jira | | `send_email` | Send email notification | | `create_zoom_meeting` | Start a video bridge for the incident | | `http_client` | Call a custom HTTP endpoint (Rootly's generic webhook action) | | `add_role` | Assign an incident role | | `update_status` | Change the incident's status | | `update_incident` | Modify incident fields | | `create_incident_postmortem` / `update_incident_postmortem` | Create or update the incident's retrospective (see [postmortems](../postmortems/SKILL.md)) |

This is a representative subset -- Rootly's OpenAPI spec defines well over 100 task