A couple of weeks ago, I was having a conversation with a colleague about the Service Catalog work I was doing for a client. Despite their vast experience with Service Catalog, having worked in the space in many capacities, I was surprised when they had not heard of a couple of new features I mentioned, some of which were release as far back as Paris. It really goes to show how hard it is to keep pace with the velocity of new features added to the Platform. From requestors to developers and catalog owners, there are always new features to be discovered to make the world of work better for you. This conversation inspired me to share some of the new features I have recently discovered with the community. I have also committed some sample configurations to my GitHub repository if you would like to explore these further.
New features for requestors (Paris+)
Delegated request experience
Provides an OOB mechanism to raise a request for multiple users from filling out a single form using a variable type called Requested For.
A Requested Item is raised for each user under the same Request.
The ability to add multiple users can be locked down by role.
The variable will automatically map to a new 'Requested for' field on the Requested Item.
This can also be used to create form logic based on the Requested for the user, instead of waiting for it to be captured using the Request or Order Request Methods.
Attachment variable
Get greater control of attachments on Catalogue items using the new Attachment variable.
Allowed extensions and maximum file size can be controlled by Variable attributes.
The attachments can be easily identified on the Requested Item by the fulfilment team.
You can also use this with UI Policies to control when certain attachments are required, eliminating the need to use Client Script to enforce controls on attachments.
New feature for developers (Quebec+)
Catalogue lookup definition
Instead of creating scripts that look like this
function onChange(control, oldValue, newValue, isLoading) {
if (isLoading || newValue == '') {
return;
}
var ga = new GlideAjax('AjaxXnow');
ga.addParam('sysparm_name', 'getXnowApp');
ga.addParam('sysparm_sysid', newValue);
ga.getXML(callback);
function callback(response) {
var answer = response.responseXML.documentElement.getAttribute("answer");
var xNowData = JSON.parse(answer);
console.log(xNowData);
if (xNowData.sys_id != -1) {
g_form.setValue('it_app_owner',xNowData.owned_by.value, xNowData.owned_by.display);
g_form.setValue('managed_by',xNowData.managed_by.value, xNowData.managed_by.display);
g_form.setValue('support_group',xNowData.support_group.value, xNowData.support_group.display);
g_form.setValue('version',xNowData.version.value);
g_form.setValue('comments',xNowData.comments.value);
}
}
}And this...
var AjaxXnow = Class.create();
AjaxXnow.prototype = Object.extendsObject(global.AbstractAjaxProcessor, {
getXnowApp: function() {
var sysid = this.getParameter('sysparm_sysid');
var xNowData = this._getXnowApp(sysid);
return JSON.stringify(xNowData);
},
_getXnowApp: function(sysid) {
var xNowData = {
sys_id: "-1",
owned_by: {value:'', display:''},
version: {value:'', display:''},
comments: {value:'', display:''},
support_group: {value:'', display:''},
managed_by: {value:'', display:''}
};
var grXnowAppService = new GlideRecord('x_43553_govermenti_xnow_application_service');
if (grXnowAppService.get(sysid) && grXnowAppService.canRead() ) {
xNowData.sys_id = grXnowAppService.getValue('sys_id');
xNowData.owned_by.value = grXnowAppService.getValue('owned_by');
xNowData.version.value = grXnowAppService.getValue('version');
xNowData.comments.value = grXnowAppService.getValue('comments');
xNowData.support_group.value = grXnowAppService.getValue('support_group');
xNowData.managed_by.value = grXnowAppService.getValue('managed_by');
// Return display values to prevent round trip
xNowData.owned_by.display = grXnowAppService.getDisplayValue('owned_by');
xNowData.version.display = grXnowAppService.getDisplayValue('version');
xNowData.comments.display = grXnowAppService.getDisplayValue('comments');
xNowData.support_group.display = grXnowAppService.getDisplayValue('support_group');
xNowData.managed_by.display = grXnowAppService.getDisplayValue('managed_by');
}
return xNowData;
},
type: 'AjaxXnow'
});You can now achieve exactly the same result using Catalog Data Lookup Definitions.
When creating a Data Lookup Definition, select 'Catalog Data Lookup Rule' and populate the Matcher table you want to retrieve data from to auto-populate some fields.
Match on sys_id:
Then configure the fields you want to auto-populate in the 'Catalog Setter Variable Definitions' tab.
Now your variables will auto-populate based on the Matcher variable.
This eliminates the need to write Client Scripts and GlideAjax code, which is arguably one of the most time-consuming design patterns on the platform.
New feature for catalog owners (Rome+)
Catalog Builder - Service fulfilment steps
When creating a Catalog Item in Catalog Builder, select the Process engine 'Flow Designer Flow', and in Rome, the Selected Flow "Step based request fulfilment' becomes available:
This will allow you to create a fulfilment process without needing to create a Flow in Flow Designer.
From here, Tasks, Custom or Manager approvals can be defined to make up your fulfilment process.
This removes the requirement to be trained to use Flow Designer, reducing the time to value for simple Catalog items to be added to the Service catalog.
Honourable mentions
What are your favourite features that others have missed?
Please add your favourite new features to the comments below!
1 Comment
