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 UI > UI 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:
Table 1. UI page
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.
Related lists on the form view:
Access Controls View and configure access controls for the UI page. See Use access controls on UI pages for more information.
Versions Shows all versions of the UI page. Use this list to compare versions or to revert to a previous version.

Access control

A UI page can be secured by creating an ACL with the following parameters:

  • Type: ui_page
  • Operation: read
  • Name: Name of the UI page to be protected
  • Role: User role that is allowed to access the record
When saving a new UI Page, you will be prompted to assign a role for access control.Role selection for access control for a new UI page.
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.

High risk UI pages

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.
  • Does not 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.

UI page access

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 [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

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.
  2. Navigate to All > System UI > UI Pages.
  3. Select New.
  4. Complete the form.
    See UI pages 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.Displays the role based access control modal.
  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:
  1. Open a UI page from the UI pages table.
  2. View the Access Controls under the related lists.
  3. 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.
  4. Complete the form and assign a role to the UI page.
    For additional information on access control, see Create an ACL rule.
  5. Select Submit for a new access control or Update for edits.
    Note: There can be multiple access controls per UI page.

Secure UI pages

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.

UI page security recommendation messages.

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 sectionsHTML and Processing script examples.
  • 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.
See UI pages for details on high risk UI pages.

Conditions that display the security recommendations message

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).

Conditions that don’t display the security recommendations message

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

If your UI page contains a form (uses the <g:form> 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 application_sys_id 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 application_sys_id:
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.