Introduction
ServiceNow released in Vancouver a new feature as part of the 'Supplier Lifecycle Operations' product, which enables internal employees to create cases from the Workspace, on behalf of Suppliers. This feature might be useful for example when the Supplier contacted the Helpdesk Agent through a phone call, and the Case must be registered into the system for audit purposes.
Challenge
Some case types, such as 'General Inquiry' might be quite straight forward to be created from the Workspace, as the fulfiller, either the Agent or the Supplier Contact, might only need to provide some basic information while creating the case, which is basically mapped to some standard fields in the Case table, such as Short Description, Description, etc.
However, the challenge might come when the Record Producer for that specific case type contains multiple fields to be filled in, and a more complex mapping into the target table.
Would it be possible to create one field at the Case table for each of these? Yes, of course. Nonetheless, the more different request types that would be offered to the Suppliers, the more fields would be required in the Case table and form, with the risk of ending up with a very complex solution, which would be very difficult to maintain, and even having the risk of performane problems while loading a case with too many fields in it.
So, how did ServiceNow solve this for the existing case types?
Out-of-the-box Solution
In the out-of-the-box (OOTB) solution, there are currently 3 different case types which require this kind of additional information to be provided to correctly complete the process.
These are: Supplier information change request, Supplier location change request, and Banking information change request.
And the solution basically consists on offering the Agents an 'Add More Details' button which opens a pop-up with the information that must be filled in order to replicate the information that Suppliers would have provided when creating the Case form the Supplier Collaboration Portal.
That's great! Is not it? We do not need to create more fields in our Supplier Case table, as their mapped as variables, emulating the process we have from the Portal, and having a consistent and unified user experience regardless of the source the Case was created from.
But now, how can that functionality be extended for custom case types?
Extension for custom case types
It is quite standard to create custom case types in the system when trying to meet some business requirements which are not covered by the out-of-the-box functionalities. In addition, it is recommended to maintain a common user experience in the system so that Agents can maintain a standard way of working.
Thus, in the next steps, it is explained with a basic example, how to extend this feature to a custom case type:
- Create the new custom Case type: We need to navigate to the Dictionary for Service Case [sn_spend_sdc_service_request] table, and in the Choices related list, create the new entry.
Note: Supplier Case [sn_slm_case] table extends Service Case table, which is where the 'Case Type' fields belongs to. That's why the modification must be done at that level.
To provide an example, it might be interesting to allow Suppliers request a new relationship with the Legal Entities in the company, so that the process can be automated without the need of manual intervention. So, in the example below, a new 'Associate Legal Entity' (associate_legal_entity) case type is created as detailed:
- Create Record Producers: In order to create new cases for the case type created in the previous step, we should create Record Producers. And yes, in this case is in plural. Not only one.
One Record Producer would be created to allow Suppliers create cases of the new type created (External-exposed), whereas another one must be created as well to allow Agents create cases of this new type on behalf of the users (Internal-exposed).
So, these two record producers can share a lot of variables in common, and therefore it would be useful to create those as part of a variable set.
However, there might be some differences to be considered for these two record producers:
1. The audience must be clearly restricted, and while the External one must be restricted to users without a Supplier role, the Internal one should also be restricted to external users.
2. The Internal one, does not need to be associated to any catalog and SHOULD NOT be set with any Category, so that it can't be searched in the Portals, because the idea is to make it available only to the Agents from the Workspace.
3. While some of the variables can be shared between these two, some others should not. The Supplier fields must be automatically populated for the Internal one with the value of the Case which Agents are adding the details from.
Therefore, a new reference variable must be created with these values:
Map to field = false; Type = Reference; Question = Supplier; Name = Supplier; Reference = Supplier [sn_fin_supplier]; Use reference qualifier = Simple.
As well as an onLoad client script to autopopulate the Supplier value from the Case. For this, we can reuse some OOTB functions:
function onLoad() {
var url = top.location.href;
var currentRecordSysId = url.match(/sn_slm_case\/([^/]+)/)[1]; // Gets sys_id from url
try {
var ga = new GlideAjax('sn_slm.SupplierCommonAjaxUtil');
ga.addParam('sysparm_supplier_case_id', currentRecordSysId);
ga.addParam('sysparm_name', 'getSupplierFromCase');
ga.getXML(updateColumn);
} catch (e) {
throw e;
}
function updateColumn(response) {
try {
var answer = response.responseXML.documentElement.getAttribute("answer");
if (answer)
g_form.setValue('supplier', answer);
} catch (e) {
throw e;
}
}
}
- Modify Declarative Action: The OOTB 'Add More Details' button is implemented by a Declarative Action. And then, it should be modified in order to include the new case type in its conditions, so that it can appear available in the Workspace.
To do it, access to Now Experience Framework > Declarative Actions > Form Actions, and search for this one (Name = Add more details; Table = Supplier Case [sn_slm_case]; Sys_Id = 8d64a60f438671104beb89e90db8f2c4).
Access the form for that Action, and modify the 'Record Conditions' field to include the new case type created.
Note: If that field is not shown in the form, it might be needed to modify the Form Layout to make it visible, depending on the view you are editing that record.
Note: For more information about Declarative Actions, please visit the following link: https://www.servicenow.com/community/developer-blog/declarative-actions-in-servicenow-the-complete-g...
Now, when creating a case from the Workspace for the custom type created, the button is visible, however it does not have any functionality.
- Connect the Case Type with the Record Producer: In order to make the button open the pop-up with the record producer we created in the previous step (Internal-exposed), access to UI Builder > 'Page Collections' tab >S2P SLM Record Page Modals > Case Modal. Once opened, go to the 'Client state parameters' section, and modify the 'catalogItem' JSON object to include the new case type and external Record Producer sys_id.
After applying these changes, the button must already open the Record Producer created.
However, there is still one final step to cover the OOTB experience for the new case type.
- Restrict Submission for the new Case type: In the OOTB experience, Agents are not allowed to submit the case by clicking on the 'Submit Case' button unless the variables for that case type have been filled in. So, in order to be consistent with this experience, access System UI > UI Actions and search for Name = Submit Case and Table = Supplier Case [sn_slm_case] (Sys_Id = 0b6b6bfe378831106c13e7d734924ba4). The script of this UI Action contains a verification step to allow the user proceed or not depending on the conditions below:
if ((new sn_slm.SupplierCommonUtil().isCaseTypeNeedVariables(current)) && !(new sn_slm.SupplierCommonUtil().isCaseDetailsFilled(current))) {
This needs to be updated so that 'isCaseTypeNeedVariables' function includes the new custom case type created.
To do it, access System UI > Script Includes, and first open the OOTB 'SupplierCommonUtilSNC', in which that function is defined. Copy the function and then open the 'SupplierCommonUtil' Script Include, in which the function must be overwritten to include the new case type:
var SupplierCommonUtil = Class.create();
SupplierCommonUtil.prototype = Object.extendsObject(sn_slm.SupplierCommonUtilSNC, {
CASE_TYPE_NEED_VARIABLES: ['update_banking_details', 'update_supplier_profile', 'add_or_remove_location', 'associate_legal_entity'],
initialize: function() {},
isCaseTypeNeedVariables: function(supplierCase) {
var caseGR = new GlideRecord(this.SUPPLIER_CASE_TABLE);
if (caseGR.get(supplierCase.sys_id)) {
var case_type = caseGR.getValue("case_type");
if (this.CASE_TYPE_NEED_VARIABLES.indexOf(case_type) > -1) {
return true;
}
}
return false;
},
type: 'SupplierCommonUtil'
});
