We decided to write this article after learning from a ServiceNow subject matter expert (SME) that most implementers create their own access control lists (ACL’s) instead of configuring the ‘out of the box’ solution from ServiceNow, which is based on COE (Center of Excellence) Security policies.
When the ServiceNow SME, that was reviewing a project for us, praised us for sticking to ‘out-of-the-box’, I was surprised. For me, this was the obvious best solution, but he told me that most didn’t. I guess the reason is that for getting COE Security Policies to work, you need to understand the configuration, and also learn what implications it may have to use your own custom ACL’s instead.
If you know how to use COE Security Policies properly, you wouldn’t find yourself in a position where custom ACL’s are necessary. And as you’ll learn from this article, using your own ACL’s (like most do) might give you or your company a headache or two further down the road.
COE stands for Center of Excellence and is part of the HR Module in ServiceNow, as the logical representation of an HR function (as a table in ServiceNow). Figure 1 shows how the different COE’s are structured:
Figure 1
Now, from figure 1, imagine that between each of these COE’s, you can have restrictions for each based on conditions. The structure of the COE and its relation to HR Services, can be seen in figure 2.
Figure 2
In case you are not familiar, COE Security Policies are the rules we can set up in the HR module, restricting which groups are allowed to read or write (or both) on a particular HR Case, based on conditions that you define. In figure 2, at the bottom, you have three HR Services. All of these can be conditions on which to base your COE Security Policies, and thereby set up ‘borders’, between each COE.
You can also have multiple COE Security policies which can either be ‘Applied to all services’ is true or false. When you have multiple COE security policies it looks at all COE security policies and allows the user read -or write-access to the record, if just one of the rules matches.
The answer to this is related to upgrades of the ServiceNow platform. For each upgrade you have to make sure that everything is working as intended. COE Security Policies are out of the box records from ServiceNow where you “just” define conditions for and define records in the reference fields.
This means that if something goes wrong, you can get help from ServiceNow on these matters. And if they improve the functionality over time concerning the COE Security Policies, you will also benefit from this.
If you create your own custom ACL’s, you must maintain and troubleshoot them on your own and provide documentation on it. This can easily go wrong and result in that the scaling of your custom ACL’s is not sufficient in a year. It can be a slippery slope, which is not necessary in my opinion.
Imagine that you have three Payroll Services, on the HR Payroll table (COE) as seen in figure 2; “Payroll Discrepancy”, “Direct Deposit Setup” and “Direct Deposit Inquiry”.
Here, it would be an obvious case to have a COE Security Policy that goes something like this:
In the Groups section, you add the ‘Payroll’ group, which will be allowed to read HR cases, when one of those HR Services are on the case. The COE (HR table) would be “sn_hr_core_case_payroll”, Active is True and Type is Read. You would then create the same COE Security policy with exact same values, only this time with the type ‘Write’.
Imagine the same scenario, but instead of creating several COE Security policies to do the same, you can tweak this a bit. One of the most powerful aspects you can utilize is the condition ‘Assignment group is (dynamic) | One of my groups’, as seen in figure 3.
This means that only when it is assigned to a group you are a member of, and if that group is on the list of allowed groups here in the COE Security Policy, they will be granted access.
There are many ways you can utilize the conditions in COE Security Policies, but it all depends on your data structure. For example, if you just want a specific type of groups, you can use the ‘Type’ field on the Group records as such.
The Type field can be very powerful, and can represent anything you want really; a region, a collection of groups, a functional discipline within your organization and so forth.
Figure 4
Figure 4 shows how you can use “Assignment group.Type” contains “hr_scandinavia”, where we use the Type field to define who has access to which COE’s / Services. Again, this is very dependent on your setup, so I will also suggest utilizing Types on the group record for COE Security Policies if it fits your needs.
One thing to note in general, is that you should always be certain and verify that your conditions meet your requirements and that they are scalable. Make sure to re-visit your conditions on your COE Security Policies, when and if your organization changes and/or your requirements does.
COE Security Policies require careful consideration about who should be able to see what. It can help to make an overview of this both before, on what you want to map, and afterwards, you can make a pivot table for instance, that shows which groups have read/write access to which tables, and if all services apply.
One of the most useful things I have ever used is the Workbook tool that ServiceNow provides. This is an Excel document, where they have predefined fields that you fill out with the values of the new form/HR Service, when conducting a workshop on this (for example, defined which group it should be assigned to, topic category, SLA, fields on the form, and so on). This will also help, once the project is complete and perhaps new HR Services are being introduced gradually, to make sure that you adhere to the same standard as when you first created them.
Feel free to reach out to us if you have any questions about COE Security Policies or about the HR module in general.