Introduction

In #1 we explored the Inherited, Global and Isolate Script checkboxes. In #2 we talked about writing clean, efficient client code. But here is the reality today: your users are no longer only on the classic form. Agents live in Service Operations Workspace, employees raise requests on Service Portal or Employee Center, and catalog owners build items in Catalog Builder.

So the big question is: will my client script still run there? In this part, let us walk through where client scripts run, where they don't, and what to use instead.

1. The UI Type field — your first checkpoint

Every client script has a UI Type field with three options: Desktop, Mobile / Service Portal, and All. This one field decides where the script executes.

UI TypeRuns on

Desktop

|

Classic platform UI (Core UI) only

|
|

Mobile / Service Portal

|

Service Portal, Employee Center, Now Mobile

|
|

All

|

Classic UI, Workspaces, Portal and Mobile

|

The most common community question is "my client script works in the form view but not in the workspace." In most cases the fix is simple: set UI Type to All. Record pages in Configurable Workspaces respect classic client scripts, but only when UI Type allows it (community thread).

A second, less obvious cause: the field your script reads must be present on the workspace form. If it is hidden or not on the view, the client simply does not have its value — only server-side code can read it.

2. What is NOT available outside the classic UI

Remember the Isolate Script checkbox from #1? In Workspace and Service Portal, isolation is not a choice. The scripting environment does not give you window, document, jQuery or angular (How to use UI Actions in Workspaces). This means:

• No DOM manipulation (gel(), document.getElementById(), $()).
• No synchronous GlideRecord or getXMLWait() — they are not supported on Portal and Mobile.
• No GlideDialogWindow / GlideModal from UI Pages.

If your script only uses documented g_form, g_user, GlideAjax and g_scratchpad APIs, it will travel well across every UI. This is one more reason why the "avoid DOM" rule from #2 matters.

3. UI Actions in Workspace: Workspace Client Script and g_modal

UI Actions with the Client checkbox have a separate field called Workspace Client Script , plus Workspace Form Button and Format for Configurable Workspace. Your classic onClick script will not run in a workspace; the Workspace Client Script will.

Instead of GlideModal, use g_modal. It offers showFields(), showFrame(), alert(), confirm() and confirmDestroy().

function onClick(g_form) {
    g_modal.showFields({
        title: 'Reason for putting on hold',
        fields: [{
            type: 'textarea',
            name: 'work_notes',
            label: getMessage('Reason'),
            mandatory: true
        }],
        size: 'lg'
    }).then(function(fieldValues) {
        g_form.setValue('work_notes', fieldValues.updatedFields[0].value);
        g_form.setValue('state', '3'); // On Hold
        g_form.save();
    });
}

Need the server-side part of the UI Action as well? Call g_form.submit(g_form.getActionName()) from the workspace script. For lists and related lists in workspace, look at Declarative Actions instead — UI Actions only appear in the form action bar.

4. Service Portal and Catalog Client Scripts

Catalog client scripts follow the same rules, with a few extras worth knowing:

• Applies on checkboxes: Catalog Item view, Requested Items, Catalog Tasks and Target Record. Untick what you don't need — fewer scripts loading means faster forms.
• UI Type = All if the item is ordered from Portal or Employee Center (which is almost always).
• Use spModal (Portal only) for prompts and confirmations, not confirm() or GlideModal.

• In a Multi-Row Variable Set (MRVS), use g_service_catalog.parent to read variables from the parent item:

  function onLoad() {
  // Inside an MRVS catalog client script
  var requestedFor = g_service_catalog.parent.getValue('requested_for');
  if (requestedFor) {
  g_form.setValue('approver', requestedFor);
  }
  }

New in Zurich : catalog owners can now create client scripts directly in Catalog Builder (Zurich New Features: Client Scripts in Catalog Builder). That is great for productivity, but it also means more people writing client code. Agree on a naming convention and review process early.

5. UI Builder client scripts are a different animal

The name is the same, but UI Builder (page) client scripts are not form scripts. They react to events, read and write client state parameters, and work with data resources through the api object (UI Builder Client Scripts vs Classic😞

Classic client scriptUI Builder client script

Triggered by

|

onLoad, onChange, onSubmit, onCellEdit

|

Component or page events

|
|

Main API

|

g_form, g_user, GlideAjax

|

api.state, api.data, api.emit, api.context, helpers

|
|

Purpose

|

Field behavior and validation on a form

|

Page logic, data binding, event handling

|
|

Where

|

sys_script_client

|

UX client script on the page

|

Rule of thumb: if you are controlling a form field, write a classic client script (or a UI Policy). If you are building page behavior in a custom workspace page, use a UI Builder client script.

6. Quick checklist before you say "it's done"

• UI Type set deliberately (All, unless you have a reason)
• No DOM, jQuery or window references
• Fields used by the script are on the workspace and portal views
• Workspace Client Script filled in for client UI Actions
• Catalog scripts: Applies on checkboxes reviewed
• Tested in classic UI, Workspace and Portal

Conclusion

Client scripts are not tied to one screen anymore. A script that is well-scoped, DOM-free and uses documented APIs will work everywhere your users are. In the next part (#4) we will go deeper into asynchronous patterns, debugging, and how to test client scripts — including new ATF capabilities in the Australia release.

 

If you found this helpful, please mark it Helpful and share your own workspace and portal gotchas in the comments!

Thank You!

Regards,

Kailash Bhange,

 

LinkedIn