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 incident.io 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 incident.io 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:
Escalate to specific teams/teammates based on the severity of an incident, or the product it affects
Send an email to only the 3rd parties affected by an incident
Message the
#customer-supportchannel when high-value customers are affected by an incidentSend a Slack message to a specific Account Executive when their customer is affected by an incident
🛠 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:
What information to collect
Whether the information is required or optional
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!
Name
The title that will appear on the incident declaration form. The shorter and more explicit, the better!
Description
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.
Never | 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 |
⛔️ 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! 👋