Skip to main content
All CollectionsCreating and running incidentsCreating a new incident
Customising your incident creation form using Custom Fields
Customising your incident creation form using Custom Fields

Use Custom Fields to tag incidents and capture more information

Chris Evans avatar
Written by Chris Evans
Updated over a week ago

You've declared your first incident with our default settings and now you're wondering if you can edit the incident declaration form to categorise incidents and track additional dimensions such as which teams were involved, what systems were affected, or how many customers were impacted?

You've come to the right place, and yes you can! 😎

πŸ“Š Using Custom Fields

Maybe you have different teams that look after different products, customer journeys or different systems? All these can be turned into Custom Fields, and there are a few reasons customers use Custom Fields.

πŸ“ˆ Enriching their retros & reporting

You might be looking to enrich your understanding of your incidents and narrow down on systemic issues. Or you might just need additional information for compliance or internal reporting purposes.

Either way, Custom Fields can help you answer questions like:

  • 'Which system is most incident-prone?'

  • 'Which customers suffer the most incidents?'

  • 'Which team reacts to incidents the fastest?'

  • 'Which product is most vulnerable?'

  • 'How many incidents involved personal data?'

  • ...

You can capture and visualise all this directly from the Insights, by applying filters off the back of Custom Fields in the Incidents tab, and when you export a CSV of your incidents.

βš™οΈ Triggering specific automations

A very popular use case for Custom Fields is to use them as triggers in Workflows.

For example:

πŸ›  Setting Up Custom Fields

πŸ’‘ Only Admins and Owners can edit Custom Fields.

1️⃣ Head to Settings > Custom Fields

2️⃣ Add and tweak your Custom Field

Clicking on Add New Custom Field will pop up a creation modal from which you can control:

  1. What information to collect

  2. Whether the information is required or optional

  3. When the information is collected (during or after an incident)

Field Types

The field types we support are:

  • single-select

  • multi-select

  • plain text

  • link

  • number

  • timestamp

If there are any more you'd like us to add, please let us know!


The title that will appear on the incident declaration form. The shorter and more explicit, the better!


This will appear as a tooltip for your team in the modal, like so πŸ‘‡πŸΌ

Require this field - this sets whether information is compulsory or optional.


Optional field: an incident can be declared/closed without the field filled

When an incident is created

Compulsory field - an incident cannot be declared without the field filled

Before an incident is resolved

Compulsory field - an incident cannot be marked as resolved without the field filled

This field should be shown - this determines when the field will be visible to users.

On creation

The field will be visible in the incident declaration form (like in the screenshot above)

On resolution

The field will be visible when marking the incident as resolved

On both creation and resolution

The field will be visible in both the incident declaration form and the resolution form

On neither creation nor resolution

The field will not be visible unless you access it via the /inc fields command in the incident's #inc-... channel

⛔️ Think carefully about how you engineer your form

Only require what you absolutely must, and prefer requiring at incident close than at incident start. If you require 5 fields when opening an incident, responders will be forced to provide a 5 value before they begin responding.

If you run into any trouble, want a leg up setting up workflows or would like some best practices on Custom Fields, get in touch! πŸ‘‹

Did this answer your question?