---
sourceDocument: Brazil API Reference
sourceDocumentLink: https://www.servicenow.com/docs/r/api-reference

 Release :

    - brazil

ft:locale :

    - en-US

ft:publication_title :

    - Brazil API Reference

ft:clusterId :

    - crapiref

bundleId :

    - crapiref

workflow :

    - Creator


---

# MobileScripts - Scoped

# MobileScripts - Scoped {#ariaid-title1}

Release version: Brazil  
Updated September 10, 2026  
![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read  
The MobileScripts API is the entry point for loading and calling custom mobile scripts stored in the Mobile Script \[sys_sg_mobile_script\] table.

It works like a script include, and can be resolved both on the device and on the instance.

Use this API to move reusable logic, such as a validator or a formatter, out of the inline expression on a button condition or a write-back action step. The script can then be called by name instead of being duplicated in each
expression. A mobile script can also call another mobile script: the body of every mobile script runs with MobileScripts, [mgs](https://www.servicenow.com/docs/8clGFOAf90NhKkVOLepNkw#MobileGlideSystemScopedAPI "The MobileGlideSystem API provides utility methods for the current session, including user information, date and time values, and script logging."), and [MobileGlideRecord](https://www.servicenow.com/docs/4ZK0Lnx5ps5Dc3iVcod09w#MobileGlideRecordScopedAPI "The MobileGlideRecord API provides the subset of GlideRecord available to mobile scripts, for querying and updating records through the mobile scripting environment.") already in scope, so a script can call `MobileScripts.get('ScriptA')` from within its own source.

When the script is evaluated on the instance, the results of `get()` are cached for the
duration of the transaction, so repeated calls that use the same script name within a transaction don't run the script again. Resolving a script that depends on other scripts is limited by a configurable call depth, which is 25 by
default. If resolution exceeds that depth, an error is thrown. This limit prevents mobile scripts from depending on each other in a loop.

Whether a script that calls this API is evaluated on the instance or on the device depends on how the component that runs the script is configured. The methods in this class are available in both cases: the mobile client provides its
own implementation of the same API surface, so the same script returns the same result in either context. Typical calling contexts include a condition script on a mobile button (sys_sg_button) and an
execution script on a write-back action item or step.

## API access {#MobileScriptsScopedAPI__section_jmx_krp_lkc}

This API is registered in the sn_mobile_scripting application scope and requires the mobile_admin role. It requires the
com.glide.sg.mobile_scripting plugin, which is enabled by default. The class has no constructor. Access it with the static `MobileScripts.get(apiName)` method.

## MobileScripts - get(String apiName) {#ariaid-title2}

Loads a mobile script by its name and returns the value that the script exports, such as a class or function, so that a script can call it right away.
{#MS-get_S__table_MS-get_S_p__entry__3}

| Name | Type | Description |
|-|-|-|
| apiName | String | Name of the mobile script, in the format `scope.name`, such as `global.ValidationHelper`. The name must match a record in the Mobile Script \[sys_sg_mobile_script\] table. |
[Table 1. Parameters]

{#MS-get_S__table_MS-get_S_p} {#MS-get_S__table_MS-get_S_r__entry__2}

| Type | Description |
|-|-|
| Object | The value that the script exports, such as a class, function, or object. If `apiName` does not match a record in the Mobile Script table, the method throws an `IllegalArgumentException` error. When the script runs on the instance, the result is saved for the rest of the transaction, so repeated calls with the same name don't run the script again. |
[Table 2. Returns]

{#MS-get_S__table_MS-get_S_r}  
This example loads a mobile script named `global.TaskValidator`, calls its canComplete() method with the sys_id of the current record, and logs whether the task can be completed.

    var canComplete = MobileScripts.get('global.TaskValidator').canComplete(current.getValue('sys_id'));
            mgs.info(canComplete);

Output:

    true

This example uses the same validator in a write-back action to stop a task from being completed while it has open child tasks. The script handles the case where the mobile script name doesn't match a record, which makes get() throw an error. Keeping the check in a mobile script means that every button and action that needs it calls the same logic.

    try {
            var validator = MobileScripts.get('global.TaskValidator');
            if (validator.canComplete(current.getValue('sys_id'))) {
            mgs.addInfoMessage('Task can be completed.');
            } else {
            mgs.addErrorMessage('Complete all child tasks first.');
            }
            } catch (e) {
            mgs.info('Could not load global.TaskValidator: ' + e);
            }

Message shown to the user when the task has open child tasks:

    Complete all child tasks first.