Scripts in user criteria

[Subha V]

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.