Transferring a Case

shegde
Giga Contributor

I'm trying to work through an alternate way to transfer a Case by switching the COE and HR Service values in the existing case, rather than cancelling and recreating. I'm coming across a bunch of items that I need to account for, and wanted to see if there was a simpler way to get to it.

I'm making changes in the 'Transfer Case' UI page, and specifically the processing script section. This is what I currently have:

(function(_this) {
	var originalTask = new GlideRecord(task_table_name);
	if (!originalTask.get(task_sys_id)) {
		gs.addErrorMessage(gs.getMessage("Could not find original case"));
		return;
	}
	var service = new GlideRecord("sn_hr_core_service");
	if (!service.get(selected_service)) {
		gs.addErrorMessage(gs.getMessage("Could not find selected service"));
		return;
	}

    // Update Original Task
    
	originalTask.template_invoked = false;
	originalTask.workflow_invoked = false;
	originalTask.assigned_to = '';
	originalTask.assignment_group = '';
	originalTask.skills = '';	
	originalTask.fulfillment_instructions = service.fulfillment_instructions;
	originalTask.hr_service = service.sys_id;
    originalTask.topic_category = service.topic_detail.topic_category;
    originalTask.topic_detail = service.topic_detail;
    originalTask.sys_class_name = service.topic_detail.topic_category.coe;
	originalTask.template = service.template;
	originalTask.short_description = service.name + ' case for ' + originalTask.subject_person.name;
	
	// Query for the Service's checklist
	var srvChklst = new GlideRecord('checklist');
	srvChklst.addQuery('table','sn_hr_core_service');
	srvChklst.addQuery('document', service.sys_id);
    srvChklst.query();
    
	/**
     * If Service Checklist exists, copy the checklist and checklist Items for the case.
    */
    if (srvChklst.next()) {
        var table = task_table_name;
        var checklistId = '';
        var list = new GlideRecord('checklist');
        list.name = srvChklst.name;
        list.document = originalTask.sys_id;
        list.table = table;
        list.insert();

        var getItems = new GlideRecord('checklist_item');
        getItems.addQuery('checklist', srvChklst.sys_id);
        getItems.query();
        while(getItems.next()) {    
            var cpItem = new GlideRecord('checklist_item');
                cpItem.checklist = list.sys_id;
                cpItem.complete = false;
                cpItem.name = getItems.name;
                cpItem.order = getItems.order;
                cpItem.insert();
        }
    }
	
	originalTask.update();
  

	gs.addInfoMessage(gs.getMessage("Case was transferred to " + service.getDisplayName() + " service."));
	response.sendRedirect(service.topic_detail.topic_category.coe + ".do?sysparm_query=sys_id=" + originalTask.getUniqueValue());
})(this);

I've been able to account for some of the HR Service details, including template, fulfillment instructions and Checklist items, and it works. But I also need to take care of any open SLAs, workflows etc. Is there a way I can invoke the rules and scripts that kickoff on Case creation to automatically take care of everything, or do I need to work through each one by one in the script?

1 ACCEPTED SOLUTION

Kiel Sanders
ServiceNow Employee
ServiceNow Employee

This is one of the many reasons we chose not to update an existing case and instead create a new case for the Transfer Case action.  Updating the existing case can cause some concern because there are many pieces of the original case that need to be accounted for such as workflows currently, reapplying the HR Service items/template, how to handle SLAs, changes in security between cases, etc.

We've also made a number of enhancements to the Transfer Case functionality in recent releases.  In Kingston we added a "Transferred to" field that creates a bi-directional link between cases involved in a transfer ("Transferred from" field already exists).  We've also updated the case screen in the Employee Service Center to allow employees viewing a canceled case to redirect back to the new case (screenshot below).

find_real_file.png

In London we've made enhancements to the notifications so that employees only receive one unique transfer email as opposed to the generic new case and case closed notifications.  In addition, we also modified the inbound actions so that any email reply back to the original transferred case will update the new case.

View solution in original post

3 REPLIES 3

Sylvia Fong
Kilo Contributor

I would love to know too!  Please share if you have more info from others

Kiel Sanders
ServiceNow Employee
ServiceNow Employee

This is one of the many reasons we chose not to update an existing case and instead create a new case for the Transfer Case action.  Updating the existing case can cause some concern because there are many pieces of the original case that need to be accounted for such as workflows currently, reapplying the HR Service items/template, how to handle SLAs, changes in security between cases, etc.

We've also made a number of enhancements to the Transfer Case functionality in recent releases.  In Kingston we added a "Transferred to" field that creates a bi-directional link between cases involved in a transfer ("Transferred from" field already exists).  We've also updated the case screen in the Employee Service Center to allow employees viewing a canceled case to redirect back to the new case (screenshot below).

find_real_file.png

In London we've made enhancements to the notifications so that employees only receive one unique transfer email as opposed to the generic new case and case closed notifications.  In addition, we also modified the inbound actions so that any email reply back to the original transferred case will update the new case.

Hi @Kiel Sanders ,

Could you please let me know if the OOB 'Transfer with existing case number' transfer type .

Is this recommended way I can show my client about Transfer Case functionality . 

When I am trying this , I get below error .

find_real_file.png