HRSD Vancouver: COE Security policies inheritance explained
Please find here a logical depiction of how COE Security policies and ACLs are evaluated in the (Out of the Box) ServiceNow setup
COE Security Policies and ACL's
COE security policies are a no-code way to configure access to the different HR Case tables (Centers of Excellence; COE’s). Read more about the evaluation of them here.
Up until Vancouver there was however a difference in how COE security policies handle Hierarchy versus how Access Control Lists (ACLs) handle them.
As an example, we can look at HR Core Case, that is an extend of Task. The different COE’s are in itself an extend of HR Core Case.
For ACLs it will look from most specific (f.e. Payroll) to least specific. Meaning that if you have not specified a more specific ACL on Payroll, it will look for an ACL on HR Core Case, if it cannot find any there, it will finally resort to the Task level (or even * level; meaning the fallback for any table). This means that there is a certain connection between the tables in terms of inheritance/hierarchy like depicted below.
Utah --> Vancouver
Up until the Utah release this however was not the case for COE Security policies. You could not specify on HR Core Case level a policy that would cover all Child tables (f.e. Payroll, HR IT, and Employee relations).
This meant that you would have to set up policies on each level. For example, if you want to allow ‘Group A’ access to all 3 tables, as well as the HR Core Case table, you need to specify it 4 times.
From Vancouver on it is possible to set up 1 policy that applies to all Child COEs:
(Note that ‘Applies to all services’ will be automatically checked and read only)
This inheritance will allow us to set up 1 policy that will roll down to the other levels
In combination with the added ‘Policy name’ and ‘Short description’ this adds to the maintainability and efficiency of the COE Security policy setup.
