Group By field(custom field) throws "Insufficient access for query_range" for client user

[DeebikaS1775775]

Hi All,
I am investigating a reporting issue after a recent ServiceNow upgrade.

Scenario:

Report is built on cmdb_ci.
Report uses Group By = Resource Group (custom field).
For some users (including admins), the report works correctly.
For one specific user, the report fails with an error similar to:
Insufficient access for 'query_range'

If I remove the Group By and set Group By = None, the same user can see all report data successfully.

Observations:

User has access to the underlying records because the data is visible when grouping is removed.
The issue occurs only when ServiceNow performs the grouping/aggregation on the Resource Group field.
No field-level ACL exists on the custom Resource Group field.
The field values are visible in list view for the affected user.

Questions:

Has anyone seen query_range errors affecting reports that use Group By?
Does report grouping internally trigger query_range ACL evaluation?
Were there any upgrade changes related to query_match / query_range ACL enforcement that could impact report aggregations?
What is the best way to troubleshoot which ACL is blocking the aggregation for the affected user?

Any guidance would be appreciated.
Thanks!

[Tanushree Maiti]

Hi @DeebikaS1775775 

Query_range error is very common.

For it you dont need to remove group by.

Fix: In error , table_name.field_name is printed.

You need to create a custom query_range Access Control List (ACL) rule for the affected field. 

• Navigate to System Security > Access Control in your ServiceNow instance. 
• Click New to create a new ACL.
• Set the configuration as follows:

• Type: record
• Operation: query_range
• Name: <your table name > and select <your field name> from the field dropdown.
• Roles: Add the roles required by users who need to execute this filter. 

• Save the ACL

[DeebikaS1775775]

Hi @Tanushree Maiti 

For a custom CMDB field, I created a field-level query_range ACL and added the required role. After that, the affected client user was able to view the report data successfully.

However, I noticed that so some OOTB fields are also showing similar query_range errors in both:

CMDB list views
Reports

My concern is scalability. We do not know how many OOTB fields may be affected, and creating separate field-level query_range ACLs for every impacted field is not a sustainable solution.

I have already checked the following query_range ACLs:

cmdb_ci (Operation = query_range)
cmdb_ci.* (Operation = query_range)
* (Operation = query_range)

All of the above appear to allow access through the public role.
I also noticed the OOTB role:
query_range_role

I have a few questions:

What is the intended purpose of the query_range_role role?
1.If this role is assigned to affected users, will it resolve query_range errors for reports and list views?

2.Has anyone encountered a situation where generic ACLs (cmdb_ci, cmdb_ci.*, *) already exist, but specific fields still fail query_range evaluation?

3.Is there a recommended alternative to creating individual field-level query_range ACLs for every impacted field?

4.Are there any additional checks related to query_match ACLs, security attributes, or ACL inheritance that should be reviewed?

Any guidance or best practices would be greatly appreciated.
Thank you.