Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

User criteria diagnostics reports: No user criteria is configured at article level.

simoneserra9483
Tera Contributor

I have set Cannot read UC on a kb article. The parent knowledge base has no Cannot read UC. When I run UC diagnostics on a certain and on that KB article, I get a "No user criteria is configured at article level". Is that because I'm running it while impersonating the knowledge manager and not admin (as admin, i don't access to it)?

1 ACCEPTED SOLUTION

MackI
Kilo Sage

hi @simoneserra9483 

 

You have the following conflict:
• Fact 1: You explicitly set a "Cannot read UC" (User Criteria) on the KB article itself.
• Fact 2: The UC diagnostic returns: "No user criteria is configured at article level."
The fact that the diagnostic cannot confirm the presence of the criteria you know are set suggests an access restriction on the diagnostic utility itself when attempting to read the configuration data:
1. Impersonation Interference: When running the diagnostic tool while impersonating the Knowledge Manager, the platform executes the diagnostic checks using the security context of that manager. If the manager's role lacks the required read access to the internal tables that store the definition of the "Cannot read UC" criteria relationship on the KB article, the diagnostic script may return an empty or null value, which the user interface interprets and displays as "No user criteria is configured".
2. Configuration vs. Runtime: The diagnostic tool is designed to retrieve the configured criteria (like "Available For" or "Not Available For" lists, which are based on User Criteria records) to determine access. If the user running the check does not have the elevated permissions (like admin) required to directly query or view these system configuration records, the output will fail, regardless of whether the criteria are technically present.
Conclusion and Action
Yes, the diagnostic result is likely inaccurate due to the impersonated user's role.
To resolve this and confirm the configuration, your ITSM Administrator should perform the diagnostic:
• Run as Admin: The configuration or system administration tasks, such as running internal diagnostics, generally require the admin role to ensure full access to all relevant tables and definitions.

 

A small request from my end, If you like this opinion and your problem is resolved after reviewing and applying it. Please kindly mark this your best answer‌🌠‌ OR  mark it  Helpful ‌‌ if you think that you get some insight from this content relevant to your problem and help me to contribute more to this community

MackI | ServiceNow Technical Consultant | DXC Technology Australia | ServiceNow Practice | LinkedIn Top IT Operation Voice 2023 | Sydney,Australia

View solution in original post

1 REPLY 1

MackI
Kilo Sage

hi @simoneserra9483 

 

You have the following conflict:
• Fact 1: You explicitly set a "Cannot read UC" (User Criteria) on the KB article itself.
• Fact 2: The UC diagnostic returns: "No user criteria is configured at article level."
The fact that the diagnostic cannot confirm the presence of the criteria you know are set suggests an access restriction on the diagnostic utility itself when attempting to read the configuration data:
1. Impersonation Interference: When running the diagnostic tool while impersonating the Knowledge Manager, the platform executes the diagnostic checks using the security context of that manager. If the manager's role lacks the required read access to the internal tables that store the definition of the "Cannot read UC" criteria relationship on the KB article, the diagnostic script may return an empty or null value, which the user interface interprets and displays as "No user criteria is configured".
2. Configuration vs. Runtime: The diagnostic tool is designed to retrieve the configured criteria (like "Available For" or "Not Available For" lists, which are based on User Criteria records) to determine access. If the user running the check does not have the elevated permissions (like admin) required to directly query or view these system configuration records, the output will fail, regardless of whether the criteria are technically present.
Conclusion and Action
Yes, the diagnostic result is likely inaccurate due to the impersonated user's role.
To resolve this and confirm the configuration, your ITSM Administrator should perform the diagnostic:
• Run as Admin: The configuration or system administration tasks, such as running internal diagnostics, generally require the admin role to ensure full access to all relevant tables and definitions.

 

A small request from my end, If you like this opinion and your problem is resolved after reviewing and applying it. Please kindly mark this your best answer‌🌠‌ OR  mark it  Helpful ‌‌ if you think that you get some insight from this content relevant to your problem and help me to contribute more to this community

MackI | ServiceNow Technical Consultant | DXC Technology Australia | ServiceNow Practice | LinkedIn Top IT Operation Voice 2023 | Sydney,Australia