User Criteria

What is User Criteria?

User Criteria is an ability to group users based on certain conditions. In Service Now, we have User Groups which groups sets of users. But not that might not always satisfy all the usecases.

Lets say, we want to group all users working in Support organization from New York office. We dont have an ability to group these people in Service Now using User Group. Thats where User Criteria comes in. User Criteria allows to group user based on multiple conditions.

Is User Criteria an alternative to ACL? Short answer, NO.

To secure anything we need 2 answers "What" needs to be secured? For "Whom" it needs to be secured?

User Criteria only answers the "Whom". It has nothing to do with security on its own. It is used to group a set of users in the system based on some condition. Now, with this group, we can say they have access to a KB article, or a Catalog Item or any widget in Portal. All of these are security provided by the Applications using User Criteria as user grouping mechanism, and then securing the respective object. So, User Criteria doesnot provide security, the security is provided by the application which uses User Criteria to answer "Whom". We can use User Criteria in ACL script as well to secure say an Incident or Case record as well.

### User Criteria applies only on 6 fields. Can I extend to apply on any other field like VIP?

Yes, User Criteria can be extended to apply on any field in User(sys_user) table. Lets say, we want to have a user criteria only for VIP users. To do this, add a new field in User Criteria(user_criteria) table with the same name as in sys_user table.

System takes care of handling "u_" prefix for field name. So, if a field with u_vip doesnot exist in sys_user table it will check for field with vip.

Note: For reference fields, you can use List(glide_list) to refer to multiple records like Company.

Add the newly added field to the User Criteria form.

Create a new User Criteria selecting VIP checkbox.

Now this user criteria can be used to group any vip user and can be used in any Application. So, we can create a Catalog Item only for VIP users or a KB article only for VIP users.

Note: For performance improvement, user to user criteria association is cached. This allows effective evaluation of user criteria. The caching is done in two level. For non-scripted(non-advanced) user criteria, the cache is in the application. This means the cache remains in the system till the node if restarted or the record is updated. If the user criteria is scripted, the caching is on the session. So, after the user logs out the cache is flushed out. Hence it is recommended not to use script because it will have performance implications as the cache is only in session.

For extending the user criteria to a new field in User(sys_user), we need to let the system know whenever any user record is updated with VIP field, we need to clean the cache of these users. To do so, we need to create/update a property (glide.cache.flush.user_criteria_cache.sys_user), and put comma separated field names for whom we want the system to track changes and invalidate the User Criteria cache. The field names need to be from the user(sys_user) table and not from user criteria table.

How to use User Criteria for custom application?

There are scripts available in the platform which allows us to check if the user is part of a user criteria. Using these scripts one can configure their application to make use of User Criteria grouping.

API: sn_uc.UserCriteriaLoader.userMatches(userID, listOfUserCriteriaIDs); Return: Boolean(true/false) Returns true if the user(userId) is part of any of the user criteria

API: sn_uc.UserCriteriaLoader.getMatchingCriteria(userID, listOfUserCriteriaIDs); Return: List of user criteria IDs Returns list of criteria IDs what the user(userID) is part of

With the above 2 APIs, any application can use user criteria in their flow.

Note: Unlike User Group where user membership is stored in a table, user association to a User Criteria is not direct. It could be with multiple combinations like roles, company, location etc. It could also be scripted. Hence to get all users for a given user criteria is not easily available in any table. To evaluate it might be high on performance as one needs to iterate over all Users in the system and evaluate User Criteria usage. So, one should consider changing the ask and evaluate only those user criteria the application needs for the given user.

Warning:

ServiceNow community has a few APIs which are non-documented and should not be used as those APIs has the ability to bring down an instance. APIs like UserCriteriaLoader.getAllUserCriteria() should never be used.