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. Add a condition to a field and it only shows when the incident’s type or severity matches. Conditions support “is one of” and “is not one of” against the incident types and severities you have configured.

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.