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. 

[bianca_vaccarin]

The Kb referenced here is an internal articles so if you want people to use the info it needs to be flipped to public or I would suggest removing it from this post. 

[Muqalid]

Great article. Thank you so much. I was just wondering if you could shed some more light on the last point (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) with an example? I wanted give permission for a KB based on fields in sn_hr_Core_profile table. For example:

var gr = new GlideRecord ('sn_hr_Core_profile);

var ManagmentGroup;

gr.addQuery('user',user_id);

gr.query();

if (gr.next()) {

ManagmentGroup = gr.u_managment_group;

}

if (ManagmentGroup == 'test');

{

answer = true;

}

else

{

answer=false;

}

Thanks!

[shouvik]

@Muqalid User Criteria is generally cached for performance. If the User Criteria definition is not scripted we can cache the objects and based on the definition invalidate correctly when the values are updated. If the User Criteria is scripted we cant cache it, hence it will be evaluated which causes performance problem. This is the same issue you see with Scripted ACLs.

Thanks
Shouvik 

[Allen Andreas]

Hi,

I just wanted to add that scripted user criteria IS cached...the same as any user criteria without script.

In fact, that's a big issue a lot of people have is that scripted criteria is in fact cached and people want to know what they can do about it. One method, presented in this public facing support article, is to set 2 specific system properties to true: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0790108 -- for the one property listed, there's a typo and it should be named: glide.cache.disabled.USER_ITEMS_CACHE

I'd recommend reading over that support article and weighing the true need to disable caching for user criteria and see if it really fits your need(s). Contact SN support for further guidance.

[Nichole Weiland]

Hi I am attempting to extend my user criteria to allow for a reference value for User Status we have on our user record to be used within our Knowledge Base.  I followed the steps outlined int the above post to extend and it isn't working.  Can you extend if the reference field is a user defined rather than out of the box variable?  And if so, are there any differences that need to be accounted for?

Here is my build out of the User Criteria field:

User Status Field Build on the User Table

User Status Table:

Thank you for any help that you can give me in advance.