Incident roles

An incident role says who is handling a particular part of the response, like the Incident Lead who coordinates it. You assign roles inside the incident channel and change them as the incident develops.

Firefight comes with one role. You define the rest.

Role	Description
Incident Lead	Coordinates incident response and makes decisions

Incident Lead is built into Firefight. It is there from your first incident and you cannot delete or disable it, because incident lists and the incident page always show who is leading.

What a role means

A role names one accountable person, not everyone doing the work. Making someone the Incident Lead does not mean they fix the incident alone, it means they own coordinating it and saying where things stand. The same goes for any role you define. Work that several people share belongs in action items and follow-ups instead, which any number of people can pick up.

Assigning a role does not change what someone can do in Firefight. That is set by their access level.

Defining your own roles

Configure → Incident Roles lists every incident role. Click Add Role to define your own, for example Operations Lead or Communications Lead, with a name and a description of what the role is responsible for. Drag the rows to set the order they appear in when assigning.

To stop offering a role, disable it. Past incidents keep their assignments, and you can re-enable it whenever you want it back. Delete is only for a role no incident has ever used.

Assigning roles during an incident

In the incident channel, run:

/ff roles

An Incident Roles dialog opens with one picker per role, each already showing whoever holds it. Change any of them and save. Firefight posts a single message in the channel summarising what changed.

To assign only the lead, /ff lead still opens a dialog for that one role.

Each role holds one person at a time, so choosing someone new hands the role over rather than adding a second holder. Clearing a picker and saving leaves the role unassigned. The Incident Lead is the exception. Once an incident has a lead it keeps one, so you can hand the lead to someone else but not leave it empty.

Roles stop changing once an incident is resolved or canceled. Every change announces itself in the incident channel, and that channel is on its way to being archived, so Firefight says which role can no longer be changed rather than posting into a room nobody is reading. Reopen the incident if the response is genuinely starting again.

Where roles show up

The lead appears on the incident page and in every incident list across the web dashboard. Anyone catching up can see who is coordinating without opening the incident.

Every other role you have assigned appears in a Roles panel on the incident page, each one next to the person holding it. Roles nobody holds are left out, so the panel shows the roster as it actually stands.

Every change is recorded on the incident timeline, alongside status changes and updates. When you look back at the incident, you can see who took a role and when they took it.

If you forward incidents to your own systems, role changes arrive as webhook events. The lead sends lead.assigned. Every other role sends role.assigned when someone takes it and role.unassigned when it is cleared.

Working with roles from an AI agent

An AI agent connected to Firefight can handle the roster as well as a person can, which is useful when the agent is already triaging the incident.

get_incident returns every role your workspace has defined together with whoever currently holds it, so the agent knows the roster before it changes anything. assign_incident_role then puts one person in one role, or clears it.

The same rules apply as in Slack. One person per role, and the lead can be handed over but not left empty. See Connect AI agents.