This article is relevant for the following ServiceNow releases: Xanadu, Yokohama.

---

In 2025, we’re still seeing “records hidden by security constraints” pop up across ServiceNow instances. If you’ve worked on a heavily ACL table with complex business logic, you know this isn’t just a minor annoyance—it’s a source of confusion, inference risks, and wasted debugging hours. But with the latest updates, we’ve now got new tools in the box.

The most recent security patch introduced some powerful updates: namely, query_match and query_range ACLs. These provide finer-grained control over what fields can be queried, filtered, or even counted against. Let’s break down what problems these ACLs solve—and what they don’t.

If you’re wondering whether these new ACLs finally solve the “records hidden by security constraints” ? Let’s unpack it with a scenario that’s a little too close to reality for most devs.

Scenario: Secret Task

Security Model

Let’s say we have a custom table called u_secret_task, extending the standard task table. This table includes a sensitive field: u_secret_number.

Security rules dictate that users can view these records only if:

• The record is unassigned, or
• The record is assigned to their group.

However, there’s a catch. We don’t just want to restrict access to viewing records. We want to eliminate any possibility of a user inferring how many “Secret Tasks” exist or what their secret numbers are—even if they can’t open them.

Full data set of Secret tasks and Secret numbers

We will test this scenario as a user who is part of the group Service Desk.

Security Configuration

First, let’s cover the most obvious method: Deny ACLs. With a “Deny unless” script-based ACL, we can ensure that if a user isn’t in the assigned group (or if the task is assigned elsewhere), access is flat-out denied.

Deny unless ACL for Secret tasks with an assignment group

ACL to check you are a member of the assignment group

That works well enough, enforcing the data security with a single ACL.

Or does it?

But here’s where things get dicey. Let’s say you paginate the list to 10 rows. A savvy user can still infer:

1. The total number of records that exist
2. How many have a particular secret number
3. Which ranges of secret numbers are more frequent

I can’t see 4 records but I still know how many records there are

As long as the number of results exceeds the row limit and returns more than one page, users can infer data that they should not be able to see by adding filters. This is just the odd way ServiceNow works with pagination and security.

As an experiment, I set the page limit to 1. Using this, I can infer that the Secret number of 2 Secret tasks assigned to CAB Approval is 1.

While this example may seem silly, if there is enough data in the system, you can begin to make inferences. This is because your security is misconfigured.

So how do we level-up our security posture and eliminate even these indirect exposures? Enter: query business rules, Query ACLs and a new feature you may never have heard of.

Before Query Business Rules

By implementing a before query business rule, we can programmatically apply additional conditions to all queries—even ones coming from scripts, widgets, or third-party integrations. These business rules add a query to every GlideRecord lookup in the system to filter out results.

(function executeRule(current, previous /null when async/) {
gs.info("Secret task b4 qry");
current.addEncodedQuery('assignment_groupDYNAMICd6435e965f510100a9ad2572f2b47744ORassignment_groupISEMPTYEQ');
gs.addInfoMessage("Before query rule has restricted access to data in the table Secret Task [u_secret_task].");
gs.addInfoMessage(current.getEncodedQuery());

})(current, previous);

Hiding hidden results with before query business rules

This can eliminate the “hidden by security constraints” banner by ensuring users never see results they’re not supposed to in the first place (info message added for educational purposes). But there’s a gotcha: this only works on the table where the rule is defined.

Want to hide secret tasks when someone queries the parent task table? You’ll need a matching rule there too. That’s not always practical. And performance-wise, these rules can be expensive if you’re filtering with subqueries or heavy joins.

Security Data Filters (Yokohama+)

Security Filters, introduced in a recent upgrade, provide similar functionality to before query business rules—without needing to write code. They’re configured declaratively and applied before query evaluation.

• Requires elevated roles like security_admin
• Can be set on conditions like “only if user is in group X”
• Better for performance, less room for human error

Security filter to hide records

Works just like a before query Business rule

If you’re not already using security filters in favour of business rules for access control, now’s the time to consider it, especially on custom tables with sensitive data. I would suggest this makes before query business rules obsolete, with this as the new standard.

Query Match ACL

Here’s where things get spicy. The new Query Match ACL stops users from filtering on a particular field entirely—unless they pass the ACL condition.

So if I add a query_match ACL on u_secret_number, and the user doesn’t pass the ACL check? They can’t even apply a filter like “u_secret_number = 1”.

This shuts down the most common inference method: narrowing down results by filtering.

Query Range ACL

Need to go one level deeper? Query Range ACL does the same thing, but for range-based queries. Think “u_secret_number BETWEEN 0 AND 2”.

With a query_range ACL in place, even advanced filters like ranges, wildcards, and LIKE clauses are blocked—unless the user passes your access check.

So if your security concern is around pattern detection or statistical inference, this ACL is your new best friend.

Conclusion

So, where are we in 2025? We’ve come a long way. The combination of before query rules, security filters, and query ACLs gives us the strongest set of tools yet to lock down sensitive tables and fields.

But here’s the reality: “records hidden by security constraints” is still a thing. These ACLs don’t replace the banner—they just make it less relevant by blocking the ability to infer what’s missing.

Want to go one step further? Join the campaign to deprecate this behaviour entirely. Upvote the idea here (requires a NowSupport login) and help save your fellow developers from late-night debugging and security paranoia.

Until then—lock it down, test your filters, and assume users are smarter than you think.

The post Is “records hidden by security constraints” still a thing after the latest security patch? appeared first on The SN Nerd.