ACLs or Access Control Lists are the process by which ServiceNow provides granular security for its data and can be applied to individual records, as well as fields within those records.
While you want to work with ACLs, you should know the types of ACLs. The types are as follows:
1. Row level ACL or table level ACL.
2. Column level ACL or field level ACL.
You can create ACLs for different operations on the table like Read, Write, Create, Delete. You can create ACLs for Client Callable script includes, UI pages, REST endpoints, etc. Please see below screen shot.
While giving the user access for Read, you need to first create Row level ACL first and then create Field level ACL for Read permission. You need to add the role that you decided to whom you are going to give Read access.
When working with ACLs, it is extremely important to note that the order in which an ACL definition is evaluated has performance implications.
These are:
- Roles
- Criteria
- Script
ROLES: FASTEST
Roles will evaluate extremely fast as they are cached in server memory, so using roles is always highly recommended.
CRITERIA: FAST
Conditions are based on values in the current record and will evaluate quickly, but only after the role has been checked.
Although you can have complex criteria using dot-walking (“Show related records”) these will incur a performance overhead as ServiceNow needs to load the related records.
In this example, the criteria is based on the company of the assigned person for that record, requiring ServiceNow to load TWO additional records to evaluate.
Remember, performance does not scale in a linear fashion.
Although criteria like this may seem blisteringly fast when looking at a single record in a development environment, it will be much slower in production as lots of people access records—and particularly if it is applied to a READ rule in a list view as the criteria has to evaluate for each and every individual row being displayed (multiplying the performance overhead).
SCRIPT: SLOWEST
Although slowest here is a relative term, ACL scripts will evaluate at least slightly slower than ACL roles and ACL criteria for a number of reasons.
Scripts are often needed in ACLs, but they should always be carefully considered for performance implications.
The best practice with scripts is to have them shielded by roles and criteria. In this way, the script won’t even run unless the ACL first matches the role and then matches the criteria, potentially sidestepping a performance overhead before it occurs.
Consider the following two ACLs. Technically, they’re identical, but one will run considerably faster than the other.
Even though they’re technically identical, the second ACL will be slower because:
- The script will be run for ALL users and not just those that have the ITIL role
- The script will run on ALL records not just those that are active
- ServiceNow’s JAVA layer has to invoke a Rhino Javascript engine to evaluate this script
Ideally, scripts should only be used on ACLs that already have roles and criteria to ensure they’re only running when absolutely necessary.
ServiceNow is optimised to run ACLs extremely fast, but they can introduce a performance overhead on large instances with millions of records.
