Separate Resolution Codes for Incidents vs Major Incidents (Same Incident Table)

[lvenna]

Hello All,

In ServiceNow, both Incidents and Major Incidents use the same Incident [incident] table.

Is there a way to maintain separate Resolution Codes for:
• standard Incidents, and
• Major Incidents

Since Major Incidents are differentiated only by flags/states (but still remain in the same table), I’m not seeing a clean way to segregate resolution codes without impacting normal incidents.

Has anyone implemented this requirement before?
Looking for best-practice or platform-supported approaches.

Thank you,

Laxma.

[SumanthDosapati]

@lvenna 

1. Navigate to dictionary entry of Resolution code field and switch to Advanced view
2. In Dependent field tab, tick the checkbox and choose 'Major Incident State' as dependent field.
3. Create new resolution code dropdown choices that you want for major incident and while creation, in the dependent value field, give the value of Accepted from Major Incident State.

Another approach would be managing the choices through client script. 

Accept the solution and mark as helpful if it does, to benefit future readers.
Regards,
Sumanth

[Brad Bowman]

You would add all of the choices, then use a Client Script similar to this to remove each choice for each type

function onLoad() {
	if (g_form.getValue('promoted_on') == '') {
		//not a Major Incident
		g_form.removeOption('close_code', 'Duplicate');
	} else {
		//Major Incident
		g_form.removeOption('close_code', 'Known error');
	}
}

[Chaitanya ILCR]

Hi @lvenna ,

1. you can use a client script and hide/show some options based on the major incident state 

or

you can create new field (Is major incident?) a checkbox and you can use a BR to update this based on the major_incident_stae field and in the dictionary

you can set the major incident related resolution code choices dependent value to true and others to false

Note: after creation of the new field you would have to run a fix script to set the new field to true for major incidents 

Please mark my answer as helpful/correct if it resolves your query.

Regards,
Chaitanya

[Itallo Brandão]

Hi Laxma,

Since both types of incidents reside on the same table, there is no OOB "switch" to segregate the Choice List based on the Major Incident state. However, this is a very common requirement.

Here are the two approaches to achieve this. Option 1 is generally considered the best practice for flexibility and UX.

Option 1: Client Script (The "Filter" Approach)

Since the Resolution Code field is likely a Choice List (not a Reference field), the standard way to manipulate the available options is using g_form.removeOption().

Implementation:

1. Define the Superset: Add ALL necessary resolution codes (both Standard and Major) to the choice list for the close_code field.

2. Create an onLoad Client Script: This script checks if the incident is a Major Incident and filters the list accordingly.

Sample Logic:

function onLoad() {
    var isMI = g_form.getValue('major_incident_state'); // Check field name, usually 'major_incident_state'
    var miStateAccepted = 'accepted'; // Check the value for 'Accepted'

    if (isMI == miStateAccepted) {
        // It IS a Major Incident - Remove Standard Codes
        g_form.removeOption('close_code', 'solved_workaround');
        g_form.removeOption('close_code', 'user_education');
    } else {
        // It is a Normal Incident - Remove MI specific codes
        g_form.removeOption('close_code', 'infrastructure_failover');
        g_form.removeOption('close_code', 'emergency_change');
    }
}

Note: You might need an onChange script as well if users can promote an incident to Major dynamically on the form, though usually, that happens via UI Action/Workspace.

Option 2: Dependent Values (The "No-Code" Approach)

You can configure the close_code choice list to be Dependent on the major_incident_state field.

1. Right-click the Resolution code label > Configure Dictionary.

2. In the Dependent Field tab, select major_incident_state.

3. Go to your Choices (sys_choice list).

4. For every resolution code, you must now populate the Dependent value column.

   • Set Standard codes to have a dependent value of proposed or canceled (or whatever the non-MI state is).

   • Set Major codes to have a dependent value of accepted.
     
     

Why Option 1 is usually better: Option 2 is rigid. If major_incident_state is empty or changes, your choices might disappear unexpectedly. Also, if close_code is already dependent on state or category, you can't easily add a second dependency without custom scripting anyway.

A Critical "Watch-out"

Remember that Major Incidents often require a Post Incident Report (PIR). Best Practice Recommendation: Instead of cluttering the Incident close_code, many organizations prefer to keep the Incident Resolution simple (e.g., "Restored") and capture the detailed "Root Cause" and "Resolution Method" in the PIR (Post Incident Report) record, which is a separate table/tab specifically designed for Major Incidents.

Hope this helps you choose the right path!

If this response helps you achieve your requirement, please mark it as Accepted Solution.
This helps the community grow and assists others in finding valid answers faster.

Best regards,
Brandão.