Using a script in user criteria poses a lot of caching issues. Scripts are dynamic in nature and cannot be cached. So, there is a tradeoff between the performance and consistent output of script. In a few scenarios, instead of using a script in user criteria, you can extend the user criteria by adding fields to the User Criteria [user_criteria] table.

Common scenario for using a script in user criteria

A script is generally used in user criteria to get the column value from a user record and compare that value with the required value.

For example, the following script can be used to create a group for managers who are system administrators. Assume that the sys_id of the system administrator is 6816f79cc0a8016401c5a33be04be441.

var udc=gs.getUser().getRecord().getValue('manager');

if (udc=="6816f79cc0a8016401c5a33be04be441")

{

answer = true;

}

else {

answer = false;

}

In the script, we get the manager column value from a user record and compare it with the sys_id of a system administrator.

However, since using a script in user criteria poses caching issues, you can remove the script and extend the user criteria by adding the required field from the User [sys_user] table. In this example, you can remove the script from the user criteria and add the manager column from the User [sys_user] table and set its value as System Administrator.

How to extend user criteria?

Instead of adding a script to user criteria using a field on the User [sys_user] table, you can add a field to the User Criteria [user_criteria] table.

Here are a few rules for adding a field:

• The field type must be Reference or List in the User [sys_user] table.
• The field type must be List in the User Criteria [user_criteria] table.
• The fields must have matching names in the User [sys_user] and User Criteria [user_criteria] table.

Best practices for using a script in user criteria

In case it is inevitable to use a script in user criteria, you can follow these best practices:

• The global object user_id points to the logged-in user. Use user_id in the script to get values for the logged-in user instead of performing a query or getting the corresponding values from the session.
• Do not use scoped APIs in scripts since they can fail as they are accessed from a different scope.If scoping is required, define a script includes in the required scope and call the script includes from the user criteria script. This practice is not recommended. Use only when it is inevitable for the business.
• If you have a script that can impact performance, for example, GlideRecord queries, then use gs.putClientData(name,value) to store result as a name value pair in the session. You can later in the session retrieve this data using gs.getClientData(name). The result is then cached at the session level for a user.