Skip to main content

​
Overview

Action item workflows automate what happens after work is identified—whether that work comes from an incident, a retrospective, or ongoing operational reviews. In Rootly, action items are first-class objects tied to incidents, and workflows can react whenever those action items are created, updated, assigned, or completed. These workflows are especially useful for eliminating manual handoffs. Instead of relying on responders to remember to open Jira tickets, assign owners, or notify teams, you can encode those rules once and let Rootly enforce them consistently. Common use cases include:
  • Automatically creating or updating Jira (or other ticketing) issues when an action item is created or completed
  • Assigning tickets based on the user or team assigned to the Rootly action item
  • Notifying teams or owners when work is assigned, completed, or overdue
Action item workflows are triggered by action item events, not incident events. However, you can still use incident properties as run conditions (such as severity, services, or teams) to precisely control when the workflow should execute.

​
Supported Triggers

Action item workflows support the following trigger events:
  • Action Item Created (action_item_created)
  • Action Item Updated (action_item_updated) – catch-all trigger
  • Assigned User Updated (assigned_user_updated)
  • Summary Updated (summary_updated)
  • Description Updated (description_updated)
  • Status Updated (status_updated)
  • Priority Updated (priority_updated)
  • Due Date Updated (due_date_updated)
  • Teams Updated (teams_updated)
  • Incident Updated (incident_updated)
  • Slack Command (slack_command)
  • [CustomField] «Field Name» Updated (custom_fields.<field-slug>.updated) – one trigger per custom field, fired when that field’s value changes on an action item

​
Catch-All Trigger Behavior

Action Item Updated is a catch-all trigger that fires for any change to the action item. Do not combine it with more specific field-level triggers (such as Status Updated or Priority Updated), or the workflow may fire more often than intended.
Custom field triggers appear once custom fields for action items is enabled for your organization — one trigger per enabled custom field, whether or not it is placed on an action item form. They fire for both tasks and follow-ups.

​
Create an Action Item Workflow

1

Start a New Workflow

Navigate to Workflows → Create Workflow → Action Item.
2

Choose Trigger Event(s)

Select the action item events that should initiate the workflow. For example, a workflow can start when a new action item is created.You can also include a Slack Command trigger if you want the workflow to be runnable manually.
3

Define Run Conditions

Action item workflows can evaluate both action item properties and incident properties. This allows you to build rules like:
  • “Only create tickets for high-priority action items”
  • “Only notify teams when the parent incident was SEV0 or SEV1”

​
Action item fields

The following action item fields can be used in conditions:
​
task | follow_up
Separates remediation work (task) from informational follow-ups (follow_up).
​
open | in_progress | done | cancelled
Commonly used to trigger workflows when work is completed.In an action item workflow, “status” always refers to the action item status, not the incident status.
​
high | medium | low
Often used to restrict automation to higher-impact follow-ups. Action item priority is distinct from incident severity — they are separate fields and should not be conflated.
​
team (group)
The team the action item is assigned to. This is independent of the incident’s team assignment — an incident can belong to one team while its action items are owned by another. Action item workflows evaluate the action item’s assigned teams, not the incident’s.
​
action item custom field
Any custom field placed on an action item form can be used as a condition. Supports is, is not, is one of, is set, and is unset semantics, plus contains any / all / none of for multi-value fields. Evaluates the action item’s own field values, not the parent incident’s — use incident conditions (below) for incident custom fields.
4

Use Incident Conditions (Optional)

Because action items are tied to incidents, you can further narrow execution using incident properties such as:
  • Incident severity
  • Impacted services
  • Incident teams
  • Custom incident fields
For details on operators and condition logic, see: Condition Checks.
5

Configure Actions

Once the workflow passes all conditions, its actions are executed. Available actions depend on your integrations, but action item workflows commonly include:
  • Ticketing actions (create or update Jira, Linear, Shortcut, Asana, ClickUp, and more)
  • Messaging actions (send Slack or Microsoft Teams messages)
  • Rootly actions (create or update action items, add timeline entries)
  • Notifications (email, SMS, or phone where configured)
Two actions are worth calling out for custom field automation:
  • Update Action Item can set an action item’s custom field values via its Custom Fields Mapping input. Values support Liquid, so you can populate a field from incident context (for example, {{ incident.severity }}).
  • Ticketing actions (Create/Update Jira Issue, Linear Issue, GitHub Issue, Asana Task, and others) support custom field mappings, letting you write an action item’s field values into the external ticket with Liquid — for example, {{ action_item.custom_fields_by_slug.business-unit-owner }}. See Action Item Variables.
By default, a failing action halts the workflow. Enable Skip on Failure on non-critical actions to allow the workflow to continue even if one step fails.

​
Best Practices

Action item workflows are most effective when they reinforce ownership and accountability without creating noise.
  • Trigger on meaningful changes. Status transitions (for example, to done) are usually better triggers than generic updates.
  • Use priority as a gate. Many teams only want automation for high-impact action items.
  • Let Rootly be the source of truth. Use the action item as the canonical object and sync outward to ticketing systems, not the other way around.
  • Avoid catch-all triggers unless necessary. Action Item Updated should almost always be paired with strict run conditions.
  • Create ownership explicitly. When creating tickets, assign owners and due dates automatically so work does not stall.

​
Frequently Asked Questions

Yes. They can run automatically based on action item events and can also be triggered manually using a Slack command if that trigger is enabled.
Yes. Action item workflows can evaluate both action item fields and incident fields, allowing very precise control over when the workflow runs.
This is usually caused by using the catch-all Action Item Updated trigger without restrictive run conditions. Narrow the workflow using specific triggers or conditions such as status or priority.
No. Action item workflows are triggered by changes inside Rootly. Updates in external tools only trigger workflows if they sync back and modify the Rootly action item.
Yes — this is a common pattern. The Export to ticketing modal itself does not support Liquid variables, but the act of exporting fires the Action Item Updated trigger (it writes the external ticket reference back to the action item). You can build an action item workflow that runs on that trigger and uses the relevant Update action (Update Jira Issue, Update Linear Issue, Update Asana Task, etc.) to populate a field with {{ incident.url }} or any other incident variable. Full walkthrough: Linking Exported Tasks Back to the Incident.
Need help designing reliable follow-up automation? Contact your Rootly onboarding representative or email support@rootly.com.

Incident Workflows

The companion type — action items belong to incidents, so most action-item automation follows an incident-workflow chain.

Workflow Types

The full set of workflow types and when to reach for each.

Action Items

The object these workflows read and write — tasks and follow-ups on an incident.