Incident forms

Incident forms are the dialogs responders fill in at key moments of an incident’s life. Firefight ships four of them with sensible defaults, and Settings → Forms lets you tune each one, which fields appear, in what order, and which are required, without any responder retraining. Slash commands simply start showing the updated dialog.

The four lifecycle forms

Form	When responders see it
Declare	When someone declares an incident with /ff new
Update	When someone posts a status update with /ff update
Resolve	When the incident is resolved or closed with /ff resolve or /ff close
Cancel	When an incident is cancelled with /ff cancel as not a real incident

The same four forms open from the dashboard, so whatever you configure here is asked on both surfaces. See Running an incident from the dashboard.

Every form works out of the box with built-in fields such as the incident’s name, severity, and summary. You only need to touch Settings → Forms when you want to change what gets asked.

The Cancel form is the exception. Nothing on it is switched on to begin with, so /ff cancel dismisses a false positive in one step with no dialog at all. Turn something on, or add a custom field such as “Cancellation reason”, and the dialog starts appearing.

Editing a form

Pick a form from the list on the left. The editor shows each field the way responders will see it, with a preview of its input. For every field you can:

• Reorder by dragging the handle next to the field.
• Show or hide with the Visible toggle. Hidden fields stay configured but disappear from the dialog.
• Require or make optional with the Required toggle. A few essential fields are locked as required and cannot be hidden or made optional.

Some fields are listed switched off rather than missing, so you can see everything a form is able to ask before deciding to ask it. A field can also carry a line explaining that responders will not be asked it yet, which happens when there is genuinely nothing to choose.

Conditional fields

Fields can appear only when they are relevant. Click Add condition on a field and pick what it depends on, then choose is one of or is not one of and the values that count. A field with several conditions shows only when all of them hold.

A condition can depend on the incident’s Incident Type, Severity, Status or Visibility, or on a single-select, multi-select or catalog custom field. The picker only offers what responders actually answer on this form or on the forms before it. The Update form can depend on answers from Declare and Update, Resolve on Declare, Update and Resolve, and Cancel on Declare, Update and Cancel.

The dialog follows the answers as they are given, in Slack and on the dashboard alike. Pick a severity and the fields that depend on it appear or disappear straight away.

Tip

Use conditions to keep the Declare form short. A “Customer communication owner” field that only appears for your highest severities keeps low-stakes declarations fast while still capturing what matters when it counts.

Adding custom fields

Click Add custom field on a form to attach any field defined in Settings → Custom Fields. The same field can be attached to several forms, so a value requested at declare time can be revisited at resolve time. Attached custom fields can be reordered, hidden, required, conditioned, and removed just like you would expect. Removing a custom field from a form does not delete the field definition or any values already captured.

If the field you need does not exist yet, create it first. See Custom fields for field types and option sources.

Over the API and MCP

GET /api/v1/forms/:slug reads one form and every field on it, hidden ones included, and PATCH changes one field at a time. The get_form and upsert_form_field MCP tools do the same. Sending conditions replaces the set on that field rather than adding to it, and the four forms cannot be created or removed. See Using the API.