Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field

Hi there,

When retrieving Update Sets on an instance, ever came across an issue concerning "Update Scope Id is different than Update Set Scope Id"? This sometimes occurs, a Customer Update being captured in your Update Set which is in a certain Application Scope, while the actual artifact being updated resides in a different Application Scope. Due to this issue, you can't commit the Update Set.

What can we do about this? Some ideas:- Creating an Instance Scan Scan Check;- Adding a validation on the Update Set concerned;

- Automatically moving the Customer Update.

In this article I'll focus on the second idea, applying a validation on the Update Set concerned. A validation which would show an error message when displaying the Update Set.

Update Scope Id is different than Update Set Scope Id

Here an example of the issue concerned. The issue prevents Update Sets from being committed on the target instance.

Basically, this example is about a Business Rule which is captured in an Update Set which is in the "Global" Application Scope. While the Business Rule itself, is actually in the "Service Portal - Standard Ticket" Application Scope.

Adding a validation on the Update Set

Instead of noticing this issue on the target instance, when the Update Set is already retrieved and previewed, let's add a validation on the source instance. A validation which detects if there are any Customer Updates captured in an Update Set in a different Application Scope. This will help the administrator or developer handling the Update Set, to already notice the issue before closing the Update Set.

My thought for this is applying a display Business Rule with a condition of "stateINin progress,completeEQ" on table "sys_update_set", which queries if there are any Customer Updates captured in an Update Set in a different Application Scope, and if so displays an error message concerning the issues and a hyperlink to the Customer Updates concerned.

(function executeRule(current, previous /*null when async*/) {

    var gaCustomerUpdate = new GlideAggregate('sys_update_xml');
    gaCustomerUpdate.addEncodedQuery('update_set=' + current.getUniqueValue() + '^applicationNSAMEASupdate_set.application');
    gaCustomerUpdate.addAggregate('COUNT');
    gaCustomerUpdate._query();

    if(gaCustomerUpdate._next() && gaCustomerUpdate.getAggregate('COUNT') >= 1) {
        var plural = '';
        if(gaCustomerUpdate.getAggregate('COUNT') > 1) {
            plural = 's';
        }

        gs.addErrorMessage(gs.getMessage('Update Scope Id is different than Update Set Scope Id for <a href="{0}" target="_blank">{1} Customer Update{2}</a>.', ['sys_update_xml_list.do?sysparm_query=update_set%3D' + current.getUniqueValue() + '%5EapplicationNSAMEASupdate_set.application', gaCustomerUpdate.getAggregate('COUNT'), plural]));
    }

})(current, previous);

This will still allow the administrator or developer to change the State of the Update Set to Complete. If wanting to prevent this, we could add an onLoad Client Script which removes the "Complete" option from the choices. The Client Script, using a Scratchpad object which we would add to our Business Rule. So let's expand the Business Rule with below line:

g_scratchpad.scope_id_issues = true;

The onLoad Client Script on table "sys_update_set" would only contain the below following script:

function onLoad() {

    if(g_scratchpad.scope_id_issues) {
        g_form.removeOption('state', 'complete');
    }

}

The above Business Rule and Client Script concern the Update Set itself. Let's add a validation on the Customer Update as well. Adding a display Business Rule with a condition of "applicationNSAMEASupdate_set.applicationupdate_set.stateINin progress,completeEQ" on table "sys_update_xml".

(function executeRule(current, previous /*null when async*/) {

    gs.addErrorMessage(gs.getMessage('Update Scope Id ({0}) is different than Update Set Scope Id ({1}).', [current.getValue('application'), current.update_set.application.getValue()]));

})(current, previous);

Result

While reviewing the Update Set and normally changing the State to "Complete", the administrator or developer now is instantly informed about the issue. This allows the administrator or developer to fix the issue on the source instance, before even retrieving the Update Set on the target instance. This saves time, frustration, and prevents issues if you actually automated your Update Set cycle on higher instances.

In a future article, I'll share a thought on automatically moving the Customer Update, to an Update Set in the same Application Scope.

Share

An Update Set with the Business Rules and Client Script can be downloaded from Share:

- Detecting "Update Scope Id is different than Update Set Scope Id"

---

And that's it. Hope you like it. If any questions or remarks, let me know!

Kind regards,

Mark Roethof

ServiceNow Technical Platform Architect @ Eraneous

2x ServiceNow Developer MVP

2x ServiceNow Community MVP

---

LinkedIn