[Article] What is Query Business Rule in Servicenow

[BillMartin]

What Is a Query Business Rule in ServiceNow? A Practical Guide to Security, Performance, and Data Governance

When I first discovered that not every ServiceNow list showed all available records, I wondered why. I knew there was more data in the database, yet only certain records ever appeared. If you’ve ever questioned this, you’re not alone. The answer often sits with Query Business Rules in ServiceNow, one of the platform’s best tools for controlling data access, boosting performance, and keeping information safe.

In this post, I’m breaking down what a Query Business Rule is, how it fits into the bigger picture of ServiceNow

business rules, why it matters for admins and developers, and how you can use it to shape your data landscape like a pro. Along the way, you’ll see a practical example, learn the business value, and pick up some best practices that’ll help you avoid common mistakes.

 

The Basics: What Are Business Rules in ServiceNow?

Business rules in ServiceNow are small pieces of server-side logic that run in response to actions—like querying, displaying, inserting, updating, or deleting a record. They’re a backbone of automation and governance in ServiceNow.

Business rules break down into a handful of types:

• Before Rules: Change data just before saving to the database.
• After Rules: Run logic after saving data.
• Async Rules: Handle tasks in the background (great for stuff that doesn’t need to block the user).
• Display Rules: Prepare or shape data right before it loads on a form.
• Query Rules: Filter and control what data is retrieved in the first place—my focus in this guide.

Out of these, Query Business Rules do their work earliest; they change what records users or APIs can even see, before the database sends any results back.

Where Do Query Business Rules Fit In?

Imagine a user tries to open the Incident list. Behind the scenes, ServiceNow kicks off a chain of server-side logic. Here’s a simplified breakdown:

1. Query is triggered: The user or a system process asks the database for records.
2. Query Business Rules fire: Before the SQL is run, these rules filter the data. Only qualified records will ever make it to the next step.
3. Database runs the filtered query: Only matching records are selected.
4. Display rules prepare data: For forms, these rules format and provide extra context.
5. Before rules validate input: If the user edits or adds data, before rules check or change the data before saving.
6. After and async rules run final processing: Notifications, integrations, and audit logs happen after the record is saved.

Query Business Rules shape the dataset right at the starting line. I think of them as the bouncer at a club: they decide which records even get through the door.

What Does a Query Business Rule Actually Do?

A Query Business Rule works like a filter. Unlike other rules that can modify or validate data, query rules simply change the WHERE clause for the database query. They don’t touch the data itself; instead, they change what records get retrieved.

A classic example: Suppose I want users to only see Incidents assigned to their group. Without this, anyone with access might see every Incident in the system (not ideal).

Let’s say the user Beth Anglin belongs to the Network Support and Service Desk groups. The Query Business Rule grabs her group membership and tells ServiceNow, “Only show her Incidents where the assignment group matches hers.” That’s automatic, secure filtering at the database level—users never see what they aren’t allowed to see.

Step-by-Step Example: Restricting Incidents to Assigned Groups

To make this real, here’s how I set up a Query Business Rule to restrict Incidents by group in a ServiceNow developer instance:

1. Name the rule for clarity: Give it a clear, descriptive name so you know exactly what it does later (for example: “Restrict Incidents by User Group”).
2. Select the table: Point the rule at the incident table.
3. Set the trigger to “query”: So it only runs when records are being retrieved.
4. Enable advanced scripting: Check the “advanced” box.
5. Write the script:
   • Grab the currently logged-in user.
   • Find the user’s groups.
   • Use addQuery to filter results so only Incident records with a matching Assignment Group are included.

A key part of the script: add current.addQuery('assignment_group', 'IN', userGroups); inside the rule’s script field. This tells ServiceNow to retrieve only the records where the assignment group matches a group the user belongs to.

Testing the Rule in Action

I like to test changes step by step. Here’s how I made sure the rule worked:

• Impersonate Beth Anglin with the rule inactive. Beth sees all 152 Incident records.
• Activate the rule and refresh her Incident list. Now, Beth sees only the Incident records tied to her groups—a much smaller, relevant list.

This entire process runs without touching the front-end filters or UI. The user experiences a filtered list automatically, and security is consistent every time data is queried.

 

Why Query Business Rules Matter

I see at least four big benefits to well-designed Query Business Rules:

1. Security and Privacy
   Only authorized users or systems can access sensitive data. This rule type lets me enforce strict visibility at the database level.
2. Data Governance
   Organizational rules are baked in. I can guarantee that users only access appropriate records, following our company’s policies.
3. Performance Optimization
   Filtering results early cuts down on unnecessary data load. The system doesn’t waste resources retrieving records users shouldn’t see.
4. Consistency
   Admins don’t have to hope users apply the right filters. With Query Business Rules, every query starts with the right set of data, every time.

Query Business Rules work even better when paired with Access Control Lists (ACLs) . Where ACLs control who can do what (view, edit, delete) on tables and fields, Query Business Rules decide which records to retrieve at all. Used together, they create a strong, layered security model.

Best Practices for Creating and Managing Query Business Rules

After years of tuning ServiceNow environments, I’ve picked up some best practices that save headaches:

• Keep queries efficient. Don’t write scripts that force complex joins or conditions—it slows the system and can cause timeout errors.
• Document your rules. Future admins will thank you. Always describe what the rule does, why it exists, and which tables it applies to.
• Test for all user roles. Make sure your rules don’t hide too much. Impersonate different users and confirm they see what they should.
• Use groups to manage governance. Assign permissions and data visibility at the user group level for easy, scalable maintenance.
• Don’t disable ACLs. Use Query Business Rules to supplement, not replace, ServiceNow’s built-in security controls. Layered security is safer.
• Validate before production. Overly tight query rules can make it look like records disappeared. Always double-check in a test environment.

These habits will help you balance security, performance, and user needs without extra drama.

 

Comparing Business Rule Types in ServiceNow

Here’s a quick table to help distinguish where different business rules fit in the data workflow:

Rule Type When It Runs Key Function

Before	Before insert/update	Validates or modifies data before saving
After	After insert/update/delete	Triggers actions like sending notifications
Async	Runs in background	Handles tasks that don’t need to block operations
Display	When form loads	Prepares data for UI display
Query	Before database retrieves records	Filters which records can be seen or used

For a deeper dive into how all these rules fit together, check out my complete lesson on business rules in ServiceNow.

Tips for Testing and Learning

Don’t just take these tips at face value—try them yourself! I recommend using a free ServiceNow developer instance for safe testing and learning. That way, you can see how Query Business Rules impact real data, try impersonating different users, and confirm everything works as expected before making changes in production.

Wrapping Up: Why Mastering Query Business Rules Matters

Query Business Rules run quietly behind the scenes, acting as the gatekeeper for every ServiceNow data request. They’re a key tool for privacy, security, and performance. With just a few lines of code, I can control exactly what users see—sometimes without them knowing any filtering happened at all.

Keep your rules efficient. Always test with real users. Use clear names and document your intentions. Pair Query Business Rules with ACLs for layered security, and you’ll sleep easier knowing your ServiceNow data is tight and well-governed.

If you found this guide helpful and want to learn even more about ServiceNow business rules (including a deep dive on before, after, display, and async rules), watch my full lesson here. Don’t forget to subscribe to the channel and leave your favorite Query Business Rule use case in the comments.

Thanks for reading—I’ll see you in the next tutorial!

[Nikhil Bajaj9 · Accepted solution]

Hi @BillMartin ,

Just topping up.

Query Business Rules offer a lot of benefits:

Enhanced User Experience: Users see only what's relevant, streamlining workflows and boosting productivity.
Improved Data Security: Restricting access protects sensitive information, mitigating risk.
Automated Data Governance: Enforce predefined data policies without manual intervention.
Reduced Query Load: Fewer irrelevant queries improve database performance.

Regards,

Nikhil Bajaj

[Nikhil Bajaj9 · Accepted solution]

Hi @BillMartin ,

Just topping up.

Query Business Rules offer a lot of benefits:

Enhanced User Experience: Users see only what's relevant, streamlining workflows and boosting productivity.
Improved Data Security: Restricting access protects sensitive information, mitigating risk.
Automated Data Governance: Enforce predefined data policies without manual intervention.
Reduced Query Load: Fewer irrelevant queries improve database performance.

Regards,

Nikhil Bajaj

[BillMartin · Accepted solution]

good points @Nikhil Bajaj9 

[Daniel Oderbolz]

Hi @BillMartin 
Thanks for yet another good article.

Let me point out a few things.

I do not quite agree that BWBR are so great. In my opinion, they are often misused and serve mostly to prevent this thing from happening: Ability to disable "Number of records removed by security constraints"... and results returned"

(this is currently the most voted-on idea in the idea portal, because it is a real pain).
BQBR do not provide security at all - they only affect list views. If a user has another way of getting to the data, they can see it i there are no corresponding ACL.

In fact, you need both: ACL and BQBR, the latter just to make sure that the User is actually able to find the records they are entitled to see.

And I am especially not a fan of a centralized approach where some people decide what other people need to see. Often, especially in incident management, it is very important that support teams see what other people did. I think organisations that restrict access on incidents too tightly see a worse performance resolving incidents compared to "Open Book" organisations.

Best
Daniel

[BillMartin]

Hi @Daniel Oderbolz ,

These are valid points you mentioned, especially from an architectural perspective. It’s always a tradeoff: ACLs define true security boundaries, while BQBR function more as a usability layer, shaping how data is viewed in list contexts.

From an architectural standpoint, the value lies in how these mechanisms complement each other — ACLs ensuring protection of data, BQBR helping streamline the viewing experience, and governance guiding how restrictive or open that visibility should be.

Best,
Bill