> ## 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.
# Actions
> Keep track of what needs doing during an incident, and who picked it up.
export const SlackPreview = ({snapshot, alt, maxWidth, caption}) => {
const slug = snapshot.replace(/\.json$/, '').replace(/\//g, '--').replace(/[^a-zA-Z0-9-]/g, '-').replace(/-{2,}/g, '-').replace(/^-|-$/g, '').toLowerCase();
const light = `/images/slack_generated_screenshots/${slug}-light.png`;
const dark = `/images/slack_generated_screenshots/${slug}-dark.png`;
return <>
{caption &&
{caption}
}
;
};
During an incident it's easy to lose track of who's fixing what, and easier still to forget it entirely once the channel goes quiet. Actions are the things that **need doing now** to move an incident forward: restarting the server, drafting customer comms, pulling a list of affected accounts. Capture them as you go and everyone responding sees the same list of work, instead of it living in the incident lead's head.
Actions are one of three kinds of task in incident.io:
| Type | What it's for | When it gets done |
| - | - | - |
| **Action** | Work that moves the incident towards resolution | During the incident |
| **[Follow-up](/post-incident/follow-ups)** | Work the incident leaves behind for you to pick up | After the incident is resolved |
| **[Post-incident task](/post-incident/post-incident-flow)** | Steps your team owes every incident, like a debrief | Before the incident can close |
Sometimes an action turns out to extend beyond resolving the incident. When that happens it shouldn't hold the incident open, so [turn it into a follow-up](#turning-actions-into-follow-ups) and it carries over to the work your team picks up afterwards.
Every action is **open**, **completed**, or **not doing**. Mark something as not doing when your team consciously decides against it, so it leaves the open list without vanishing from the record. Every change appears on the incident [timeline](/post-incident/timeline), so the write-up afterwards shows who did what and when.
How you create and manage actions depends on whether you run incidents in Slack or Microsoft Teams. The dashboard works the same way for both.
## Creating actions
There are several ways to create an action, so you can capture one without breaking off what you're doing.
### React with the `:boom:` emoji
React to any message in an incident channel with `:boom:` and we'll turn it into an action, using the message as the description. This is the fastest route when someone has just said "we should probably restart the workers" and you want it written down before the thread moves on.
### Run `/incident action`
Run `/incident action` in an incident channel to open the **Create action** modal. Add a description after the command to pre-fill it, for example `/incident action restart the database`.
### From the dashboard
Open the incident and select **Add an action**, or use the **+** button on the **Actions** section.
### By asking @incident
Tag [@incident](/ai/at-incident) in the incident channel and ask it to create, update, reassign, or delete actions in plain language. The agent runs every change with your own permissions and records it against your name.
### Via a workflow
Workflows can create actions for you. Add the **Create incident actions** step to a [workflow](/workflows/getting-started), list the actions you want, and they'll be created automatically. Useful when a class of incident always starts the same way, like a security incident that always needs an access review at kick off.
The step takes one optional assignee, who owns every action it creates. To split them across different owners, use a separate step for each.
## Managing actions
Actions can be assigned, edited, completed, or dropped, from wherever you're working.
### Assigning actions
Assigning is optional. Leave **Who's picking it up?** empty and the action sits unassigned until someone claims it.
When you do assign someone, we mention them in the incident channel and invite them to it if they're not already there.
From an action's menu you can also:
* **I'll take it**: assign an unassigned action to yourself
* **Reassign to me**: take an action currently assigned to someone else
* **Unassign**: put it back in the unassigned pile
* **Request an owner**: post a message to the channel asking for a volunteer, with an **I can take this** button for anyone to claim it
### Tracking what's open
Run `/incident actions` to see every action on the incident, grouped by status and showing who owns each one.
Each action's menu offers **Mark as completed**, **Mark as not doing**, **Mark as follow-up**, **Edit action**, and **Delete**. Once an action is completed or marked as not doing, **Return to open** puts it back.
Select **Post open actions in channel** to share the outstanding list with everyone in the channel, which is a quick way to bring new responders up to speed.
## Turning actions into follow-ups
You can't resolve an incident while it still has open actions. When you try, we'll ask you what to do with them: choose **Convert to follow-ups** to carry them into the post-incident flow, or **Mark all as complete** if the work is already done.
You can convert a single action at any point using **Mark as follow-up** from its menu. To skip the action stage entirely and create a follow-up straight from a message, react with `:fast_forward:` instead of `:boom:`.
## Creating actions
There are a few ways to create an action, so you can capture one without breaking off what you're doing.
### From the incident's page
Head to the incident's page and select **Add an action**. You can get there from the dashboard, or from the incident.io tab in the incident channel.
Give the action a **description**, and optionally an **owner**. We'll post it into the incident channel so the rest of the team can see what's been picked up.
### By asking @incident
Ask [@incident](/ai/at-incident) to create one for you, from the dashboard or from the incident.io tab in the incident channel. The agent runs every change with your own permissions and records it against your name.
### Via a workflow
Workflows can create actions for you. Add the **Create incident actions** step to a [workflow](/workflows/getting-started), list the actions you want, and they'll be created automatically. Useful when a class of incident always starts the same way, like a security incident that always needs an access review at kick off.
The step takes one optional assignee, who owns every action it creates. To split them across different owners, use a separate step for each.
## Managing actions
Actions can be assigned, edited, completed, or dropped, from wherever you're working.
### Assigning actions
Assigning is optional, and an action sits unassigned until someone picks it up.
When you assign an action, the assignee gets a direct message from incident.io telling them what it is and which incident it belongs to, with a **View action** button that opens it in the incident.io tab in the incident channel.
### Tracking what's open
Manage actions from the **Actions** section on the incident's **Overview** tab.
* Select the checkbox to mark an action complete
* Select the action to edit its description or assignee
* Use the **...** menu for **Mark as follow-up** and **Delete**
When an incident has more than ten actions we collapse the list, so select **Show more** to see the rest.
## Turning actions into follow-ups
Once an incident is resolved or closed, any actions still outstanding are flagged on the **Actions** section, prompting you to make them follow-ups. Select **Convert to follow-ups** to move all of them into the post-incident flow at once.
You can also convert a single action at any point with **Mark as follow-up** from its **...** menu.
## FAQs
Each action has a single owner, so it's always clear who has picked something up. You can assign anyone who can
already access the incident, which on a [private incident](/incidents/private-incidents) means they need to be a
participant first.
In the dashboard, actions live with the incident they belong to, which keeps them focused on the response in front of
you. To pull them together across incidents, [list them with the API](/api-reference/actions-v3/list), filtering by
assignee or incident mode.
They stay scoped to that [stream](/incidents/streams), so each workstream keeps its own focused list. Streams don't
have their own post-incident flow, so their actions stay as actions rather than becoming follow-ups. Once a stream is
closed you can still update the actions it already has.
As soon as an incident has been accepted. Triage incidents are still being assessed, so actions and follow-ups
become available once you [accept it out of triage](/incidents/triaging).