Thank you for your feedback.
Form temporarily unavailable. Please try again or contact to submit your comments.

UI pages

Log in to subscribe to topics and get notified when content changes.

UI pages

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.

UI Pages use HTML, Jelly, and AngularJS. To learn more about creating an AngularJS UI page, see the Building Apps with AngularJS training.

Figure 1. UI page form
The UI page form provides the following fields:
Table 1. UI page
Field Input Value
Name Name used to invoke the page via a URL (must not contain spaces).
HTML Main component of the page, and it defines what will be rendered when the page is shown. It can contain either static XHTML or dynamically generated content defined as Jelly, and it can call script includes and UI Macros.
Client Script Client-side JavaScript that runs in the browser (e.g. functions called by buttons, etc.). It is intended to handle any client-side processing needed, for example setting focus to a field, or other interactive DHTML features after a page is loaded. Ultimately, a UI page's Client Scripts are deployed to the browser within a <script/> tag, so it could be defined within the page's HTML field to achieve the same effect. Using the Client Script field instead to define these scripts makes things much more tidy and readable though, and it keeps the Jelly and HTML from becoming unmanageable.
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).
Related lists on the form view:
Versions Shows all versions of the UI page. Use this list to compare versions or to revert to a previous version.

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
For details on creating an ACL rule, see Create an ACL rule.

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> If the page was part of a custom application called example_app, you would instead navigate to https://<instance name>

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: / 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:
<j:set var = "jvar_user_id" value = "${sysparm_user}" />
  <g:evaluate> var userRoles = new GlideRecord('sys_user_has_role');
  <select id='select_role'> 
      <j:while test = "${}"> 
          <option value = "${userRoles.sys_id}"> ${} </option> 

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 [] and set it to false to temporarily allow the evaluation of URL parameters passing scripts in UI pages.

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 could then access it using just application_sys_id:
var application = new GlideRecord('hr_application');
 application.status = "Rejected";
 var urlOnStack = GlideSession.get().getStack().bottom();

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.