How to Configure Major Issue Management for Case Types?

[Sandhya Gurram]

When I try to propose a case type record as a major case, the system automatically creates a base case as the major case instead of using the selected case type. I couldn't find any official documentation to configure it for case types. 

[Shruti]

Hi

It's a limitation. Check page 46 of the attached document

[MattSN]

From the best practices document referenced above.

Case types with Major Issue Management:

• Major issue management enables customer communication for issues that
  impact a wider audience
• There is no need to duplicate major case for every case type. Instead, add the
  ‘Case Type’ specific attribute in the major case to categorize major cases
  
  

Now we just need to clarify what they mean by "add the 'Case Type’ specific attribute in the major case to categorize major cases".

In the "Approve Major Case Candidate" UI Action, there is a call to 

current.sys_class_name== new sn_majorissue_mgt.MajorIssueManagement(current).ATTR_TABLE_NAME).

This checks your case class and either creates a parent or promotes the existing case record. The simplest solution would be to override the UI action for your case type and have it promote the existing record always using "new sn_majorissue_mgt.MajorIssueManagement(current).promoteMCC(true);"

Alternatively you can change the attribute in the script include and make all major cases create a parent within your case type.

[vishnuvardhanch · Accepted solution]

The issue occurs because the OOB MajorIssueManagementImpl script include uses a fixed table name (sn_customerservice_case).
Because of this, when we promote a case type record to a major case, the system always creates the major case on the base table instead of the actual extended case table.

Steps we follow to fix this

1. Open the extension script include "MajorIssueManagement"
ServiceNow provides an extension script include called MajorIssueManagement, where we can write our override scripts for customization. This script include does not implement anything initially, so here we need to override the parent script include’s initialize() function.

2. Implement the initialize() method
Inside this function, we read the current record and determine its actual table using getRecordClassName().

3. Check whether the current table extends sn_customerservice_case
Using GlideTableHierarchy, we verify the table hierarchy.

4. Override the hard-coded table name
If the current case table is part of the hierarchy, we change this.ATTR_TABLE_NAME dynamically so the major case gets created on the correct table.

Final override (inside MajorIssueManagement)

var MajorIssueManagement = Class.create();
MajorIssueManagement.prototype = Object.extendsObject(MajorIssueManagementImpl, {

initialize: function(current) {

// Call parent implementation
MajorIssueManagementImpl.prototype.initialize.call(this, current);

var baseTable = "sn_customerservice_case";
var tableName = current.getRecordClassName();

// Fetch table hierarchy
var hierarchy = new GlideTableHierarchy(tableName);
var parentTables = hierarchy.getTables();

// If current table extends sn_customerservice_case, update table name
if (parentTables.indexOf(baseTable) > -1) {
this.ATTR_TABLE_NAME = tableName;
}
},

type: "MajorIssueManagement"
});

 

Result

With this override in place, when we promote a case type to a major case, the major case is now created in the same extended case table, instead of always using the base table.