Planning Your Access Control Strategy

pratikbhatt

Persona: Admins, architects, and developers who own access control configuration

Introduction: Why Planning First Pays Off

Successful access control in ServiceNow begins long before anyone touches the Script field or creates their first ACL rule. The most effective security implementations start with a thoughtful planning phase—selecting the right control type, placing it at the appropriate layer in your table hierarchy, and understanding how different security mechanisms interact with each other.

ServiceNow's access control system has evolved significantly with recent releases. The introduction of Deny-Unless ACLs in the Xanadu release, along with Security Data Filters and Query ACLs in subsequent versions, gives administrators more granular control than ever before. However, this expanded toolkit also means there are more decisions to make—and more opportunities to create confusion if you don't plan ahead.

Learn how to plan access controls before you configure them—pick the right ACL type, place rules in the table hierarchy, and decide when to combine ACLs or use security data filters.

Understanding ACL Decision Types

Before creating any access control rule, you must first understand the fundamental difference between the two decision types available in ServiceNow: Allow-If and Deny-Unless.

Deny-Unless ACLs

Deny-Unless ACLs as gates that block access unless ALL specified conditions are met.

Key characteristics of Deny-Unless ACLs:

Access is denied unless the user satisfies all configured conditions.
Deny-Unless ACLs are always evaluated before Allow-If ACLs—if a user fails a Deny-Unless check, they never get a chance to be evaluated against Allow-If rules
Passing a Deny-Unless ACL does NOT grant access—it simply means the user won't be denied by that specific rule. They still need an Allow-If ACL to actually gain access.
Best suited for scenarios where access should never be granted outside of conditions in the ACL.

Allow-If ACLs

Allow-If ACLs represent the traditional ServiceNow access control model. They work on an additive principle. Start with a safe baseline and then augment for new needs by adding more Allow ACLs.

Key characteristics of Allow-If ACLs:

Access is granted if the user satisfies all configured conditions.
Multiple Allow-If ACLs on the same object are evaluated independently—passing any one of them grants access
This is the default ACL type and represents how ServiceNow has traditionally handled access control
Best suited for scenarios where you want to progressively expand access as business needs grow

ACL Conditions

ServiceNow ACLs evaluate up to five condition types together to decide whether a user can access a record or field.

ACL condition types

An ACL rule can include these condition types, all of which must evaluate to true to grant access (logical AND):

Roles - required user roles that must be present.
Security Attributes - reusable scripted component to evaluate user or environment criteria.
Data condition - record-based conditions built with the condition builder.
Controlled by reference - access that depends on ACLs of a reference record.
Script – advanced logic that returns true or false.

Contextual vs non-contextual ACLs

ACLs that rely only on static checks such as roles and security attributes are typically non-contextual, because they do not depend on individual record data.

ACLs that use data conditions, reference-based checks, or scripts that inspect the current record are contextual, because they evaluate per record based on its data.

Performance and maintainability

Non-contextual ACLs are faster to evaluate, easier to audit, and simpler to maintain, making them preferable for broad, role-based or environment (example network criteria) access rules.

Contextual ACLs provide finer-grained, record-level security but require evaluation on each record, which can be slower and more complex to manage at scale.

Planning tip: Security Data Filters introduced in Yokohama release can help you filter data based on criteria.

Required Roles and Security Attributes (Fastest)

These checks happen once per resource and require no database reads. Security attributes like UserIsAuthenticated, Role, and RoleExplicit are evaluated first. Required Roles specified in the ACL are also part of this fast evaluation layer. If a user fails here, they're immediately denied access without any further processing.

Planning tip: Always specify required roles when possible. This is the most performant security check available and should be your first line of defense.

Data Conditions and Applies To

These conditions are evaluated per record and involve database reads. The Condition field in your ACL allows you to specify record-level criteria without writing scripts. The "Applies To" field (introduced in recent releases) provides additional control over when the ACL should be evaluated.

Planning tip: Ensure conditions reference indexed fields whenever possible. Unindexed field conditions can significantly impact performance when applied to large tables.

Controlled by Reference

When your access decision depends on a related record, use the "Controlled by Reference" mechanism to leverage ACLs already defined on that relationship. This allows you to dot-walk to related records and inherit their access decisions.

Planning tip: Use reference-based control when you can naturally express access in terms of related records. For example, "users who can access the parent Service can access related Configuration Items" is cleaner than duplicating logic in scripts.

Scripts (Last Resort)

Script-based conditions should be your last resort. While scripts provide maximum flexibility, they're harder to test, maintain, and audit. Scripts run per record and can include complex logic with GlideRecordSecure queries, dot-walking, and custom business logic—all of which consume significant resources.

Planning tip: Before writing a script condition, ask: "Can I express this with roles, security attributes, conditions, or references instead?". If you need scripting explore security attributes before you write script condition which allows you to write complex logic and enforce access based on user and environment criteria. Only use scripts when the business logic genuinely cannot be expressed declaratively.

Security Data Filters

Security Data Filters (SDFs) are an alternative to Before Query Business Rules. They apply safeguards directly to database queries, restricting data at the source rather than after retrieval. SDFs were introduced as a more maintainable and auditable approach to row-level read ACLs and Before Query Business Rules (BQBR).

Key characteristics of Security Data Filters:

Applied before queries execute—unauthorized records never leave the database.
Multiple filters on the same table are combined using logical AND.
Filters on child tables do not propagate to parent tables—create filters on each table if needed.
Provide declarative security that auditors often prefer over scripted controls.
Security Data Filters are best suited for restricting record-level visibility across the platform when you need to enforce row-level security based on user attributes, roles, or contextual criteria without modifying individual ACLs.

When to Use Security Data Filters

Plan to use Security Data Filters for highly sensitive data where the business requirement is that unauthorized users should never even query the records. Common use cases include HR records with regional restrictions, financial data with strict need-to-know requirements, and personally identifiable information (PII) that must remain isolated.

Performance consideration: Poorly optimized filters can degrade system performance. Avoid filters on unindexed fields or using "contains" operations. Use the Security Data Filter Performance Analysis Tool to evaluate impact before enabling filters in production.

Conclusion

Access control in ServiceNow is far more than just creating ACL rules. A well-planned security implementation considers the nature of each requirement, applies the right control type, places rules strategically in the table hierarchy, and leverages the full toolkit of security features available in modern ServiceNow releases.

By following the funnel approach—starting with fast, broad checks and narrowing to specific, resource-intensive evaluations only when necessary—you create a security posture that is both effective and performant. By choosing wisely between Deny-Unless and Allow-If, you ensure your implementation matches the actual business intent.

Remember: the goal isn't just to implement access controls, but to implement them in a way that's maintainable, auditable, and aligned with your organization's security requirements. Planning first always pays off.

Next Step:

Learn more about how to configure access control.

Additional Resources

For more information, consult the following ServiceNow documentation: