In the first article of that series I've introduced a concept to document ACL effectively. Now, in the second step, the focus is on uncovering and eliminating the differences regarding ACLs between instances.
Identify the difference
To find out the differences between certain instances your only chance is to compare the individual records one by one.
For this purpose, to make access to the corresponding ACLs as easy as possible, I have linked the labels of the different ACL types with the preconfigured list views on the DEV instance in the documentation table already presented:
In the next step, the respective lists must be opened in the comparison instance. If you have a lot of ACLs to compare with each other, this can quickly become very time-consuming, which is why I have built two simple but extremely useful UI actions "Open in TEST" and "Open in PROD"
These UI actions work both in the Form View and in the List View, as they simply replace the domain name in the current URL and then open this modified URL in a new tab.
In the following screenshot, you can find all configurations for such a UI Action. Due to the chosen table sys_metadata the buttons will appear on all form & list view of real artifacts like ACLs, Business Rules, Script Includes etc:
For the easiest possible visual comparison of records in different instances, the list layout configurations should be identical. I also found it extremely helpful to display the Sys IDs in the first column (for example, using the SN Utils browser extension) and then sort the "Sys ID" column.
Only this way I came across a rather strange and very annoying characteristic: Some (but not all) ACLs have different Sys IDs on all instances!! This means, for example, that it is not possible to modify such an OOTB ACL on DEV (e.g. deactivate it) and then transport it to the next instance via an Update Set, as two ACLs for the same topic would then overlap on the target instance and the ACL that is still activated would win:
To indicate such ACLs, which must be maintained manually in all cases, I have introduced a red asterisk in the documentation:
Document the changes
Having arrived at this point, you have to think about which actions are required to transition from the current state to the target state. In order to keep these activities close to the existing documentation, I have inserted additional rows in the Confluence table and added to them expandable areas with the help of the Confluence {expand} macro. All necessary adjustments can now be documented in these areas.
It is up to you how exactly you want to document the status and progress of all the required activities. One option is to use Jira tickets, which reflect the live status using the {jiraissues} macro.
Another option I prefer is using one of the available emoticons, like the green checkmark, to indicate a finished issue/task. And the red background color of the underlying table cell only act as eye-catcher as the overall table can be become really gigantic!
Capture and Transfer
There are different options to transfer artifacts from one instance to another in ServiceNow and I can't cover them all here in this article.
For capturing all ACL modifications, I prefer an individual Update Set with single child Update Sets for each table:
A fresh version of that batch Update Set will always be deployed on the target instance after each and every release - independent of whether any ACL changes have been made or not recently.
In my opinion, this approach has several advantages:
- Since ACLs are probably the most sensitive part of an implementation, it is important to have all customizations collected in one place.
- Each new deployment ensures that any manual (and therefore unauthorized) adjustments to the target instance are restored to the intended configuration.
Conclusion
Getting from the (chaotic) current state to the clear target state requires a lot of discipline in recording all adjustments and a very good understanding of how ACLs work - otherwise the situation will only get worse. However, with the help of the documentation approach presented here, you can maintain an overview and transparently present the decisions that led to the changes.
