@Henrik Alt You are most likely experiencing this issue due to missing query_range acl on the risk assessment instance table due to an instance level change that happened in May, 2025. Therefore, you are experiencing this immediately after the upgrade.
If you've recently seen one of your GRC users open a workspace and find an empty list — or hit a cryptic banner that mentions "insufficient access for 'query_range' operation" — you're not configuring something wrong. You're seeing the downstream effect of a platform security change that quietly reshaped how every list query is evaluated.
Here's what changed, why it matters specifically for IRM, TPRM, and Compliance teams, and what to do when it bites.
The error you'll actually see
Part of the query on [table] has been ignored because of
insufficient access for 'query_range' operation on [table.field]
The query still runs. The unauthorized filter clause is just silently dropped. That's why symptoms usually look like "the list is empty" or "the business user can't find their assessment" rather than a hard authorization failure — making this one of the harder ACL issues to diagnose in production.
What query_range actually is
query_range is an ACL operation — sitting alongside read/write/create/delete — that governs whether a user can apply range or pattern operators (>, <, >=, <=, starts with, ends with, contains, between) to a field. Its sibling query_match governs the safer exact-match operators (=, !=, IN, IS EMPTY).
The operation type itself isn't new. What changed in May 2025 is that ServiceNow flipped the global *.* query_range ACL to default deny and auto-generated thousands of new query_range ACLs across the platform. Before the patch, range queries were effectively wide open unless explicitly blocked. After the patch, they're blocked unless explicitly allowed.
How to fix it (when an OOB patch isn't available)
Create a parallel Record ACL that mirrors the read ACL but uses the query_range operation:
- Operation:
query_range
- Name:
table.field (or table.* for table-wide coverage)
- Roles: the same roles your existing read ACL grants
Two practical caveats:
- If the corresponding read ACL has a security attribute, the parallel query_range ACL should mirror it without the security attribute. The security attribute lives on read; the query layer just needs the role match.
- Sometimes
query_match is the right answer instead. If the operators users actually need are =, !=, or IN, build a query_match ACL — ServiceNow Support has flagged this on a few cases (see KB2130442).
Review these articles:
Missing ACLs on initial Compliance Management Workspace setuphttps://www.servicenow.com/community/grc-forum/missing-acls-on-initial-compliance-management-workspa...
Query ACLs
https://www.servicenow.com/community/developer-blog/query-acls/ba-p/3273676
Find below knowledge articles on ServiceNow support:
KB2046494 (May 2025 Maintenance) ·
KB2130442 (query_range troubleshooting).
Hope this helps.
