Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

Client script not working as intended for Customer Contact

FrancescoB82786
Tera Contributor

Hi everyone,
I’m encountering an issue with a Catalog Client Script that runs on a portal form. The script is the following:

function onChange(control, oldValue, newValue, isLoading) {
if (isLoading) {
return;
}

var wl_array = g_form.getValue('watch_list').split(',');

if (wl_array.length > 2) {

var trimmed = wl_array.slice(0, 2);

g_form.setValue('watch_list', trimmed.join(','));
g_form.setValue('watch_list', g_form.getValue('watch_list'));

setTimeout(function() {
g_form.showFieldMsg('watch_list', 'You can select a maximum of 2 people.', 'error');
}, 200);
}
}

What it does is: within the "watch_list" field (a list collector), when the user tries to add a third person, the script prevents the addition and displays a message informing the user that the maximum allowed is 2.

The script works correctly with my admin user.
However, when impersonating a user belonging to the Customer Contact role, the script breaks: the field gets cleared completely when the user tries to add the third person.

3 REPLIES 3

Brad Bowman
Kilo Patron
Kilo Patron

What is the purpose of the second setValue line?  Seems redundant.  You could also just set the value of watch_list to oldValue, instead of all that.

For sure, I've tried many combination and forgot to comment that line in an attempt

Hi @FrancescoB82786 ,

 

 Root Cause Analysis:

  1. List Collector Behavior in Portal
    • In the Service Portal, g_form.getValue('watch_list') returns a comma-separated sys_id string (e.g., "12345abcd,67890efgh").
    • For admins, the sys_ids resolve fine because they have access to all referenced records.
    • For restricted roles (like Customer Contact), if they don’t have read access to one of the sys_ids, the field can’t resolve properly. When you reset the value with g_form.setValue(), the portal clears it because the user doesn’t have permission to see those sys_ids.
  2. Double setValue Call
    • You’re calling g_form.setValue('watch_list', trimmed.join(',')); and then immediately calling g_form.setValue('watch_list', g_form.getValue('watch_list'));.
    • That second call is redundant and can cause the field to re-render incorrectly, especially for non-admins.
  3. ACLs / Role Restrictions
    • The Customer Contact role may not have read access to the sys_user table or specific users in the watch list. When you trim and reset, the portal tries to resolve the display values but fails, resulting in a cleared field.

 

 Recommended Solution:

function onChange(control, oldValue, newValue, isLoading) {

    if (isLoading || !newValue) {

        return;

    }

 

    var wl_array = newValue.split(',');

 

    if (wl_array.length > 2) {

        var trimmed = wl_array.slice(0, 2);

 

        // Only set once

        g_form.setValue('watch_list', trimmed.join(','));

 

        setTimeout(function() {

            g_form.showFieldMsg('watch_list', 'You can select a maximum of 2 people.', 'error');

        }, 200);

    }

}

 

Key Changes:

  • Use newValue instead of g_form.getValue('watch_list') (more reliable in portal).
  • Remove the redundant second setValue.
  • Ensure ACLs allow the Customer Contact role to read the sys_user records being added.

 

 Next Steps to Test

  • Check ACLs: Verify that the Customer Contact role has read access to sys_user and specifically the users being added to the watch list.
  • Test with newValue only: See if the clearing issue disappears when you rely on the passed-in newValue.
  • Portal vs. Native UI: Confirm behavior in both — sometimes portal scripts behave differently than native UI scripts.

 

My bet is that the combination of redundant setValue and restricted ACLs is causing the clearing. If you fix the script as above and confirm ACLs, the issue should resolve.

 

If my response helped please mark it correct and close the thread so that it benefits future readers.

 

Best,

Anupam.