In today’s data-driven world, it is crucial to protect sensitive information while still enabling the right people to do their jobs effectively. The need-to-know principle, which is the practice of granting individuals access only to the data and functionalities they require, is an important security concept that helps ensure privacy and compliance.
Organizations often adopt this principle to meet regulatory requirements such as the General Data Protection Regulation (GDPR), Health Insurance Portability and Accountability Act (HIPAA), or the Digital Operational Resilience Act (DORA). These frameworks lay out rules on how data should be accessed, stored, and shared, encouraging clear security controls.
Another reason is building customer trust. When users know their data is handled securely, they have more confidence in an organization’s services. Lastly, internal policies and best practices also motivate the use of the need-to-know principle. By limiting access to only what employees truly need, companies can lower the risks of unauthorized changes, accidental disclosures, and general security threats within their ServiceNow environments.
When need-to-know measures aren’t balanced properly, teams risk losing access to essential data (leading to business delays), while a poor implementation can degrade platform performance and increase maintenance overhead.
In this article, we will cover the following:
- Overview of ServiceNow data security capabilities that support the need-to-know principle
- How data security capabilities work together when a user attempts to access a record
- Designing the need-to-know principle, including key considerations for planning access and avoiding common pitfalls
- Implementation recommendations, grounded in ServiceNow best practices
Overview of ServiceNow Data Security Capabilities
There are five platform-wide solutions that can help secure data:
- Multi-instance architecture
- Domain Separation
- Data Filtration
- Deny-unless ACLs
- Allow-if ACLs
Multi-instance Architecture
Multi-instance architecture provides physical data segregation across multiple ServiceNow instances or external systems. It is particularly useful for storing highly sensitive data, such as personal information, in a separate environment. In this setup, you can fetch the necessary data into ServiceNow via Remote tables, ensuring the information remains in memory only and is never permanently stored in the ServiceNow database.
This approach suits scenarios where you merely need to display sensitive data (e.g., personal details) from an external system without involving it in automated workflows or storing it within ServiceNow. By segregating data physically, you can maintain stricter controls over who has access to it and reduce the risk of unauthorized exposure.
Domain Separation
Domain Separation provides logical data segregation within a single ServiceNow database by dividing data into separate silos (Domains). It was originally designed for Managed Service Providers (MSPs) that need strict boundaries between different client environments.
However, Domain Separation introduces significant complexities for most enterprises, such as cross-domain visibility challenges, cumbersome administration, and specialized skill requirements. It is strongly discouraged in typical enterprise scenarios. Instead, organizations should leverage the other solutions discussed in this article - such as Data Filtration or ACL-based configurations - to achieve secure data segmentation without the overhead and limitations of Domain Separation.
If Domain Separation is absolutely necessary for your MSP use case, it should be the first plugin enabled on a newly provisioned instance to avoid conflicts and ensure proper configuration from the start.
Data Filtration
Data Filtration provides application-layer data segregation on top of your existing Access Control rules (ACLs). It selectively denies access to tables and records that do not match certain subject attributes, which an administrator defines (for example, a user’s role or group membership).
A key limitation is that Data Filtration applies only to read operations at the record level, so you cannot selectively hide or expose individual fields within a single record. Moreover, Data Filtration can only evaluate the current user’s attributes, not specific fields on the record itself. This means you can create conditions like “User has role ABC” or “User is in group XYZ,” but you cannot filter on details such as “Caller is me” or “Assignment group is one of my groups.”
One unique advantage of Data Filtration is the ability to apply network-based restrictions (for example, blocking access if the user’s IP address is not in an approved range). If you need this network-level granularity, Data Filtration is essential. In most other scenarios, Deny-unless ACLs offer broader flexibility and can typically address the same requirements without the user-focused limitation.
Deny-unless ACLs
Deny-unless ACLs provide application-layer data segregation and were introduced in the Xanadu release as an extension of the pre-Xanadu ACL model. Unlike pre-Xanadu ACLs and Allow-if ACLs, where access is granted if ANY matching ACL condition is met, Deny-unless ACLs deny access unless ALL defined Deny-unless ACLs (and all their criteria) are satisfied.
This reversed logic can offer more granular control, but it also requires careful planning to avoid unintentionally blocking users from data they need. When used correctly, Deny-unless ACLs can help ensure that only the right individuals have access to sensitive information.
Allow-if ACLs
Allow-if ACLs provide application-layer data segregation and were introduced in the Xanadu release. As part of this release, all existing ACLs were automatically converted to Allow-if ACLs without any impact on functionality. Their behavior matches that of pre-Xanadu ACLs, meaning that if ANY matching ACL condition is satisfied, access is granted.
This straightforward approach works well for most use cases, as it maintains the familiar access logic that many administrators are already comfortable with.
Summary
In addition to the five security solutions discussed, certain ServiceNow products - such as Strategic Portfolio Management - offer their own built-in data segmentation features. However, because these solutions are product-specific, they are not covered in this article.
It is also important to note that before-query Business Rules are not a reliable solution for enforcing data security, as they can be bypassed and do not provide the same level of control as the security measures outlined above.
How data security capabilities work together
In this chapter, we will focus on three core security methods introduced above:
- Data Filtration
- Deny-unless ACLs
- Allow-if ACLs
These methods can work together to enforce a strong need-to-know model. Here is how the process typically unfolds when a user attempts to access a record:
1. Record Retrieval
- The system loads the requested record from the database.
2. Data Filtration Check
- If one or more Data Filtration rules apply to this record, all applicable rules must match the user’s attributes.
- If any rule does not match, access is denied, and the process stops here.
- If no Data Filtration rules apply, or if they all match, the process continues.
3. Deny-unless ACL Check
- If one or more Deny-unless ACLs exist for this record, all of them must match for the user to proceed.
- If any Deny-unless ACL fails to match, access is denied, and the process stops.
- If no Deny-unless ACLs apply, or if they all match, the process continues.
4. Allow-if ACL Check
- If an Allow-if ACL condition is satisfied, access is granted.
- If no Allow-if ACL condition is met, access is denied.
By combining these methods in the correct sequence, you can ensure that users only gain access to the data they legitimately need, without risking overexposure or unnecessary restrictions.
Example: A House with Multiple Doors
Imagine you have a house with multiple doors, such as a front door, back door, and garage door. Each door represents an Allow-if ACL. You have also given out various keys to family members and friends, allowing them to enter your home when needed. However, you still want to make sure that even if someone has a key, they only come in for a valid reason.
You have two ways to do this:
1. Attach a separate validation mechanism to each door
You could install a special device on every door (front, back, garage, etc.) that checks the reason for entry. This is similar to customizing each Allow-if ACL to include extra conditions, but it can become complicated and harder to maintain because you have to manage many separate doors.
2. Build a fence with a single entry point
Instead of putting a mechanism on every door, you could build a fence around your house with one main gate. Everyone who wants to enter first goes through this gate. If they pass the reason-for-entry check at the fence, then they can use their door key to get inside. This setup centralizes the control outside the house, without altering the original locks on each door.
Before the Xanadu release, you had to rely on the first option - customizing the baseline (Allow-if) ACLs - for each scenario. Now, thanks to features introduced in Xanadu, you can “build a fence” around your house. In other words, you can use Data Filtration and/or Deny-unless ACLs to apply a centralized check before the Allow-if ACLs even come into play. This way, you do not have to modify the baseline Allow-if ACLs.
This approach has several advantages:
- Fewer customizations: You keep the core ServiceNow ACL logic intact.
- Centralized control: You can apply uniform rules across the entire platform from one place.
- Minimal conflicts: ServiceNow does not ship any Data Filtration rules by default, and Deny-unless ACLs are rarely used out of the box, so your customizations are less likely to clash with standard settings.
By placing these “fences” around your house, you ensure that only those with both a valid key (baseline ACL) and a valid reason (Data Filtration or Deny-unless ACL) are granted access. This creates a more flexible yet secure environment - mirroring the need-to-know principle discussed in this article.
Designing the need-to-know principle
Before diving deeper, let’s consider the key risks associated with implementing the need-to-know principle:
- Business Risks
If the access rules are set too strictly, some records might become invisible to everyone, preventing people from accessing data they legitimately need. This can result in business delays, reduced productivity, and even compliance issues if essential information is not accessible when required.
- Technical Risks
Implementing advanced data security features can increase complexity in your ServiceNow environment. When not carefully planned, this complexity can affect platform performance, leading to slower query times or added overhead during record retrieval. Poorly optimized security configurations can also be difficult to maintain or troubleshoot.
The first business risk is associated with the size of the silos you want to create - whether it is, for example, “You may only see records from your organization” or “You may only see records assigned to you or your groups.” If you opt for very small groups with limited membership, you face a higher chance that essential records go unattended when people are on vacation or sick. To compensate, you might need many “power users” with broad access to monitor the situation, which is inefficient. Therefore, plan silo sizes carefully to avoid situations where nobody can manage specific records.
The second business risk is an extension of the first, involving cross-silo exceptions. Regardless of how well you segment data, you will likely need some individuals to see records outside their silo (for instance, to support another organization). These exceptions typically rely on group memberships - each silo has its own group granting visibility. If your silos are too granular, you will end up with numerous exception groups, making business logic difficult to manage and maintain.
The third business risk relates to which records you choose to protect - whether it is only tickets (e.g., in the Task table) or also foundation data and the CMDB. If you restrict access to foundational data, you may find that a user can see a ticket but not the associated user, service, or configuration item. This situation is confusing because reference fields appear empty, leaving users uncertain whether the data truly does not exist or is just hidden.
The fourth business risk relates to how Data Filtration and Deny-unless ACLs work. As noted earlier, these controls function like a fence around a house with multiple doors - those doors representing your Allow-if ACLs. The “gate” in the fence must account for all possible reasons someone might need to enter. If you miss even one valid reason, users might be locked out of records they legitimately need to access. Therefore, it is essential to ensure that every use case covered by the Allow-if ACLs is also reflected in your Data Filtration or Deny-unless ACL configurations.
As discussed, there are several key considerations to minimize business risks associated with the need-to-know principle. Properly defining your business logic is the most critical factor for a successful implementation. From a technical perspective, there are actually fewer risks when using Data Filtration and/or Deny-unless ACLs. In addition, the complexity of the logic does not necessarily pose a bigger challenge than you might expect - both simple and complex scenarios still require listing all valid reasons for granting access, which means the technical approach remains largely the same.
So, what is the key technical risk?
The main technical risk comes from the number of SQL queries needed to fetch and display record lists. By using the Debug SQL option, you can see how many queries are required for different list sizes. For instance, in a personal ServiceNow instance:
- Loading 20 Incident records generated 29 SQL queries
- Loading 50 Incident records generated 56 SQL queries
- Loading 100 Incident records generated 73 SQL queries
For simplicity, let’s assume that the number of SQL queries approximately matches the number of records. Thus, loading 100 records would require about 100 queries.
The greatest concern is the extra database reads triggered by dot-walking, or by calls to GlideRecord or GlideAggregate. In the worst-case scenario, the following formula shows how these can multiply:
Performance impact factor = X + ((number of attributes with field-level ACLs) * Y)
- X is the number of dot-walking or GlideRecord/GlideAggregate operations used in record-level ACLs
- Y is the number of dot-walking or GlideRecord/GlideAggregate operations in field-level ACLs
- The resulting performance impact factor represents how many times more SQL queries the platform might need to run
Examples:
- If you have only record-level Deny-unless ACLs with 2 dot-walking operations, your performance impact factor is 2. In other words, you may need 200% more resources than you would without these extra checks.
- If you have both record-level and field-level Deny-unless ACLs, with 3 dot-walking operations at the record level and 2 dot-walking operations at the field level (applied to 5 attributes), your factor becomes 3 + (5 × 2) = 13, meaning you could need 1300% more resources.
Although the calculation above represents a worst-case scenario, it can actually occur quite frequently - especially when users start defining custom filters or when you have many small silos. The more silos you create (or the smaller they are), the higher the likelihood of hitting this performance bottleneck. This situation closely ties into the first business risk, where very small or numerous silos lead to inefficiencies.
It remains critical to understand the potential impact of your business logic on query performance. The upcoming chapter on Implementation Recommendations will outline strategies to reduce these risks and ensure optimal performance.
As a general guideline, if you see a performance impact factor that you believe could lead to performance issues - often around 3 or higher - it’s wise to revisit your design to reduce the use of dot-walking, GlideRecord, and GlideAggregate in both record-level and field-level ACLs. Bear in mind that the exact threshold for noticeable performance degradation will vary among different implementations, depending on factors like database setup, query performance, and how your ACLs are structured.
Drawing on the points made so far, the following suggestions capture the essential considerations to guide you in designing the need-to-know principle:
- When defining business logic and silo levels, avoid overly small silos. Even if you want to restrict visibility, silos that are too small can lead to unassigned or delayed work when team members are out of office. Strike a balance between security and practicality by ensuring a sufficient pool of users can handle critical records.
- Expect exceptions to arise and plan for them. Be aware that exceptions are inevitable. Even if you do not see an immediate need, ensure that your solution can handle cross-silo access and that the exception process remains manageable.
- Use record-level ACLs for tickets, but show at least the display value for referenced data. Showing or hiding entire tickets works well for tasks, but users need to understand which services, items, or people a record references. If you must fully restrict access to those references, opt for field-level ACLs instead of hiding the entire record.
- Clearly define your access criteria so all scenarios are reflected in Deny-unless ACLs. Deny-unless ACLs deny access unless all conditions are met. This makes it vital to list every valid reason a user could need to view a record. Omitting even a single scenario might block legitimate users from necessary data.
- Perform a technical analysis of your defined access rules. Identify where dot-walking, GlideRecord, or GlideAggregate calls appear in both record-level and field-level ACLs. Each of these operations can increase query counts and slow down list rendering.
- Assess potential performance impacts. Consider calculating a “performance impact factor” to gauge how much your ACLs are multiplying database reads. Tools like Debug SQL can offer valuable insights into how many queries your ACLs generate.
- Revise your business logic if performance issues arise. A performance impact factor above a certain threshold may indicate the need for optimizations. Reducing the number of dot-walking or GlideRecord calls can significantly improve platform responsiveness.
Below is a practical illustration of how you might define your access criteria. Each access level in the table corresponds to a valid reason for granting visibility, ensuring that no legitimate scenario is overlooked. Please note that these table entries are not the same as individual ACL definitions. Instead, think of them as inputs to your technical design, as explained in the next chapter, Implementation Recommendations.
| Access level | Description | Conditions |
| Ticket Creator or Watcher | Anyone who created a ticket or is on the watch list should be able to view the ticket. | User is named in the ticket’s caller_id, opened_by, or watch_list fields. |
| Fulfiller or Business Stakeholder | Grants fulfillers and business stakeholders broader access to their company’s tickets, including those assigned to their group. | User.Company = Ticket.Company OR User is a member of the Assignment group OR User is named in Assigned to |
| Read Another Company | Grants exceptional, cross-company access. | User is a member of the exception group for Ticket.Company |
| Read All | Enables “power users” (or administrators) to see all tickets across the platform. | (Role-based) Read all tickets |
Implementation recommendations
This chapter provides technical recommendations for implementing the need-to-know principle using Deny-unless ACLs and Allow-if ACLs, with a focus on reducing the risks outlined in earlier chapters. The content assumes a strong technical foundation and is aimed at implementers (developers) with hands-on experience in configuring ACLs and writing server-side scripts.
In this chapter, we will cover:
- Understanding the behavior and implementation approach of Allow-if and Deny-unless ACLs
- Strategies to minimize the risk of worst-case performance scenarios
- Practical guidance for implementing Deny-unless ACLs effectively
In the following text, we will refer back to the example of access levels provided in the previous chapter, illustrating how to translate those definitions into a technical implementation.
Understanding the behavior and implementation approach of Allow-if and Deny-unless ACLs
As mentioned in the Overview of ServiceNow Data Security Capabilities, Deny-unless ACLs use reversed logic compared to Allow-if ACLs. Using the example with the access levels:
- With Allow-if ACLs (which function like an “OR” condition), you would typically create multiple ACLs - one for each valid reason to grant access.
- With Deny-unless ACLs (which function like an “AND” condition), creating multiple ACL definitions for the same record can unintentionally block access altogether. If you have four Deny-unless ACLs, then all four conditions must be met for a user to see a record.
In practice, this means:
- It is recommended to have multiple Allow-if ACLs, each covering a specific access level or scenario.
- You should generally have only one Deny-unless ACL per table or attribute, incorporating all valid reasons for access within that single ACL definition.
Note: You can have more than one Deny-unless ACL on the same table only if they target different subsets of records based on “Applies to” conditions.
Using Deny-unless ACLs may not always be the best option. In some scenarios, modifying a single baseline Allow-if ACL is technically simpler. However, this approach:
- Increases the impact on platform manageability and upgradability, since your custom logic might conflict with upgrades.
- Spreads your logic across multiple places if you mix Deny-unless with customized baseline Allow-if ACLs, making it harder to maintain.
- Leaves you exposed to new Allow-if ACLs introduced by plugins, which could override or conflict with your custom rules, potentially causing security issues.
If you rely solely on Deny-unless ACLs, you have one central location to manage your logic. Combine that with baseline Allow-if ACLs only if you are prepared to review potential conflicts after every upgrade.
You will often find multiple ways to implement your requirements, so choose the one that best fits your needs.
Record-level vs Field-level ACLs
It is especially important to decide between Deny-unless ACLs and Allow-if ACLs when restricting access to reference data (foundation data, CMDB, etc.). As discussed previously, we recommend avoiding record-level restrictions on such data to prevent situations where references appear blank and users are uncertain if data is missing or simply hidden.
Instead, use field-level ACLs to protect specific attributes. In that case, your choice between Deny-unless or Allow-if ACLs depends on how many attributes you need to protect or expose:
- Deny-unless ACLs if you only need to secure a few attributes
- Allow-if ACLs if you need to show just a few attributes but restrict access to most others
Example 1: Hiding Sensitive Personal Information
If you want to hide a small number of sensitive fields in the user record (e.g., national ID, personal email), using Deny-unless ACLs for those specific fields is often simpler and safer.
Example 2: Restricting Access to the CMDB
The CMDB includes many tables and attributes. You might decide only a few key attributes (Name, Company, Assigned to, etc.) should be visible to everyone. Instead of creating thousands of field-level Deny-unless ACLs, it may be simpler to apply a default Allow-if ACL that restricts all attributes, and then add dedicated/overriding Allow-if ACLs for the selected fields you want everyone to see.
By carefully choosing between Deny-unless and Allow-if ACLs - and between record-level and field-level protection - you can strike a balance between security and usability, while also minimizing the risk of unexpected performance issues or maintenance challenges.
Strategies to minimize the risk of worst-case performance scenarios
The worst-case scenario described in earlier chapters mainly affects fulfillers (users who work in the backend, such as Service Desk agents). End users who only access the platform through the Employee Center have visibility constraints determined by predefined filters, meaning they typically see only their own tickets.
To reduce the likelihood of encountering worst-case performance situations, consider the following:
- Use Application Menus with Predefined Filters
Make sure your application menus include filters that allow fulfillers to see only the tickets relevant to them. This helps prevent queries that pull in unnecessary data.
- Hide Protected Attributes in List Views
If you have field-level ACLs protecting certain attributes, avoid displaying these attributes in the list view. This reduces additional queries and dot-walking operations.
Fulfillers are the most frequent users viewing and updating tickets. When you design application menus, optimize them for these roles. For instance, Service Desk agents typically want to see only tickets assigned to them or their groups. Use that understanding of their daily workflow to tailor application menus accordingly. Below is an example of an application menu for Incidents in a customer-based silo model.
| Menu item | URL |
| Create New | Keep the baseline URL (default functionality) |
| Assigned to Me | Active = True AND State IS NOT Resolved AND Assigned to IS Me |
| Assigned to My Groups | Active = True AND State IS NOT Resolved AND Assignment group IS One of My Groups |
| My Groups Unassigned | Active = True AND State IS NOT Resolved AND Assignment group IS One of My Groups AND Assigned to IS EMPTY |
| Resolved | Active = True AND Company IS One of My Companies AND State IS Resolved |
| Open | Active = True AND Company IS One of My Companies |
| All | Company IS One of My Companies |
The “One of My Companies” menu item uses a custom dynamic filter that returns the user’s company, along with any additional companies the user can access based on membership in exception groups.
Keep in mind that this menu design does not cover every possible scenario from the example access levels. Instead, it aims to address the most common use cases, ensuring that the majority of users can handle their daily tasks without needing extra training to build filters. More advanced users - such as those building reports - should learn how to create efficient filters that maintain the correct data visibility and good performance.
The approach described above not only promotes good performance but also reduces instances where users see the message, “Number of rows removed from this list by security constraints: <number>”, due to records they are not allowed to access.
You might wonder why we do not use before-query business rules for this purpose. Such rules significantly increase the technical complexity and associated risks, because they require replicating the entire access logic within the database query. By contrast, the approach of customizing application menus provides a consistent user experience for most users without adding extra complexity or risk. If necessary, you can still introduce before-query business rules later on - once you are certain your need-to-know logic is stable and working effectively, and only if the customized menus alone no longer meet your needs.
It is equally important to address field-level ACLs, which can have a much bigger performance impact compared to record-level ACLs on tickets. To mitigate this risk, make sure your default list views do not include any attributes (columns) protected by field-level ACLs that rely on dot-walking, GlideRecord, or GlideAggregate. While you could enforce these views via View Rules, this can be too restrictive for some users - especially those needing to perform list edits. Instead, focus on user training, ensuring everyone is aware of the performance impact of adding such attributes and knows how to reset their list view to default if necessary.
You may also want to configure the preview view for records protected by field-level ACLs to display only the attributes that are visible to all users, further reducing the risk of performance bottlenecks.
As noted in the Overview of ServiceNow Data Security Capabilities, Deny-unless ACLs use reversed logic compared to Allow-if ACLs. When you create multiple Deny-unless ACLs for the same table or attribute, all of them must be satisfied for a user to gain access. As a result, it is generally best to define only one Deny-unless ACL per table. Additionally, each section within a single Deny-unless ACL—Security attributes, Data conditions, and Script conditions—also uses AND logic, meaning every condition in these sections must be met.
Using the example of access levels, you will usually need a single, advanced Deny-unless ACL with script conditions to capture all valid scenarios. Below are some technical tips to keep in mind:
Prioritize conditions hat do not trigger additional SQL queries
Identify conditions that do not involve dot-walking, GlideRecord, or GlideAggregate - especially those that apply to the largest number of records. You can derive these conditions from the customized application menu definition. For instance, consider the following criteria:
- Assigned to is Me
A straightforward comparison of two values (e.g., current.assigned_to == gs.getUserID()), which does not trigger extra SQL queries.
- Assignment Group is One of My Groups
Often checked via gs.getUser().isMemberOf(current.assignment_group), which does invoke an SQL query.
- Company is One of My Companies
A straightforward comparison of two values (e.g., current.company == gs.getUser().getCompanyID()), which does not trigger extra SQL queries. May require additional checks if the user belongs to exception groups, which does invoke an SQL query.
Since “Ticket.Company = My Company” usually applies to a broader set of records than “Assigned to is Me,” it often makes sense to evaluate the Company condition first - especially if most users work within their own company. By contrast, exception groups typically rely on SQL operations, so you might want to handle those later in the script.
Although “Assigned to is Me” affects fewer records, it does not invoke additional SQL queries, making it another strong candidate for early evaluation. In other words, you can check “My Company” first, followed by “Assigned to is Me,” to quickly filter a large portion of records without triggering extra database calls.
This type of condition analysis is crucial for ensuring the best possible performance. Ideally, your initial condition in the script should be the one that most frequently matches user scenarios.
Small customizations can significantly improve performance
Although it is generally advisable to minimize customizations, you cannot avoid them entirely. In fact, a well-planned customization can greatly enhance performance when you implement the need-to-know principle. Consider the following example:
You want to grant access to an Incident whenever a user has visibility into its Incident Tasks. In most environments, Incidents rarely have Incident Tasks. By adding a custom field to the Incident table - such as Has Incident Tasks (true/false) or Incident Task Count (integer) - and populating it via a Business Rule, you can avoid unnecessary GlideRecord queries to check whether any Incident Tasks exist and whether a user has access to them.
Such customizations can also serve other purposes, like reporting. Always think broadly about reusability and design your solutions in a generic manner to maximize their value.
Ensure optimal performance of GlideRecord and GlideAggregate
All GlideRecord and GlideAggregate operations within ACLs should be as efficient as possible. Always review your database indexes, adding new ones when needed to improve query speed. If you only need to verify that a related record exists, use GlideAggregate for a simpler, faster check compared to multiple GlideRecord queries.
Be careful with GlideRecordSecure to avoid loops
You may need to grant visibility to an Incident if the user can see its Incident Tasks, and vice versa. One possible way to do this is by using GlideRecordSecure to verify a user’s access to the related record. However, placing this logic in both the Incident and the Incident Task ACLs can create an endless loop of GlideRecordSecure calls.
Proper testing is essential
Any mistake in your access logic can have a significant business impact, making thorough testing absolutely critical. Remember to go beyond user testing and include integrations and other processes - such as Discovery, MID Servers, and third-party connections - to ensure all components work as expected. Be especially cautious with Data Filtration, which does not offer an “admin override” option. If administrators require access, explicitly specify the admin role in the filtration conditions to avoid unintended lockouts.
Summary
Implementing the need-to-know principle in ServiceNow is a vital step toward safeguarding sensitive information while still allowing users the access they need to perform their roles effectively. This article has explored the foundational concepts behind ServiceNow’s data security options - ranging from multi-instance architecture to Domain Separation, Data Filtration, Deny-unless ACLs, and Allow-if ACLs - and demonstrated how these methods can work together to build a robust security model.
We have seen that business risks often arise from overly restrictive silo sizes, the need for cross-silo exceptions, improperly secured reference data, and gaps in ACL logic; while technical risks revolve primarily around potential performance impacts related to SQL queries, dot-walking, and GlideRecord or GlideAggregate calls. Through practical examples, we highlighted how choosing the correct ACL strategy (Deny-unless vs. Allow-if) and leveraging carefully constructed filters can minimize security gaps, improve usability, and help avoid performance bottlenecks.
Key takeaways include:
1. Plan Your Silo Sizes and Exceptions Carefully
Poorly sized silos can cause unprocessed tickets or excessive exceptions, making administration unwieldy.
2. Use Record- and Field-Level ACLs Wisely
Restrict tickets at a record level, but keep reference data visible enough to avoid confusion. For highly sensitive fields, apply field-level ACLs.
3. Avoid Performance Pitfalls
Minimize complex ACL logic whenever possible, and pay special attention to dot-walking, GlideRecord, and GlideAggregate usage in both record-level and field-level ACLs.
4. Optimize User Experience
Configure application menus and list views to match real-world workflows. Hiding unnecessary fields and applying default filters help reduce query loads and confusion.
5. Test Thoroughly
Any misconfiguration can have a major impact, so always validate ACLs in user, integration, and platform processes.
Above all, implementing a need-to-know principle is not trivial. It requires a clear understanding of your business requirements, as well as hands-on technical expertise in designing and managing ACLs, filters, and platform features. Be sure you have a strong business reason to undertake such an initiative, and plan carefully to avoid unnecessary complexity. With thoughtful preparation, proper strategy, and a focus on balancing security with usability, you can achieve a robust need-to-know model that meets both compliance and practical operational needs.
