User Criteria Best Practices

[rosenst22]

Hi everyone. I've currently been tasked with optimizing user criteria for knowledge articles. It's an HR knowledge base, but we are seeing HR criteria and user criteria from other areas (IT, catalog items, etc.) when you click on the list. Essentially, I only want to see 'can' and 'cannot read' choices that are relevant to HR knowledge authors, but modifying user criteria or even hiding choices from HR could potentially affect other areas. Does ServiceNow recommend separate user criteria for knowledge vs. catalog items? How are your user criteria setup for knowledge articles? Are they seeing choices from other areas or are they filtered by knowledge base?

[Community Alums]

We utilize both HR Criteria and User Criteria for our HR Knowledge Base Articles. There is specific data within our user profiles that isn't on the HR Profile that HR may need/want to incorporate as part of the criteria they want to apply to their articles.

[SasiChanthati]

It's a common challenge when managing user criteria across different modules like HR and IT in ServiceNow. Here's a breakdown of best practices and what’s generally recommended:

Does ServiceNow recommend separate user criteria for knowledge vs. catalog items?

Yes, ServiceNow does recommend creating and maintaining separate user criteria for different use cases, especially when you're dealing with Knowledge Management versus Service Catalog. Even though the same “User Criteria” table is used system-wide, the context and purpose can differ significantly:

Knowledge user criteria controls who can read or contribute to a knowledge article or base. Catalog user criteria controls who can see or request a catalog item. Reusing the same user criteria across both areas can lead to unintended access or confusing list views, as you're seeing. 
How are your user criteria set up for knowledge articles?

For many orgs, best practice is:

Create dedicated user criteria records for knowledge articles, prefixed clearly (e.g., “KNOW - HR Employees”, “KNOW - HR Managers”). Use naming conventions to help HR authors distinguish their own criteria from catalog or IT related ones. Set up role-based access (e.g., only HR Knowledge authors can manage HR-specific user criteria). Optionally, use filters or custom views (via ACLs or UI Policies) to limit visibility when choosing criteria.

Are your authors seeing user criteria from other areas (like IT or Catalog)?

Yes, and that’s expected behavior unless you apply some kind of filter or custom configuration. Out of the box, the “User Criteria” list isn’t scoped by application or module, so HR knowledge authors will see all available criteria.

To mitigate this: Consider using Reference Qualifiers on the “Can Read” and “Cannot Read” fields in the Knowledge Article form. This allows you to filter what criteria are selectable (e.g., only those where “Name” starts with "HR").

If you have HR scoped apps (like “com.sn_hr_core”)  consider scoping your criteria and setting application access properly to reduce cross-contamination. In some advanced setups, a custom user criteria table or separate process may be used to keep HR and IT entirely siloed.