Members & access
Everyone who uses Firefight is a member of your workspace. Each member has an access level that decides whether they can change how the workspace is set up, and it stays the same whatever they are doing on any given incident.
How people become members
Section titled “How people become members”There is no invite flow to manage. Anyone in your Slack workspace who uses Firefight becomes a member automatically. Running a /ff command, being picked as incident lead, or signing in to the web dashboard with Slack is enough. Firefight creates the membership on the spot using the person’s Slack profile.
The first person to connect the workspace becomes its owner. Everyone after that joins as a regular member.
The members list
Section titled “The members list”Settings → Members shows everyone in your workspace. For each person you see their name, email, and avatar from Slack, their access level, and when they joined.
| Access | Meaning |
|---|---|
| Owner | The person who first connected the workspace |
| Admin | Can change workspace settings as well as respond to incidents |
| Member | Everyone else who uses Firefight |
Admins and owners can edit the settings screens. Members respond to incidents with the full set of /ff commands, and read the dashboard without being able to reconfigure the workspace. A settings screen a member cannot change shows the same list without the add, edit and reorder controls.
An admin can open a settings screen to a specific member without making them an admin, by granting it under Gateway → Permissions. Grant someone runbooks, and the Runbooks screen gives them the same controls an admin sees, everywhere else stays read-only. Integrations, API keys, Permissions itself, and workspace settings cannot be granted, and stay with admins and owners.
Permissions and Activity under Gateway are visible to admins and owners only. Approvals is visible to everyone, the sidebar shows how many requests are waiting, and approving or denying a request needs the access the request asks for. Activity is the workspace’s audit log: every settings change anyone makes on the dashboard is listed there, alongside what agents and API keys did.
You never need to raise someone’s access to give them a job during an incident. Making a member the Incident Lead leaves their access exactly as it was. See Incident roles.
Granting more than an access level allows
Section titled “Granting more than an access level allows”To grant someone reach beyond their access level, without promoting them, use permission sets. They are additive bundles you can grant to a person, an API key, or an AI agent. See Permissions.