ServiceNow is a company that provides service management software as a service.
Among all other things, using Service Desk Call, ITIL users can create a call record and while speaking with the customer capture information about an issue. Users can then decide to categorize the call as an incident, a problem, a change, or a service catalog request. The issue will, later on, be processed depending on its type, but can also be additionally qualified as a “Wrong number” call.
To include the Call module in Service Now, first, the admin should activate the Service Desk Call plugin. In our Client’s instance, it was already activated and used. There is a basic OOB list of options for the Call type (Incident, Problem, Request, Change, Hang Up, Wrong Number, Status Call, and General Inquiry), and new options can be added in it. In this case that is “Child Incident”, which means that when a customer calls and reports about an incident that already exists in the system and can be considered as a parent to this new incident, the operator should find that existing parent incident and create this new one as its child.
To implement this, we first added a new field “Parent Incident” to the New Call form that lists all the existing incidents from a lookup form and from which the parent incident is chosen. Then we changed this form’s Business Rule “CallTypeChanged” by adding the code for Child incident creation, taking some of the values for the needed fields from this form (info that the customer provides to the operator during the call like Caller, Impacted User, Location, Short Description) and some from the already existing parent incident (like Subcategory, Configuration Item, Description, Status, Assignment Group, Operational Type). This is how all this looks in the code:
if (ctype == ‘child_incident’) {
//Read the ParentID value from field Parent Incident
//with gr from Incident Table get Parent parameters: Category, Subcategory, Configuration Item, Description, Status, Assignment Group, Operational Type
var grIncident = new GlideRecord(‘incident’);
grIncident.addQuery(‘number’, current.u_parent_incident.getDisplayValue());
grIncident.query();
while (grIncident.next())
{
//with gr from the current.call_type get the following parameters: Caller, Impacted User, Location, Short Description
var ctype = ‘incident’;
var gr = new GlideRecord(ctype);
gr.caller_id = current.caller;
gr.u_impacted_user = current.u_impacted_user;
gr.short_description = current.short_description;
gr.contact_type = current.contact_type;
gr.opened_by = current.opened_by;
gr.comments = current.description.getValue();
gr.parent_incident = current.u_parent_incident;
gr.category = grIncident.getValue(‘category’);
gr.subcategory = grIncident.getValue(‘subcategory’);
gr.description = grIncident.getValue(‘description’);
gr.assignment_group = grIncident.getValue(‘assignment_group’);
gr.u_operational_type = grIncident.getValue(‘u_operational_type’);
// update task work notes
var callerName = current.caller.name;
var taskType = current.call_type.getDisplayValue();
var currentLink = “[code]<a href='” + current.getLink() + “‘>” + current.number + “</a>[/code]”;
var journalEntry = gs.getMessage(“This {0} was raised on behalf of {1} from {2}”, [taskType, callerName, currentLink]);
gr.work_notes = journalEntry;
var sysID = gr.insert();
current.transferred_to = sysID;
var url = ctype + ‘.do?sys_id=’ + sysID;
gs.addInfoMessage(gs.getMessage(“{0} transferred to: <a href='{1}’>{2}</a>”, [current.number, url, current.transferred_to.getDisplayValue()]));
}
}
Benefits and Results
With this solution, we implemented a highly organized process of creating a connection of an already existing incident in the system with a newly created one that can be considered as its “child”.
The process of creating a new incident (which is OOB option in this form) and then spending time making a connection between the two (having in mind that we need to resolve them as a Parent–Child combination), as well as the need for some of the fields in the “child” incident to be copied from the same fields in the “parent” incident, is much more complicated compared to this solution of automatically creating the new incident as a child of the existing parent and copying the needed fields. At the same time, in the Incident table, it is noted how this new incident was created.
It is also easy to notice how this automatic creation of associated incidents is very helpful for the operator who takes the calls from the customers and if not for this option, should go through all this process manually.
