Part of the query on sys_choice has been ignored because of insufficient access for 'query_match'

CharlieNZ · ‎05-18-2025

I hope this is the right place for this.

We have a user that has started getting these on each Incident they view:

Part of the query on sys_choice has been ignored because of insufficient access for 'query_match' operation on sys_choice.name
Part of the query on sys_choice has been ignored because of insufficient access for 'query_match' operation on sys_choice.inactive
Part of the query on sys_choice has been ignored because of insufficient access for 'query_match' operation on sys_choice.dependent_value
Part of the query on sys_choice has been ignored because of insufficient access for 'query_match' operation on sys_choice.element

We haven't made any changes to their account. The issue wasn't there a week ago.

Konrad Mlodzik · ‎05-20-2025

Hello @CharlieNZ
My investigation shown that in fact, users didn't have read access to the field specified in the error message, visible in the below screenshot. All of that due to all sys_choice.* ACLs.

My approach from here was to create sys_choice ACL for each of the fields that were prompted in error message, so in my case sys_choice.element and sys_choice.dependent_value.
I made them similar to the existing read ACL sys_choice.label.
Here you have an overview how I created that ACL:

And as you can see here now in Access Analyzer, access is evaluated to true

Try this approach with at least one of the fields from sys_choice that you have mentioned in yours error messages and see if the error still occurs. For me that works

If you can please mark that as helpful and that resolved your issue so that can help other visiting this thread 🙂

View solution in original post

Konrad Mlodzik · ‎05-21-2025

Superb!
I'm glad that I could help

Craig Tinsley · Friday

FWIW: we ran into this when we migrated from classic ServiceNow Dashboards/Reports to Platform Analytics Dashboards/Data Visualizations - specifically for the "sys_portal_preferences.portal_section". I initially used the glide record solution posted earlier in this thread; however, that didn't settle well with me, as this was simply masking the problem. I contacted our Governance partners at ServiceNow, and their recommendation was to address the ACL in the manner shown above. While either solution "will" work, the "more appropriate" action would be to address the specific ACL(s) at the source. Good comments - thanks to all!