UI Actions

UI Actions in ServiceNow – Complete Guide for CAD Exam

Introduction to UI Actions

UI Actions are a fundamental component of the ServiceNow Application User Interface that every Certified Application Developer (CAD) candidate must thoroughly understand. They are the mechanism by which buttons, links, and context menu items are added to forms and lists, enabling users to perform specific operations with a single click.

Why Are UI Actions Important?

UI Actions are critical because they serve as the bridge between the user interface and the underlying business logic in ServiceNow. Without UI Actions, users would have no way to trigger custom server-side or client-side scripts directly from forms and lists. Here's why they matter:

• User Productivity: They allow administrators and developers to create streamlined workflows by placing actionable buttons and links exactly where users need them.
• Process Enforcement: UI Actions can enforce business rules and processes by controlling when and how records are updated, submitted, or transitioned through states.
• Customization: They provide a powerful way to extend the default platform behavior without modifying out-of-the-box functionality.
• Consistency: UI Actions ensure that complex operations are performed consistently every time, reducing human error.

What Are UI Actions?

A UI Action is a record in the sys_ui_action table that defines a control (button, link, or context menu item) displayed on a form or list. Each UI Action can contain server-side code, client-side code, or both, which executes when the user interacts with it.

Key Fields of a UI Action Record:

• Name: The label displayed on the button, link, or context menu item.
• Table: The table on which the UI Action appears (e.g., Incident, Change Request).
• Action name: A unique identifier used to reference the UI Action programmatically. This is especially important when calling gsftSubmit() or when referencing from other scripts.
• Form button: When checked, the UI Action appears as a button on the form.
• Form link: When checked, it appears as a link in the form's "Actions" related links section.
• Form context menu: When checked, it appears in the right-click context menu on the form header.
• List button: When checked, it appears as a button at the bottom of a list view.
• List link: When checked, it appears as a link below the list.
• List context menu: When checked, it appears in the right-click context menu on list rows.
• List banner button: When checked, it appears in the list header/banner area.
• Order: A numeric value that determines the display order relative to other UI Actions (lower numbers appear first).
• Active: Determines whether the UI Action is currently enabled.
• Show insert: When checked, the UI Action is visible when creating a new record.
• Show update: When checked, the UI Action is visible when viewing/updating an existing record.
• Condition: A JavaScript expression evaluated server-side that determines whether the UI Action should be displayed. The variable current is available in this field to reference the current record.
• Script: The server-side script that executes when the UI Action is triggered.
• Client: A checkbox that, when selected, enables client-side scripting for the UI Action.
• Onclick: The name of the client-side JavaScript function to call when the UI Action is clicked (only available when Client is checked).
• Client Script: The client-side JavaScript function definition (only available when Client is checked).
• Isolate Script: When checked, the script runs in an isolated scope to prevent conflicts with global scripts.

How Do UI Actions Work?

UI Actions follow a specific execution model depending on whether they are configured as server-side only, client-side only, or both.

1. Server-Side Only UI Actions

When the Client checkbox is not checked, clicking the UI Action submits the form and executes the server-side script defined in the Script field. The script has access to the current object (the GlideRecord for the current record) and the action object.

Example of a server-side UI Action script:

current.state = 7; // Closed
current.update();
action.setRedirectURL(current);

2. Client-Side UI Actions

When the Client checkbox is checked, clicking the UI Action first executes the client-side function specified in the Onclick field. The client-side script is defined in the Client Script field. If the client-side function calls gsftSubmit(null, g_form.getFormElement(), 'action_name'), the form is submitted and then the server-side script executes.

Example of a client-side function:

function confirmClose() {
  var confirmed = confirm('Are you sure you want to close this record?');
  if (confirmed) {
    gsftSubmit(null, g_form.getFormElement(), 'close_record');
  }
}

In this pattern, the Onclick field would contain confirmClose() and the action name field would contain close_record.

3. Combined Client and Server Execution Flow

The execution order when both client and server scripts are configured is:

1. User clicks the UI Action button/link.
2. The client-side Onclick function executes.
3. If the client-side function calls gsftSubmit(), the form is submitted to the server.
4. The server-side Script executes.

Important: If the client-side function does not call gsftSubmit(), the server-side script will never execute. This is a common exam topic.

Key Concepts to Remember:

• action.setRedirectURL(): Used in server-side scripts to redirect the user after the UI Action executes. Without this, the user stays on the same form.
• action.setReturnURL(): Sets the URL to return to after the action completes.
• action.setNoPop(true): Prevents the form from popping/navigating after execution when used with list actions.
• current.update() vs. form submission: If the UI Action is a form button and submits the form, the record is automatically saved. Calling current.update() explicitly in addition to form submission can cause the record to be saved twice, triggering Business Rules twice. To avoid this, set current.update() only when necessary, or use action.setRedirectURL() to prevent double saves.
• g_form.getFormElement(): Used in client-side scripts to get a reference to the form DOM element, required by gsftSubmit().
• Condition field: Evaluated on the server before the form renders. If the condition evaluates to false, the UI Action does not appear. You can use current, roles, and GlideSystem methods like gs.hasRole() in the condition.

Common Use Cases:

• Approval buttons: "Approve" and "Reject" buttons on approval records.
• State transitions: Buttons like "Resolve", "Close", "Reopen" that move a record through its lifecycle.
• Custom operations: "Generate Report", "Send Notification", or "Clone Record" buttons.
• List operations: Bulk actions on selected list records.

UI Action Visibility and Security:

UI Actions can be restricted using:
• Condition field: Server-evaluated JavaScript condition.
• Roles: Only users with specified roles can see the UI Action.
• ACLs (Access Control Lists): Standard ACL rules apply to the underlying operations.
• Show insert / Show update: Control visibility based on whether the record is new or existing.

Scoped vs. Global UI Actions:

In scoped applications, UI Actions follow the scoping rules of the application. Server-side scripts in scoped UI Actions use the scoped API (e.g., GlideRecord in the application scope). The Isolate Script option helps prevent naming conflicts between scopes.

---

Exam Tips: Answering Questions on UI Actions

The ServiceNow CAD exam frequently tests your understanding of UI Actions. Here are targeted tips to help you answer questions correctly:

1. Know the Execution Order: Remember that when the Client checkbox is enabled, the client-side script runs FIRST. The server-side script only runs if the client-side script explicitly submits the form using gsftSubmit(). If a question asks what happens when a client-side UI Action does not call gsftSubmit(), the answer is that the server-side script does NOT execute.

2. Understand the Difference Between Form Buttons and List Buttons: Exam questions may test whether you know where a UI Action appears based on which checkboxes are selected. A Form button appears on the form view; a List button appears on the list view. These are independent settings.

3. Watch for Double Update Traps: A common trick question involves a UI Action that both submits the form AND calls current.update() in the server script. This causes the record to be saved twice. The correct approach is to either let the form submission handle the save or use current.update() but not both. If the question involves preventing duplicate Business Rule execution, look for answers that address this double-save issue.

4. Condition Field vs. ACLs: The Condition field on a UI Action controls visibility (whether the button/link is displayed), while ACLs control access (whether the user can perform the operation). Know the difference for exam scenarios.

5. Remember gsftSubmit() Syntax: The function gsftSubmit(null, g_form.getFormElement(), 'action_name') takes three parameters. The third parameter should match the action name field of the UI Action. This is a frequently tested detail.

6. Know the 'current' and 'action' Objects: In server-side UI Action scripts, current refers to the GlideRecord of the current record, and action provides methods like setRedirectURL(), setReturnURL(), and getGlideURI(). Questions may ask which objects are available in UI Action scripts.

7. Show Insert and Show Update Logic: If both Show insert and Show update are unchecked, the UI Action will NOT appear on the form regardless of other settings. If a question asks why a UI Action is not visible, check these fields first.

8. Client Checkbox Must Be Checked: The Onclick and Client Script fields are only active when the Client checkbox is selected. If a question describes a UI Action with client-side code but the Client checkbox is not checked, that client code will not execute.

9. Order Field: Lower Order values place the UI Action further to the left (for buttons) or higher in the list (for links/menus). If questions ask about button positioning, consider the Order field.

10. Table Hierarchy: UI Actions defined on a parent table (e.g., Task) can appear on child tables (e.g., Incident, Change Request) unless specifically restricted. This inheritance behavior is testable.

11. Practice Identifying UI Action Types from Scenarios: When given a scenario, determine whether it requires a server-side only, client-side only, or combined UI Action. If user confirmation is needed before execution, client-side scripting is required. If only backend processing is needed, server-side only is sufficient.

12. Global vs. Scoped: In the CAD exam, be aware that scoped applications restrict which APIs are available. A UI Action in a scoped application may not have access to certain global APIs unless cross-scope access is granted.

Summary: UI Actions are versatile tools for adding interactive controls to ServiceNow forms and lists. Mastering the fields, execution flow, and best practices around UI Actions will help you confidently answer exam questions and build effective applications on the platform.