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?'
⚙️ Triggering specific automations
A very popular use case for Custom Fields is to use them as triggers in Workflows.
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
#customer-supportchannel when high-value customers are affected by an incident
Send 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
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)
The field types we support are:
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.
The field will be visible in the incident declaration form (like in the screenshot above)
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! 👋