> ## Documentation Index > Fetch the complete documentation index at: https://docs.incident.io/llms.txt > Use this file to discover all available pages before exploring further. # Workflow triggers > Find the event that should start your automation, from an incident change to a recurring daily schedule. A trigger is the event that starts a workflow. Every workflow has exactly one, and the trigger you choose decides which conditions you can set and which variables your steps can reference. There are currently over twenty triggers available. They cover incident changes, on-call and alerting events, things people do in Slack, and a [recurring schedule](#run-a-workflow-on-a-recurring-schedule) to run a workflow like a cron job. Use the [trigger reference](#trigger-reference) to find the one you need, and read [limits](#limits) before you build something that needs frequent repetition. To pick a trigger, open [Workflows](https://app.incident.io/~/settings/workflows), select **New workflow**, then choose from the **Choose trigger** panel. Triggers are grouped there the same way they are on this page. The Choose trigger panel in the workflow editor, listing triggers under the General, User actions, Specific changes, Other, and On-call headings ## Trigger reference **API name** is the value for the `trigger` field in the [public API](/api-reference/introduction) and [Terraform](/workflows/terraform). **Requires** is the product or integration a trigger depends on. ### General | Trigger | Fires when | Requires | | -------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------- | -------- | | **An incident is created or changed**
`incident.updated` | An incident is created, or any part of it changes: severity, status, roles, custom fields, and the rest. | Response | | **An incident update is shared**
`incident.update_shared` | Someone shares an incident update, for example with `/inc update`. | Response | ### User actions | Trigger | Fires when | Requires | | ----------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | ---------------------- | | **A user joins an incident Slack channel**
`incident-channel.user-joined` | Someone joins the incident channel. | Response, Slack | | **A user leaves an incident Slack channel**
`incident-channel.user-left` | Someone leaves the incident channel. | Response, Slack | | **A message is posted in an incident channel**
`slack.message_posted` | Any message is posted in the incident channel. | Response, Slack | | **A user reacts to a message in an incident channel**
`slack.message_reaction_added` | A message receives an emoji reaction. See [emoji triggers](/workflows/emoji-triggers). | Response, Slack | | **A shoutout is given**
`shoutout.created` | Someone gives a shoutout during an incident. | Response, Slack | | **A user acks an escalation**
`escalation.acked_v2` | A responder acknowledges an escalation. | An escalation provider | | **A user triggers this workflow**
`manual` | Someone runs the workflow by hand, from the dashboard or with `/inc workflows`. | Response | ### Specific changes | Trigger | Fires when | Requires | | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------ | -------- | | **An incident's status changes**
`incident.status-changed` | The incident moves to a different status. | Response | | **An incident's severity changes**
`incident.severity-changed` | The incident's severity changes. | Response | | **An incident role assignment changes**
`incident.role-assignment-changed` | A role is assigned, reassigned, or cleared. | Response | | **A custom field value is changed**
`incident.custom-field-value-changed` | A custom field value changes on an incident. It doesn't fire when the incident is created. | Response | ### On-call | Trigger | Fires when | Requires | | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | ----------------- | | **An alert is created or changed**
`alert.updated` | An alert arrives, is resolved, or has its attributes changed. | Pro or Enterprise | | **An alert is attached to an incident**
`alert.attached` | An alert is attached to an incident, including by an alert route. | Response | | **An escalation is created or its level changes**
`escalation.created` | An escalation starts notifying, or moves to the next level in its path. | On-call | | **An On-call schedule shift changes**
`schedule.currently-on-call-changed` | A schedule hands over from one person to the next. | On-call | ### Other | Trigger | Fires when | Requires | | ------------------------------------------------------------------------- | ------------------------------------------------------ | ------------------------------------ | | **An action is created or changed**
`action.updated` | An action is created, reassigned, or changes status. | Response | | **A follow-up is created or changed**
`follow-up.updated` | A follow-up is created, reassigned, or changes status. | Response | | **A user completes a decision flow**
`decision-flow-run.completed` | Someone reaches an outcome in a decision flow. | Response | | **A document is created or updated**
`document.updated` | A document is created, or its status changes. | Response | | **An incident debrief is scheduled**
`debrief.created` | A debrief is scheduled for an incident. | Response, Google or Outlook Calendar | | **A status page update is published**
`status-page.update-published` | A new update is published to a status page. | Response | | **On a recurring schedule**
`scheduled` | A time you choose arrives. | Nothing | ## Run a workflow on a recurring schedule Sometimes you want a workflow to run on a regular cadence, rather than in reaction to a trigger. For example, to send a morning digest of open incidents, or a weekly reminder of who's on call. This trigger is available to all accounts. ### Set the cadence Set the cadence in the trigger card: an interval, an hour, and a timezone. The On a recurring schedule trigger card, with controls for the interval, the hour, and the timezone | Interval | You also choose | Example | | ------------- | ---------------- | ----------------------------------- | | Every weekday | Hour | Every weekday at 09:00 London | | Every day | Hour | Every day at 18:00 New York | | Every week | Day of the week | Every Monday at 10:00 Berlin | | Every month | Day of the month | The 1st of every month at 08:00 UTC | Times are whole hours, read in the timezone you pick, so a 09:00 London workflow follows daylight saving. Runs start within a few minutes of the scheduled time. Reach out to support or your account manager if you have a use case that requires running a workflow more frequently. ### What your steps can reference A scheduled workflow can access a list of active and triage incidents, and a list of incidents in a post-incident status. You can also access any data from your [Catalog](/catalog/catalog-setup). ### Example: a weekday digest of open incidents Create a workflow, choose **On a recurring schedule**, and set it to every weekday at 09:00 in your team's timezone. Leave conditions empty to run every weekday. Add a condition on **Active incidents** to stay quiet on mornings when nothing is open. Add a [loop](/workflows/loops) over **Active incidents**, then add **Send message to a channel** inside it, pointing at your team channel. Reference **Each active incident**'s name, severity, and lead so each line is useful on its own. Save and set live. The first run happens at the next matching occurrence, and you can watch it under **Activity** on the workflow. To send one summary message instead of one per incident, skip the loop and reference **Active incidents** directly in a single **Send message to a channel** step. ### Repeating during an incident To nudge a channel repeatedly while an incident is open, use [rule-based suggestions](/incidents/rule-based-suggestions). They prompt responders on a cadence you set, and they adapt to how busy the channel is. For repeat paging when nobody responds, use [escalation paths](/on-call/escalation-paths). They have their own levels and repeats, and a workflow can start one with an escalate step. Workflows themselves run from an event or a schedule, and a scheduled workflow runs at most once a day. ### Test and retrospective incidents By default a workflow runs on standard incidents only, so a test incident doesn't set off real automation. Open **Advanced settings** to add test incidents, retrospective incidents, or both. Workflows never run on declined, canceled, or merged incidents. ## FAQs No. Each workflow has exactly one trigger, chosen when you create it and fixed afterwards. To react to two events, build two workflows. A trigger only appears when your account has what it depends on. On-call triggers need the On-call product, Slack triggers need Slack installed, the debrief trigger needs a calendar integration, and alert workflows need a Pro or Enterprise plan. The **Requires** column in the [trigger reference](#trigger-reference) names each one. No. Daily, weekdays, weekly, and monthly are the available intervals, and the hour is a whole hour. Start with **An incident is created or changed** and narrow it with conditions. Move to a specific trigger such as **An incident's severity changes** when your automation is genuinely about that transition, since the specific triggers won't fire on unrelated edits.