What are UI Policies?

UI Policies dynamically change form behavior based on specified conditions. They control field visibility, mandatory status, and read-only state without requiring JavaScript code.

Key Advantage

UI Policies are declarative (no-code) and easier to maintain than client scripts. They run automatically when conditions are met, making forms responsive to user input.

UI Policy vs Client Script

Feature UI Policy Client Script
Coding Required No (declarative) Yes (JavaScript)
Actions Visible, Mandatory, Read-only Any form manipulation
Complexity Simple conditions Complex logic
Performance Optimized Depends on code
Maintenance Easier Requires developer

Creating UI Policies

Components of a UI Policy

  • Conditions: When should the policy run? (e.g., Priority is 1)
  • UI Policy Actions: What fields to affect and how
  • Execute on server: Run on form load (server-side)
  • Reverse if false: Undo actions when condition becomes false
Example: Priority-Based UI Policy
Table: incident
Conditions: Priority is 1 (Critical)
Actions:
  - assignment_group: Mandatory = true
  - assigned_to: Mandatory = true
  - work_notes: Visible = true
  
Reverse if false: Yes
Execute on server: No (runs client-side)
Best Practice

Use "Reverse if false" to automatically undo policy actions when conditions no longer match. Keep UI Policies simple - use client scripts for complex logic.

UI Policy Actions

UI Policy Actions define what happens to specific fields when policy conditions are met.

Available Actions

Action Description Example
Mandatory Makes field required Make assignment_group mandatory for P1 incidents
Visible Shows/hides field Show resolution fields only when state is Resolved
Read only Makes field non-editable Make number field read-only after creation
Example: State-Based Visibility
UI Policy: Show Resolution Fields
Table: incident
Conditions: State is Resolved OR State is Closed
UI Policy Actions:
  1. Field: close_notes
     - Visible: true
     - Mandatory: true
  2. Field: close_code
     - Visible: true
     - Mandatory: true
  3. Field: resolution_info (section)
     - Visible: true

UI Policy Scripts (Advanced)

For complex scenarios, you can add JavaScript to UI Policies using the "Run scripts" checkbox.

UI Policy with Script
// Script runs when policy conditions are true
function onConditionTrue() {
    // Get priority value
    var priority = g_form.getValue('priority');
    
    // Set field properties based on priority
    if (priority == '1') {
        g_form.setMandatory('assignment_group', true);
        g_form.setMandatory('assigned_to', true);
        g_form.showFieldMsg('priority', 'Critical - Immediate response required', 'error');
    }
}

// Script runs when policy conditions become false
function onConditionFalse() {
    g_form.setMandatory('assignment_group', false);
    g_form.setMandatory('assigned_to', false);
    g_form.hideFieldMsg('priority');
}
When to Use Scripts

Use UI Policy scripts only when standard actions aren't sufficient. For purely visibility/mandatory/readonly changes, use standard UI Policy actions for better performance.

What are UI Actions?

UI Actions are buttons, links, or context menu items that execute custom functionality on forms, lists, or related lists.

Types of UI Actions

Type Location Use Case
Form Button Top or bottom of form Submit, Update, Close incident
Form Link Form header/footer Open related record, Print
Form Context Menu Right-click menu Insert and Stay, Delete
List Button Above list New, Export, Bulk actions
List Choice Actions on selected dropdown Update selected, Delete selected
List Banner Button List banner area Create new type records

Creating UI Actions

Client-Side UI Action (Form Button)
// UI Action Configuration:
Name: Escalate to Manager
Table: incident
Action name: escalate_manager
Client: true
Form button: true
Condition: current.state < 6 && current.priority <= 2

// Client Script:
function onClick() {
    // Validate
    if (g_form.getValue('assignment_group') == '') {
        alert('Please assign to a group first');
        return false;
    }
    
    // Confirm action
    var confirmed = confirm('Escalate this incident to management?');
    if (!confirmed) {
        return false;
    }
    
    // Update fields
    g_form.setValue('escalation', '1');
    g_form.setValue('priority', '1');
    g_form.addInfoMessage('Incident escalated to management');
    
    // Submit form
    g_form.submit();
}
Server-Side UI Action
// UI Action Configuration:
Name: Assign to Me
Table: incident
Action name: assign_to_me
Client: false (server-side)
Form button: true
Condition: current.assigned_to.nil()

// Server Script:
(function() {
    // Assign to current user
    current.assigned_to = gs.getUserID();
    current.state = '2'; // In Progress
    current.update();
    
    // Display success message
    gs.addInfoMessage('Incident assigned to you');
    
    // Return to form
    action.setRedirectURL(current);
})();
Client vs Server

Client-side: Faster, validates before submission, can prevent form submit. Server-side: Access to full GlideRecord API, more secure for data changes, can trigger business rules.

UI Action Conditions

Conditions control when UI Actions are visible/available to users.

Example Conditions
// Show only for active incidents
current.active == true

// Show for high priority only
current.priority == '1' || current.priority == '2'

// Show only if unassigned
current.assigned_to.nil()

// Show only for specific users/roles
gs.hasRole('itil') || gs.hasRole('admin')

// Show only on new records
current.isNewRecord()

// Show only on existing records
!current.isNewRecord()

// Show based on state
current.state != '6' && current.state != '7'

// Complex condition
current.priority <= '2' && current.assignment_group.nil() && gs.hasRole('manager')

List UI Actions

Bulk Update List Action
// UI Action Configuration:
Name: Bulk Assign
Table: incident
List choice: true
Client: false

// Server Script:
(function() {
    var records = [];
    var sysIds = g_list.getChecked().split(',');
    
    // Get assignment group from user
    var groupID = g_form.getValue('assignment_group');
    
    if (!groupID) {
        gs.addErrorMessage('Please select an assignment group first');
        return;
    }
    
    // Update all selected records
    var gr = new GlideRecord('incident');
    for (var i = 0; i < sysIds.length; i++) {
        if (gr.get(sysIds[i])) {
            gr.assignment_group = groupID;
            gr.state = '2'; // In Progress
            gr.update();
            records.push(gr.number.toString());
        }
    }
    
    gs.addInfoMessage('Updated ' + records.length + ' incidents: ' + records.join(', '));
})();

CSA & CAD Exam Questions (10 Questions)

What is the primary advantage of UI Policies over Client Scripts? Q1
CSA
  • A) They run faster
  • B) They are declarative and require no code
  • C) They can do more actions
  • D) They work on the server side
Show Answer
Correct Answer: B
UI Policies are declarative (no-code) configuration, making them easier to create and maintain than JavaScript client scripts. They're ideal for simple visibility, mandatory, and read-only changes.
What does the "Reverse if false" option do in UI Policies? Q2
CSA
  • A) Reverses the order of actions
  • B) Undoes the policy actions when conditions become false
  • C) Reverses the condition logic
  • D) Prevents the policy from running
Show Answer
Correct Answer: B
"Reverse if false" automatically undoes the policy actions when the conditions no longer match. For example, if a field was made mandatory when priority=1, it becomes optional again when priority changes.
Which actions can UI Policies perform on fields? Q3
CSA
  • A) Only visibility
  • B) Visibility, mandatory, and read-only
  • C) Any form manipulation
  • D) Only mandatory
Show Answer
Correct Answer: B
UI Policy Actions can control three aspects: Visibility (show/hide), Mandatory (required/optional), and Read-only (editable/non-editable). For more complex actions, use client scripts.
What is the difference between client-side and server-side UI Actions? Q4
CAD
  • A) No functional difference
  • B) Client-side is faster and can prevent form submission; server-side has full database access
  • C) Server-side is always better
  • D) Client-side can only read data
Show Answer
Correct Answer: B
Client-side UI Actions run in the browser, are faster, and can validate/prevent form submission. Server-side UI Actions have access to GlideRecord and full server APIs, are more secure for data changes, and can trigger business rules.
Where can Form Button UI Actions appear? Q5
CSA
  • A) Only at the top of the form
  • B) Only at the bottom of the form
  • C) At both the top and bottom of the form
  • D) In the form header only
Show Answer
Correct Answer: C
Form Button UI Actions appear at both the top and bottom of forms by default. You can control their position using the "Show insert" and "Show update" checkboxes.
What does the Condition field in a UI Action do? Q6
CSA
  • A) Executes code when true
  • B) Controls when the UI Action is visible/available
  • C) Validates form data
  • D) Sets the button color
Show Answer
Correct Answer: B
The Condition field determines when the UI Action button/link appears. If the condition evaluates to false, the UI Action is hidden. Example: current.state != '6' shows button only for non-closed records.
When should you use UI Policy scripts instead of standard UI Policy actions? Q7
CAD
  • A) Always use scripts for better performance
  • B) Only when standard actions (visibility, mandatory, readonly) are insufficient
  • C) Never use scripts in UI Policies
  • D) When you want to query the database
Show Answer
Correct Answer: B
Use standard UI Policy actions when possible for better performance and maintainability. Only add scripts when you need complex logic that can't be achieved with standard actions like showing field messages or complex field manipulations.
How do you make a client-side UI Action submit the form? Q8
CAD
  • A) form.submit()
  • B) g_form.submit()
  • C) current.submit()
  • D) action.submit()
Show Answer
Correct Answer: B
In client-side UI Actions, use g_form.submit() to submit the form. You can also prevent submission by returning false from the onClick function.
What type of UI Action is used for bulk operations on list views? Q9
CAD
  • A) Form Button
  • B) List Choice
  • C) Form Link
  • D) Context Menu
Show Answer
Correct Answer: B
List Choice UI Actions appear in the "Actions on selected" dropdown and operate on multiple selected records. They're ideal for bulk updates, deletions, or other mass operations.
Can UI Policies run on the server side? Q10
CSA
  • A) No, they only run client-side
  • B) Yes, when "Execute on server" is checked, they run on form load
  • C) Yes, they always run on the server
  • D) Only with a special license
Show Answer
Correct Answer: B
When "Execute on server" is checked, the UI Policy evaluates on the server during form load, before the form is sent to the client. This is useful for policies that should apply immediately when opening a record.

Key Takeaways

  • UI Policies = no-code field control
  • Actions: visible, mandatory, readonly
  • Use "Reverse if false" for dynamic behavior
  • UI Actions = custom buttons/links
  • Client-side = fast, can prevent submit
  • Server-side = full database access
  • Use conditions to control visibility