Restricting Incident visibility with Query BR – will users still see records via Global Search/URL?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
He All,
I’m working on restricting the visibility of Incidents using a before query Business Rule.
The logic is:
A user should only see incidents assigned to them or to the groups they are a member of.
I’ve written a Query BR that adds conditions on assignment group (user’s groups) and assigned to (the user).
This works fine in the list view – users only see the expected subset of incidents.
My question is:
👉 If a user knows the number or sys_id of another incident (which belongs to a different group), and they have the itil role, will they still be able to:
Access it through Global Search?
Open it directly in the form view using the record URL?
In other words, does a Query BR fully restrict access to records outside the user’s groups, or is an ACL required to block form-level access?
I've also tested with users having admin and ITIL roles, but I've noticed that the Query BR-form level access is no longer available, and tickets are not visible in global search/URL. Is this the expected behavior?
Would appreciate some guidance on the best practice here.
Thanks in advance!
Abdul
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
if query BR is blocking a record and user uses sysId and directly visits via URL -> User won't see that record
Yes query BR will impact the global search
If my response helped please mark it correct and close the thread so that it benefits future readers.
Ankur
✨ Certified Technical Architect || ✨ 9x ServiceNow MVP || ✨ ServiceNow Community Leader
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
Hi @Abdul333 ,
If a user opens an incident using its direct URL (e.g., /incident.do?sys_id=...), the form view GlideRecord query is also filtered by your Query BR. If your BR’s logic excludes the record (not assigned to user/their group), the form will show "record not found" or similar—the record won't load, even if the sys_id is known.
If your Query BR runs for everyone (including admins), even they won’t see records not matching your conditions. If you exclude admin in the BR logic, admins will see everything.
Global Search runs GlideRecord queries like list views, so the Query BR restricts results in the same way—they’ll only see tickets matching your BR filters. Exclude admins in your Query BR if they are supposed to see all records.
Thanks,
Bhimashankar H
-------------------------------------------------------------------------------------------------
If my response points you in the right directions, please consider marking it as 'Helpful' & 'Correct'. Thanks!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 weeks ago
Hi @Abdul333 ,
Even though your Query Business Rule filters incident records in the UI, users with knowledge of a record's sys_id or number and proper roles like itil can still open those records directly via URL or search. The Query BR doesn’t block those access paths.
Best Practice is use Query BR + a row-level read ACL. This setup filters list results smoothly and prevents unauthorized record access via any direct method.
If you found my response helpful, please mark it as ‘Accept as Solution’ and ‘Helpful’. This helps other community members find the right answer more easily and supports the community.
Kaushal Kumar Jha - ServiceNow Consultant - Lets connect on Linkedin: https://www.linkedin.com/in/kaushalkrjha/
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
3 weeks ago
Hi @Abdul333 ,
I hope you saw my reply.
If my response points you in the right directions, please consider marking it as 'Helpful' & 'Correct'. It will help future readers as well having similar kind of questions and close the thread.
Thanks,
Bhimashankar H