User Criteria Diagnostics tool results inconsistent with actual user experience
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
4 hours ago
We are leveraging User Criteria Diagnostics to check access for knowledge articles. It will say that someone does or does not have access to view an article, but when we impersonate that person, often the opposite occurs of what UCD states. Has anyone else experienced this? Is this a known issue or should I just reach out to IT to resolve? Thank you!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
an hour ago
This is a known behavior rather than a bug — there are two relevant Now Support KB articles worth reviewing depending on your setup.
If you are using scripted User Criteria (KB0750243): The UCD tool does not use impersonation when evaluating access. If your User Criteria scripts use gs.getUser() calls such as gs.getUser().getCompanyID(), those calls return values for the current admin user, not the user being evaluated. This produces results that don't match what the user actually sees. The fix is to use the user_id variable in your User Criteria scripts instead of gs.getUser() calls. This is documented as expected behavior — an enhancement request to add true impersonation to the tool has been submitted but not yet delivered.
If you are using HR Criteria (KB0779974): There were two known defects (PRB1294404, PRB1319818) specifically around HR criteria being evaluated incorrectly in the UCD tool. These were marked fixed in Madrid, so if you are seeing this on a current release it may be worth opening a support case and referencing those PRB numbers.
In either case — check whether your User Criteria are scripted first. That's the most common cause of the mismatch you're describing.