Working With ACLs In ServiceNow

 

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.

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:

1. Roles
2. Criteria
3. 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.

JDS is experienced in optimizing ACLs and can use a variety of methods to drastically improve ACL performance. For more information, reach out to the JDS ServiceNow team.