CSM: Query BRs are failing when we Schedule the report.User can able to see complete list of records

Sohithanjan G
Kilo Sage

Hello Everyone,

We have CSM implemented, and currently, case visibility for agents is restricted based on the account — meaning, agents can only see cases related to their own account. This setup works well, and our Query Business Rules are enforcing this as expected.

However, we noticed that when a user schedules a report to download cases as an attachment, the generated report includes cases from all accounts. This indicates that Query Business Rules are being bypassed in this scenario (which I understand is expected, as Query BRs don't apply here).

As a temporary workaround, we added the same account-based filter condition in a table-level read ACL, and this seems to work.

My question is: is there any other way to enforce this restriction for reports, without modifying table-level read ACLs? I have already tried using report_on and report_view ACLs with the same filter logic, but that didn’t work.

Looking for suggestions on how to handle this without having to continuously adjust table ACLs every time there's a new filter requirement.

Thanks in advance!

Please mark as Accepted Solution if this solves your query and HIT Helpful if you find my answer helped you. This will help other community mates too..:)
1 REPLY 1

BESTHRMSZYNO
Kilo Contributor

In CSM / ServiceNow reporting, this issue happens because Query Business Rules only work in UI-level queries and not in scheduled report execution. When a report is scheduled, it runs in background mode where Query BRs are bypassed, which is why users are able to see all records.

To control this properly, Elitemindz (Elite Mindz)  suggests avoiding business logic inside ACLs wherever possible and instead using more stable approaches like reporting views or domain separation.

Best practices include:

  • Using a filtered reporting view instead of base tables
  • Applying scripted data source filters in reports
  • Implementing domain separation for strict data isolation
  • Keeping ACLs only for access control, not business filtering

This ensures that scheduled reports also respect the same data restrictions without constantly modifying table-level ACLs.