1. IMR Help
  2.    
  3. Incidents and Response
  4.    
  5. Custom Incident Form

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.

💡 Real example we'll use throughout this guide
A security engineer is paged at 03:47 about a suspected credential compromise. They open Xurrent, pick Security Incident, and see a form pre-shaped for exactly that scenario - CVE field, CVSS score, compliance frameworks, and a structured impact summary template. No hunting, no guessing, no missing fields.

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.

  1. Go to Account Settings
  2. Click Custom Incident Form in the left sidebar
  3. 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

Field type What it is Example use
Free text Single or multi-line text input Impact Summary, CVE ID
Number Integer or decimal number CVSS score, Revenue impact estimate
Select Pick one value from a dropdown SLA breach risk (Yes/No), Impact severity
Multi Select Pick one or more values from a list Compliance framework, Region Affected
URL A valid https link Customer ticket link, Runbook link

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.

💡 You are not setting default values or mandatory status here
Those decisions belong to the incident type, not the field itself.
The same field - say, Impact Summary - might be mandatory for a Security Incident but optional for a routine Alert, with different default values for each.
You set that per-type in Step 2.

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

  1. Click Create Incident Type
  2. Give the type a Name - e.g. Security Incident
  3. Optionally enable built-in form sections: Impacted Services and Responders
  4. 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
💡 Default values are one of the most powerful parts of this feature
For Impact Summary on a Security Incident, you can pre-fill a structured template:

"What's happening: [Brief description of the symptom or failure]
Who is affected: [Customer segment, region, or user cohort]
Since when: [Start time, in UTC]
Current status: [Investigating / Identified / Mitigating / Resolved]
Next update: [Time or condition for the next stakeholder update]"

At 3am, the responder fills in the blanks instead of inventing structure.

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

  1. Responder clicks Create Incident
  2. Picks an Incident Type - the form reshapes based on that selection
  3. Fills in the standard fields (Team, Service Affected, Assignee, Title, Urgency, Priority, Summary)
  4. Fills in the custom fields for the type they picked - with any defaults already populated
  5. Optionally adds Extra Properties (see next section) for anything ad-hoc
  6. Clicks Create Incident
Create Incident form with Security Incident selected - showing custom fields for CVE ID, CVSS score, SLA breach risk, Region Affected, Compliance framework

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

Custom fields Extra properties
Where defined Account level, in advance On-the-fly during incident creation
Reusable Yes - use across incident types No - only exists on this one incident
Field type / validation Typed (text, number, URL, select) Untyped - key/value strings only
Filterable in reports Yes No
Good for Data you capture repeatedly One-off notes tied to a specific incident

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
Incident detail view - Custom fields and Extra Fields tables