# ⚙️ Demystifying UI Actions in ServiceNow: Everything You Need to Know!

[Bhavesh Patil]

Hey #ServiceNowCommunity 👋

Ever clicked buttons like **"Resolve Incident"**, **"Close Task"**, or **"Approve Request"** in ServiceNow?

Chances are—you've already used a **UI Action**.

In this article, I’ll walk you through the complete understanding of UI Actions, covering:

✅ What they are

✅ Key fields on the UI Action form

✅ Client vs Server-side scripting

✅ Importance of `gsftSubmit()` and how it works

✅ Best practices

Let’s get started!

---

## 🔍 What is a UI Action?

A **UI Action** in ServiceNow allows you to create custom **buttons, links, or menu items** on forms, lists, or related lists that execute client-side or server-side logic.

UI Actions are used to:

* Trigger scripts or workflows

* Automate record updates

* Provide user-friendly buttons for common tasks

* Show or hide actions based on field values, roles, or conditions

> 🛡️ *Note: Only users with the `admin` or `ui_action_admin` role can create or modify UI Actions.*

---

## 📋 Key Fields on the UI Action Form (Explained)

Here are the essential fields you’ll find while configuring a UI Action:

Field	Description
Name	Developer-friendly unique identifier
Action name	Used to reference the UI Action in scripts
Table	Specifies the table where the action will appear (e.g., `incident`)
Order	Defines the sequence in which the action appears
Condition	Expression or script to control button visibility
Script	Core logic (client or server-side)
Client	Checkbox — checked if the script runs on the client side
OnClick	Name of the client-side function defined in the Script field
Form button / List banner / Context menu	Choose where this UI Action should be visible

---

## 💻 Client-side vs Server-side Scripting

UI Actions can operate in three modes:

### 1️⃣ Client-side (`Client` checkbox = true)

* Runs in the user’s browser

* Uses objects like `g_form`, `g_user`, `alert()`, etc.

* Great for validations, confirmations, or UI manipulations

### 2️⃣ Server-side (`Client` checkbox = false)

* Executes on the server

* Can utilize `GlideRecord`, `gs.addInfoMessage()`, etc.

* Best for performing updates, workflows, and database logic

### 3️⃣ Client + Server (via `gsftSubmit()`)

* Starts with a client-side function

* Calls `gsftSubmit()` to submit the form and invoke server-side code

---

## 🧠 Understanding How UI Action Scripts Execute

> 🔎 Did you know?

> Any script written **outside** a function on a UI Action is executed **immediately** when the form loads — **not** when the button is clicked.

So, use function blocks and refer to them via the `OnClick` field to avoid unintended execution.

function confirmAndSubmit() {

if (confirm("Are you sure you want to close this task?")) {

g_form.setValue('state', '3');

gsftSubmit(null, g_form.getFormElement(), 'unique_action_name');

}

}

Then in the **OnClick** field:

`confirmAndSubmit();`

---

## 🔁 Importance of `gsftSubmit()`

`gsftSubmit()` plays a vital role in hybrid (client + server) UI Actions.

### 🔹 What it does:

* Submits the form to the server

* Triggers the server-side portion of the UI Action script

### 🔹 When to use:

Use it when both client-side validation **and** server-side processing are needed.

> ⚠️ Without "gsftSubmit()", the server script will not execute in a client-based UI Action.

---

### 🔹 Sample Structure for Client + Server Logic

```javascript

function triggerUIAction() {

gsftSubmit(null, g_form.getFormElement(), "my_ui_action");

}

if (typeof window === 'undefined') {

// Server-side logic here

runServerSideCode();

} else {

// Client-side logic here (if needed)

}

function runServerSideCode() {

gs.addInfoMessage("Server-side code executed.");

}

```

---

## ✅ Best Practices for UI Actions

* Use **Identicle button labels** to indicate the action clearly

* Control visibility using **conditions** and **roles**

* Keep **client-side logic minimal**, move processing to the server

* Use `gsftSubmit()` only when a server-side script is needed

* Test thoroughly in all roles and conditions

* Avoid clutter — only show actions relevant to the user

---

## 💼 5 Real-Time Complex Use Cases

1. **Close Incident with Mandatory Resolution Notes**

* Client: Validate that `close_notes` is filled

* Server: Update state to Closed, set resolution date

2. **Reopen a Resolved Case**

* Visible only if state is Resolved

* Server: Reset state and clear resolution fields

3. **Escalate Ticket on SLA Breach**

* Appears when SLA is breached

* Server: Reassign to Tier 2 and log escalation

4. **Generate PDF Report for Current Record**

* Button triggers server-side GlidePDF logic

5. **Bulk Approve Related Child Tasks**

* Client: Prompt user for confirmation

* Server: GlideRecord loop to approve all child tasks

---

## 🧠 Final Thought

UI Actions are more than just clickable buttons — they’re a powerful way to streamline user interaction, enforce business logic, and enhance the ServiceNow UI.

Mastering their behavior — especially the balance between client and server logic, and the use of `gsftSubmit()` — can take your ServiceNow development skills to the next level.

---

🙌 If this post helped you learn something new or gave you clarity on UI Actions,

👉 **Please mark it as *Helpful* or *Correct* — it really means a lot!**

Happy developing,