Insights & updates from our experts
Custom Incident Form
Why this exists
The default incident form works, but it treats every incident the same. A late-night CPU spike gets the same form as a data breach affecting production. Responders end up either capturing too little information at 3am, or fumbling through a long form with fields that aren't relevant to the situation.
Custom Incident Form fixes this by letting admins configure two things:
- Custom fields - The information worth capturing for your team's incidents
- Incident types - Which fields show up on the form for each kind of incident
The result: a responder declaring a Security Incident sees CVE ID, CVSS score, and compliance frameworks. A responder declaring a routine Alert sees a short form with just the essentials. Same product, right form every time.
How the pieces fit together
Three concepts, in the order you set them up:
1. Custom fields
The building blocks. Define a field once (its name, type, and options if applicable), and it becomes available to attach to any incident type.
Examples: Impact Summary, CVE ID, CVSS score, Region Affected, Customer ticket link.
2. Incident types
The situations your team responds to. Each type has its own set of custom fields (chosen from the shared pool), each field's default value, and each field's mandatory status.
Examples: Alert, Security Incident, Major Incident, Sev0, Sev1.
3. Incident form
The runtime experience. A responder picks an incident type first - the form reshapes to show that type's custom fields, in the configured order, with any defaults pre-filled.
Accessing Custom Incident Form
Only account admins and owners can configure this feature.
- Go to Account Settings
- Click Custom Incident Form in the left sidebar
- You'll see two tabs: Custom fields and Incident types
Step 1 - Create your custom fields
Start in the Custom fields tab. This is a shared pool of field definitions that all incident types can draw from.

Field types supported
Field type
Creating a field
Click Create Custom fields, then in the dialog:
- Field Type - Choose a Field Type - this determines how responders will enter data
- Field Name - Give the field a clear Name - this is the label responders see on the form
- Options - For Select and Multi Select fields, add the values responders can choose from
Click Submit to save. Repeat for every field you want available across your incident types.
Example field pool for a security-focused setup
- Impact Summary - Free text - captures a structured description of what's happening
- CVE ID - Free text - for the standard vulnerability identifier (e.g. CVE-2026-1234)
- CVSS score - Number - the severity score from 0.0 to 10.0
- SLA breach risk - Select - Yes / No
- Region Affected - Multi Select - EU, US, APAC, LATAM, MEA
- Compliance framework - Multi Select - GDPR, SOC2, HIPAA, PCI-DSS, CCPA
- Customer ticket link - URL - link to the linked support ticket
- Revenue impact estimate - Number - dollar impact for financial reporting
Step 2 - Create your incident types
Switch to the Incident types tab. Each incident type represents a distinct kind of situation your team handles.
Creating a type
- Click Create Incident Type
- Give the type a Name - e.g. Security Incident
- Optionally enable built-in form sections: Impacted Services and Responders
- Attach custom fields from the shared pool
Configuring each attached field
For every custom field you attach to an incident type, you decide:
- Order - Drag the handle to control where the field appears on the incident form
- Default value - Pre-populate the field with a starting value that responders can accept or edit
- Required - Toggle whether responders must fill this field to create the incident

Step 3 - What responders see
Once you've configured your fields and types, the Create Incident flow adapts to what you've set up.
The flow
- Responder clicks Create Incident
- Picks an Incident Type - the form reshapes based on that selection
- Fills in the standard fields (Team, Service Affected, Assignee, Title, Urgency, Priority, Summary)
- Fills in the custom fields for the type they picked - with any defaults already populated
- Optionally adds Extra Properties (see next section) for anything ad-hoc
- Clicks Create Incident

The custom fields load in the order the admin set up. Any field with a default value is pre-filled. Any field marked required will block submission until it has a value.
Extra Properties - ad-hoc key/value pairs
Sometimes a responder needs to attach information to a specific incident that doesn't fit any predefined custom field. Extra Properties handle this.
At the bottom of the Create Incident form (and on the incident detail view), responders can add any number of key/value pairs - for example, adding a conference bridge URL for this specific war room, or a one-off note that isn't worth adding as a permanent custom field.
When to use Extra Properties vs. a Custom field
Viewing the data on an incident
Custom field values show up in two places on the incident detail view.
In the header bar
The incident type is displayed prominently at the top of the incident, next to Assignee, Escalate To, SLA, Priority, and Urgency. This tells everyone joining the incident what kind of situation they've walked into.
Under the Details tab
Two tables appear:
- Custom fields - Shows every custom field attached to this incident type, along with the value the responder entered
- Extra Fields - Shows the ad-hoc key/value pairs the responder added at creation time. New pairs can be added here at any point during the incident










.webp)




.webp)

.webp)

.webp)











