User Criteria

User Criteria in ServiceNow: A Comprehensive Guide for CAD Exam Preparation

Introduction to User Criteria

User Criteria is one of the most important security mechanisms in ServiceNow, particularly within the Service Portal and Service Catalog. Understanding User Criteria is essential for the Certified Application Developer (CAD) exam, as it plays a critical role in restricting and granting access to specific resources based on user attributes. This guide will walk you through everything you need to know about User Criteria — what it is, why it matters, how it works, and how to confidently answer exam questions on this topic.

Why Is User Criteria Important?

In any enterprise platform, controlling who can see and interact with specific content is paramount. User Criteria provides a flexible, reusable, and scalable way to manage access without relying solely on Access Control Lists (ACLs) or roles. Here are key reasons why User Criteria matters:

• Granular Access Control: User Criteria allows administrators and developers to define fine-grained conditions that determine which users can access catalog items, knowledge articles, Service Portal pages, and more.

• Reusability: Once a User Criteria record is defined, it can be reused across multiple catalog items, knowledge bases, and other resources, reducing redundancy and improving maintainability.

• Flexibility Beyond Roles: Unlike simple role-based access, User Criteria can evaluate users based on multiple attributes such as company, department, group, location, and even advanced scripting conditions.

• Improved User Experience: By showing users only the items and content relevant to them, User Criteria helps create a cleaner, more personalized self-service experience in the Service Portal.

• Security Compliance: Organizations can enforce data segregation and access policies more effectively, ensuring sensitive resources are only visible to authorized personnel.

What Is User Criteria?

User Criteria is a ServiceNow feature that defines a set of conditions to identify a group of users. These conditions can be based on various user attributes, and the resulting criteria can then be applied to control access to resources such as:

• Service Catalog Items and Record Producers
• Knowledge Bases and Knowledge Articles
• Service Portal Pages and Widgets
• Application Menus and Modules

A User Criteria record is essentially a reusable definition that answers the question: "Does this user meet certain conditions?"

User Criteria records are stored in the user_criteria table and can be accessed through System Security > User Criteria or through the application-specific navigation paths.

Types of User Criteria Conditions

User Criteria can match users based on the following attributes:

• Users: Specific individual users can be explicitly listed.
• Groups: Users who belong to specified groups.
• Roles: Users who have been assigned specific roles.
• Companies: Users associated with particular companies (useful in multi-tenant or customer-facing scenarios).
• Departments: Users belonging to certain departments.
• Locations: Users assigned to specific locations.
• Advanced (Script-based): A script condition that allows for complex, custom logic. When the Advanced checkbox is enabled, a script field becomes available where you can write conditions using GlideRecord or other server-side APIs.

A user matches a User Criteria record if they satisfy ANY of the defined conditions (i.e., conditions are evaluated with OR logic by default). For example, if a User Criteria specifies both a group and a role, a user who belongs to that group OR has that role will match.

How Does User Criteria Work?

Let's walk through the mechanics of how User Criteria operates in practice:

1. Creating a User Criteria Record

Navigate to System Security > User Criteria and click New. You will see fields for:
• Name — A descriptive name for the criteria
• Companies — Select one or more companies
• Groups — Select one or more groups
• Roles — Select one or more roles
• Users — Select specific users
• Departments — Select one or more departments
• Locations — Select one or more locations
• Match All — When checked, ALL conditions must be met (AND logic) instead of ANY (OR logic)
• Advanced — Enable script-based conditions for complex requirements

2. Applying User Criteria to Resources

Once created, User Criteria can be applied in two primary ways:

• Available For / Not Available For: In the Service Catalog, each catalog item has related lists called "Available For" and "Not Available For". You add User Criteria records to these lists to control which users can see the item. If any "Available For" criteria are defined, only users matching those criteria will see the item. The "Not Available For" criteria explicitly excludes users even if they match the "Available For" criteria.

• Can Read / Cannot Read (Knowledge): In Knowledge Management, User Criteria is applied through "Can Read", "Cannot Read", "Can Contribute", and "Cannot Contribute" on Knowledge Bases. This controls who can view and who can author articles.

3. Evaluation Logic

The evaluation follows a specific order of precedence:

• If no User Criteria is defined on a resource (neither Available For nor Not Available For), the resource is available to all users (subject to other security mechanisms like ACLs and roles).
• If Available For criteria are defined, only users matching at least one of those criteria can access the resource.
• If Not Available For criteria are defined, users matching those criteria are denied access, even if they also match an "Available For" criteria.
• "Not Available For" takes precedence over "Available For." This is a critical point for the exam.

4. Match All vs. Match Any

By default, within a single User Criteria record, conditions are evaluated using OR logic — a user needs to match any one of the specified conditions (e.g., be in Group A OR have Role B). However, when the "Match All" checkbox is enabled on the User Criteria record, the logic switches to AND — the user must match ALL specified conditions simultaneously.

5. Advanced Script Conditions

When the Advanced checkbox is selected, a script field appears. This allows developers to write server-side JavaScript to evaluate whether a user meets the criteria. The script must set the answer variable to true or false. For example:

// Example advanced script
answer = gs.getUser().hasRole('catalog_admin') && gs.getUser().getCompanyID() == 'some_sys_id';

This provides maximum flexibility for complex business logic that cannot be expressed through the standard fields alone.

User Criteria in the Service Catalog

In the Service Catalog, User Criteria controls visibility of:
• Catalog Items
• Record Producers
• Order Guides
• Catalogs themselves
• Categories

When a user browses the Service Catalog or Service Portal, ServiceNow evaluates the User Criteria attached to each item. Items that the user is not authorized to see are simply hidden from view. This happens transparently, providing a seamless experience where users only see what is relevant to them.

User Criteria in Knowledge Management

In Knowledge Management, User Criteria governs:
• Can Read: Who can view articles in a knowledge base
• Cannot Read: Who is explicitly prevented from viewing articles
• Can Contribute: Who can create or edit articles
• Cannot Contribute: Who is explicitly prevented from contributing

Similar to the catalog, "Cannot" criteria take precedence over "Can" criteria.

User Criteria vs. Other Security Mechanisms

It is important to understand how User Criteria relates to other ServiceNow security features:

• ACLs (Access Control Lists): ACLs control access at the table and field level — they determine whether a user can read, write, create, or delete records. User Criteria works at a higher, application-specific level, controlling visibility of catalog items, knowledge articles, etc. They complement each other but serve different purposes.

• Roles: Roles are a simpler mechanism — either a user has a role or they don't. User Criteria is more nuanced, allowing conditions based on multiple attributes beyond just roles.

• Business Rules / UI Policies: These control behavior and data manipulation but are not primarily security mechanisms. User Criteria is specifically designed for access restriction.

• Data Policies: These enforce data consistency and are not related to controlling visibility of resources.

Best Practices for User Criteria

• Name criteria descriptively: Use clear, meaningful names like "HR Department Users" or "ITSM Managers" so they are easy to identify and reuse.
• Prefer standard fields over scripts: Use the built-in fields (groups, roles, companies, etc.) whenever possible. Advanced scripts add complexity and can impact performance.
• Test thoroughly: Always test with users who should and should not have access to verify the criteria works as expected.
• Use "Not Available For" sparingly: Since it overrides "Available For," be careful not to inadvertently block access for legitimate users.
• Leverage reusability: Create general-purpose User Criteria records that can be applied across multiple items rather than creating unique criteria for every single resource.
• Document your criteria: Keep track of which User Criteria records are applied where, especially in complex environments with many catalog items and knowledge bases.

Common Exam Scenarios

Here are common scenarios that may appear on the CAD exam:

Scenario 1: A catalog item has User Criteria "Group A" in Available For and User Criteria "Role X" in Not Available For. A user belongs to Group A and has Role X. Can they see the item?
Answer: No. "Not Available For" takes precedence.

Scenario 2: A catalog item has no User Criteria defined. Who can see it?
Answer: All users (subject to other access controls like roles on the catalog item itself and ACLs).

Scenario 3: A User Criteria record has both Groups and Roles defined, with "Match All" unchecked. What logic is used?
Answer: OR logic. A user needs to match any one of the conditions.

Scenario 4: You need to restrict a knowledge base so that only users in a specific company AND with a specific role can read it. How do you configure this?
Answer: Create a User Criteria record with the company and role specified and check the "Match All" checkbox. Apply it to the "Can Read" of the knowledge base.


Exam Tips: Answering Questions on User Criteria

Here are targeted tips to help you excel on User Criteria questions in the CAD exam:

1. Remember the precedence rule: "Not Available For" (or "Cannot Read/Cannot Contribute") always takes precedence over "Available For" (or "Can Read/Can Contribute"). This is the single most tested concept regarding User Criteria. If a question describes a conflict between the two, the deny/exclusion always wins.

2. Default is OR, Match All is AND: By default, conditions within a User Criteria record use OR logic. Only when "Match All" is checked does it become AND logic. Pay close attention to whether the question mentions "Match All" being enabled.

3. No criteria means open access: If no User Criteria is applied to a resource, it is available to everyone (within the bounds of other security mechanisms). Don't assume restrictions exist unless explicitly stated.

4. Know the table: User Criteria records are stored in the user_criteria table. If a question asks about the underlying table, this is the answer.

5. Distinguish User Criteria from ACLs: If a question asks about controlling visibility of Service Catalog items or Knowledge Base articles, the answer is likely User Criteria. If it asks about table/field-level security, the answer is ACLs.

6. Advanced scripts set the 'answer' variable: If a question mentions scripting in User Criteria, remember that the script must set answer = true or answer = false.

7. Read the question carefully for application context: User Criteria is used in Service Catalog, Knowledge Management, and Service Portal contexts. Make sure you identify which context the question is about, as the related list names differ (Available For vs. Can Read, etc.).

8. Understand the relationship between catalogs, categories, and items: User Criteria can be applied at the catalog level, category level, or individual item level. Restrictions at a higher level (catalog) can affect what users see at lower levels (items within that catalog).

9. Elimination strategy: When in doubt, eliminate answers that suggest using business rules, UI policies, or client scripts to control catalog item visibility — User Criteria is the correct mechanism for this purpose.

10. Practice with real instances: If possible, practice creating User Criteria records in a ServiceNow Personal Developer Instance (PDI). Hands-on experience will solidify your understanding and help you answer scenario-based questions with confidence.

Summary

User Criteria is a powerful and flexible security mechanism in ServiceNow that controls access to Service Catalog items, Knowledge Bases, Service Portal content, and more. It evaluates users based on attributes like groups, roles, companies, departments, locations, and advanced scripts. The key principles to remember are: "Not Available For" overrides "Available For," default evaluation uses OR logic unless "Match All" is enabled, and no criteria means universal access. Mastering these concepts will prepare you to confidently tackle any User Criteria question on the CAD exam.