---
sourceDocument: Yokohama Build or modify applications
sourceDocumentLink: https://www.servicenow.com/docs/r/yokohama/application-development

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama Build or modify applications

ft:clusterId :

    - cadev

bundleId :

    - cadev

workflow :

    - Development, Data, and Analytics


---

# UI pages

# UI pages {#ariaid-title1}

* Release version: Yokohama
* 
* Updated March 26, 2026
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 7 minutes to read

UI pages can be used to create and display forms, dialogs, lists, and other UI
components.
Use UI pages as widgets on dashboards. To find the UI pages, navigate to System UIUI Pages.

This functionality requires a knowledge of HTML or Jelly. You can also create simple AngularJS applications using UI pages.
The UI page form contains the following fields:{#r_UIPages__table_lxj_31h_y4__entry__2}

| Field | Description |
|-|-|
| Name | Name used to invoke the page via a URL (must not contain spaces). |
| Application | Displays the current application scope. |
| Description | The description of the UI page and what it's used for. |
| Direct | Select this check box for a direct UI page \[sys_ui_page\]. A direct UI page doesn't include the common HTML, CSS, and scripts. This setting requires adding custom CSS and JavaScript to use in the page. |
| HTML | Main component of the page where you define what is rendered when the page is shown. It can contain either static XHTML, dynamically generated content defined as Jelly, or call script includes and UI Macros. Note: If GlideRecord/GlideDBQuery is used instead of GlideRecordSecure, a security recommendation message displays. |
| Client Script | Include client-side JavaScript that runs in the browser, such as functions called by buttons. It's intended to handle any client-side processing needed, like setting focus to a field or other interactive DHTML features after a page is loaded. Client scripts for the UI page are deployed to the browser within a \<script/\> tag, so the content can similarly be defined within the HTML field. The Client Script field can be used instead to define these scripts concisely to maintain the Jelly and HTML manageability. |
| Processing Script | Script that runs on the server when the page is submitted. This is useful if your page has a form defined with the \<g:ui_form/\> or \<g:form/\> tags. Note: If GlideRecord/GlideDBQuery is used instead of GlideRecordSecure, a security recommendation message displays. |
| obsolete-custom-processors | Note: This feature is deprecated. While legacy, existing custom processors continue to be supported, creating new custom processors has been deprecated. Instead, use the [Scripted REST APIs](https://www.servicenow.com/docs/access?context=c_CustomWebServices&version=yokohama&pubname=yokohama-api-reference&ft:locale=en-US). |
| Related lists on the form view: ||
| Access Controls | View and configure access controls for the UI page. See [Use access controls on UI pages](https://www.servicenow.com/docs/access?context=r_UIPages&version=yokohama&pubname=yokohama-api-reference&section=use-access-controls-ui-pages&ft:locale=en-US) for more information. |
| Versions | Shows all versions of the UI page. Use this list to compare versions or to revert to a previous version. |
[Table 1. UI page]

{#r_UIPages__table_lxj_31h_y4}

## Access control {#r_UIPages__section_crf_t4c_fwb}

You can secure a UI page by creating an ACL with the following parameters:

* Type: ui_page
* Operation: read
* Name: Name of the UI page to protect
* Role: User role that is allowed to access the record

{#r_UIPages__ul_jz5_qdh_y4}  
When saving a new UI page, you are prompted to assign a role for access control.  
Note:  
An entry with the same name as the UI page is created in the Access Control table.
For details on creating an ACL rule, see [Create an ACL rule](https://www.servicenow.com/docs/access?context=t_CreateAnACLRule&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US).

## High risk UI pages {#r_UIPages__section_k3s_nwb_fwb}

UI pages are considered high risk with any of the following attributes:

* Uses GlideRecord or GlideDBQuery instead of GlideRecordSecure.  
  Note:  
  This is applicable for HTML and Processing script fields and not Client scripts.
* Doesn't have a corresponding ACL configured.
* Indicates to be a public UI page and is entered in the sys_public record.
* Shows a message to indicate high risk UI page.
* For instances with glide.installation.developer is set to true.
* If resource is customized content for a customer instance.
{#r_UIPages__ul_uxn_swb_fwb}

## UI page access {#ariaid-title2}

Each UI page has a URL computed from the application scope, page name, and the
.do file extension.

For example, to display the page called glidewindow_example on the demo system, you would
navigate to https://\<instance name\>.service-now.com/glidewindow_example.do. If the page was part of a custom
application called example_app, you would instead navigate to https://\<instance name\>.service-now.com/x_example_app_glidewindow_example.do.  
You can also add additional parameters to a URL that can be accessed within a page's HTML section as jelly variables. That is, appending arguments to the URL as follows: /my_test_page.do?sysparm_verbose=true creates jelly variables called verbose that can be accessed as follows:

    <j2:if test="$[!empty(sysparm_verbose)]"> <span>show extra stuff </span> </j2:if >

A common practical example of this might be retrieving a database record for display. To
build a list of a user's roles, pass in a parameter with the user's sys_id. Invoke the
following UI page to display a list of roles for that user with Jelly code:  
`role_select.do?sysparm_user=5137153cc611227c000bbd1bd8cd2007`

    <j:set var = "jvar_user_id" value = "${sysparm_user}" />
     
      <g:evaluate> var userRoles = new GlideRecord('sys_user_has_role');
        userRoles.addQuery('user','${jvar_user_id}');
        userRoles.query(); 
      </g:evaluate>
     
      <select id='select_role'> 
          <j:while test = "${userRoles.next()}"> 
              <option value = "${userRoles.sys_id}"> ${userRoles.role.name} </option> 
          </j:while> 
      </select>

An exception to be careful of, though, is the reserved variable name sys_id. This variable
always contains the ID of the UI page itself, regardless of what is specified in the URL. A
common substitute variable name is sysparm_id.

Do not use URL parameters to load client scripts in UI pages. The system no longer evaluates
scripts that are passed by URL parameter. If your implementation depends on this behavior, you
can [add the system property](https://www.servicenow.com/docs/access?context=t_AddAPropertyUsingSysPropsList&version=yokohama&pubname=yokohama-platform-administration&ft:locale=en-US) \[glide.security.disable_ui_pages_sysparm_client_script\] and set it to
false to temporarily allow the evaluation of URL parameters passing
scripts in UI pages.

## Use access controls on UI pages {#ariaid-title3}

See access controls directly from the UI Page form and add role-based access control
when creating or editing a UI Page record.

### Before you begin

Access controls that have been added to an existing UI page can be accessed and
edited by opening the UI page record under related links.

Role required: security_admin and admin

### Procedure

1. Elevate to the security_admin role.  
   For details on role elevation, see [Elevate to a privileged
   role](https://www.servicenow.com/docs/access?context=t_ElevateToAPrivilegedRole&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US).
2. Navigate to AllSystem UIUI Pages.
3. Select New.
4. Complete the form.  
   See [UI pages](https://www.servicenow.com/docs/access?context=r_UIPages&version=yokohama&pubname=yokohama-api-reference&ft:locale=en-US) for additional information for UI field descriptions.
5. Select Submit or Save.  
   A modal displays prompting you to create a role-based access control for the UI page.
6. Select a role.
7. Select OK to assign the role.  
   You are returned to the UI pages list.

Add, edit, or view access controls for an existing UI page:

8. Open a UI page from the UI pages table.
9. View the Access Controls under the related lists.
10. Select New to create a new access control or select an existing entry for editing.  
    The Access Control form loads. UI Page details are displayed.
11. Complete the form and assign a role to the UI page.  
    For additional information on access control, see [Create an ACL rule](https://www.servicenow.com/docs/access?context=t_CreateAnACLRule&version=yokohama&pubname=yokohama-platform-security&ft:locale=en-US).
12. Select Submit for a new access control or Update for edits.  
    Note:  
    There can be multiple access controls per UI page.

### Secure UI pages {#ariaid-title4}

Access controls and related security messages are integrated on high risk UI Pages
for increased security.
An informational message displays on high risk UI pages to inform the customer to add
a role-based Access Control to the UI page.

The message displays under the following conditions:

* If an ACL (access control list) is missing
* If GlideRecord/GlideDBQuery is used instead of GlideRecordSecure in either the HTML or Processing script sections
* If the UI page is configured as public in sys_public  
  Note:  
  Public UI Pages that are public or that use GlideRecord don't show a missing ACL warning.

{#ui-pages-access-control__ul_ptx_d5b_fwb}See [UI pages](https://www.servicenow.com/docs/access?context=r_UIPages&version=yokohama&pubname=yokohama-api-reference&ft:locale=en-US) for details on high risk UI pages.

#### Conditions that display the security recommendations message {#ui-pages-access-control__section_thk_j5b_fwb}

The message displays under the following conditions:

* All internal instances eclipse/IJ where glide.installation.developer=true.
* All customer scoped UI Page resources.
* Any customized UI Page when the glide.script.ui_page.customer_scoped.security_msgs_enabled property is set to true. (The default value is true).
{#ui-pages-access-control__ul_c1h_m5b_fwb}

#### Conditions that don't display the security recommendations message {#ui-pages-access-control__section_wzx_t5b_fwb}

The message won't display under the following conditions:  
* UI Page is public.
* UI Page is in the Global scope.
* The glide.script.ui_page.customer_scoped.security_msgs_enabled is set to false.  
Note:  
To disable the role-based ACL creation prompt, set the glide.ui_page.enable_acl_create_ux property to false. The property is set to true by default.

## UI page process scripts {#ariaid-title5}

If your UI page contains a form (uses the <var class="keyword varname">&lt;g:form&gt;</var> tag), you
can submit the form and have the process script run.

The processing script can naturally access fields on the form. For example, if your form
contained the <var class="keyword varname">application_sys_id</var> field:

    <g:ui_form>
      <p>Click OK to run the processing script.</p>
      <g:dialog_buttons_ok_cancel ok="return true" />
      <input type="hidden" name="application_sys_id" value="499836460a0a0b1700003e7ad950b5da" />
    </g:ui_form>

You can access the field using <var class="keyword varname">application_sys_id</var>:

    var application = new GlideRecord('hr_application');
     application.get(application_sys_id);
     application.status = "Rejected";
     application.update();
     var urlOnStack = GlideSession.get().getStack().bottom();
     response.sendRedirect(urlOnStack);

Important:  
The preceding script is usable only with Global applications.

If you are using the UI page for a dialog, you can also reference the most recent URL on the
stack using the code above and then send the response to that location. This is useful if you
want to have the dialog's processing script update something and then redisplay the screen
that brought up the dialog.

*[\>]: and then