Mastering UI Policy Automation in ServiceNow: A Deep Dive with Real-World Examples

In the dynamic world of IT Service Management (ITSM), efficiency and user experience are paramount. ServiceNow, a leading platform in this space, offers powerful tools to streamline operations and enhance how users interact with the system. Among these, UI Policies stand out as a crucial mechanism for controlling form behavior dynamically. This article will dive deep into the practical application of UI Policies, focusing on real-world automation examples and leveraging insights from recent ServiceNow versions.

As of my last update, I’m working with the Washington D.C. release of ServiceNow, the latest and greatest. My journey with ServiceNow began with the Rome release, and I’ve had the pleasure of navigating through San Diego, Tokyo, Utah, Vancouver, and now Washington D.C. This progression has given me a solid understanding of the platform’s evolution and its capabilities.

Understanding the Foundation: Users, Groups, and Permissions

Before we jump into UI Policies, it’s essential to touch upon the underlying concepts of user management and permissions in ServiceNow. This forms the bedrock upon which our automation strategies are built.

User and Group Management in ServiceNow

ServiceNow’s user management is robust, allowing for granular control over who can access what. The primary table for user information is sys_user.

Groups play a pivotal role in organizing users and assigning permissions collectively. The group table is sys_user_group. A key best practice is to manage user permissions through groups. Why? Because when an employee leaves an organization, removing them from the relevant groups automatically revokes their associated permissions. This is far more efficient and less error-prone than manually removing roles from individual users.

Scripting User and Group Creation

While manual creation is an option, scripting offers immense power for bulk operations and automation. Here’s how you can create a user account via script:


var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username = 'jdoe';
userGr.firstname = 'John';
userGr.lastName = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.insert();


And to create a new group:


var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'testing';
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // sys_id of a user
newGr.email = 'testing@tcs.com';
newGr.description = 'test';
newGr.insert();


Assigning Permissions (Roles)

Permissions in ServiceNow are primarily managed through roles. When you assign a role to a user or a group, records are created in specific tables:

• User Roles: The sys_user_has_role table stores the link between a user and their assigned roles.
• Group Roles: The sys_group_has_role table links groups to roles.

Here’s how to add roles via script:

Adding Roles to a User:


var userRole = new GlideRecord('sys_user_has_role');
userRole.setValue('user', '62826bf03710200044e0bfc8bcbe5df1'); // sys_id of the user
userRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // sys_id of the role
userRole.insert();


Adding Roles to a Group:


var grpRole = new GlideRecord('sys_group_has_role');
grpRole.setValue('group', '477a05d153013010b846ddeeff7b1225'); // sys_id of the group
grpRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // sys_id of the role
grpRole.insert();


User Delegation: A Powerful Feature

User delegation is a lifesaver for ensuring business continuity. It allows one user to act on behalf of another, typically when the primary user is unavailable (e.g., on vacation). The delegated user gains access to the delegating user’s tasks and resources. You can configure this by navigating to the original user’s record, scrolling down to the ‘Delegates’ related list, and specifying the delegate, dates, and the types of permissions (assignments, notifications, approvals).

Managing Group Membership

Adding or removing members from groups is a frequent administrative task, efficiently handled with scripts:

Adding a Group Member:


var grMem = new GlideRecord('sys_user_grmember');
grMem.user = '62826bf03710200044e0bfc8bcbe5df1'; // sys_id of the user
grMem.group = '477a05d153013010b846ddeeff7b1225'; // sys_id of the group
grMem.insert();


Removing a Group Member:


var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1'); // sys_id of the user
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // sys_id of the group
grMem.query();
if (grMem.next()) {
grMem.deleteRecord();
}


Interview Relevance: Understanding user and group management, along with role assignments and scripting these operations, is fundamental. Be prepared to discuss the best practice of group-based role assignment and why it’s crucial for security and administration.

UI Policies: Your Gateway to Dynamic Form Control

UI Policies are client-side scripts that allow you to dynamically change form behavior based on conditions. Unlike Business Rules, which primarily run on the server, UI Policies interact directly with the user’s browser, making forms more intuitive and responsive. ServiceNow offers a clean user interface, including UI15, UI16, and the Next Experience UI, all of which respect UI Policy configurations.

Key UI Policy Concepts

• Mandatory Fields: Make fields required only when specific conditions are met.
• Read-Only Fields: Restrict users from editing fields under certain circumstances.
• Visible Fields: Show or hide fields to declutter forms and present relevant information.
• Default Values: Pre-populate fields with specific values.
• Execute scripts: For more complex logic, UI Policies can trigger client scripts.

Interview Relevance: Be ready to explain what UI Policies are, how they differ from Client Scripts and Business Rules, and their primary use cases. The concept of making fields mandatory, read-only, or visible based on conditions is a common interview topic.

Real-World UI Policy Automation Examples

Let’s explore some practical scenarios where UI Policies can automate and enhance user experiences. These examples are common in IT Service Management workflows.

Example 1: Dynamic Assignment Group for Incidents

Scenario: When a user reports an incident related to ‘Hardware’, the ‘Assignment group’ field should automatically populate with the ‘Hardware Support’ group. If the category is ‘Software’, it should default to ‘Software Support’.

Implementation Steps:

1. Navigate to System UI > UI Policies.
2. Click New.
3. Name: Dynamic Assignment Group for Incidents
4. Table: Incident [incident]
5. Order: 100 (or adjust as needed)
6. Applies to a new record: True
7. Applies to the updated record: True
8. Conditions:
• Category | is | Hardware
9. UI Policy Actions (Click “New”):
• Field: Assignment group
• Visible: True
• Mandatory: True
• Value: Hardware Support (select the sys_id of the group)
10. Save the UI Policy.
11. Create a second UI Policy (or add another condition to the first if using advanced conditions) for the ‘Software’ category with the ‘Software Support’ assignment group.

Troubleshooting:

• Assignment Group not populating: Ensure the ‘Order’ of your UI Policies is set correctly. Higher order numbers execute later. Verify the exact name or sys_id of the ‘Hardware Support’ and ‘Software Support’ groups. Check that the ‘Category’ values in the UI Policy conditions match exactly the values in the ‘Category’ field choices.
• Fields showing up incorrectly: Double-check the conditions and the ‘Visible’, ‘Mandatory’, and ‘Value’ settings in the UI Policy Actions.

Example 2: Showing or Hiding Fields Based on Incident Type

Scenario: When an incident is created for a ‘New User Onboarding’ request (perhaps a custom category or a specific subcategory), a new field called ‘Employee Start Date’ should become visible and mandatory. For all other incident types, this field should remain hidden.

Implementation Steps:

1. First, ensure you have a field named ‘Employee Start Date’ (e.g., a Date/Time field) on the Incident table.
2. Navigate to System UI > UI Policies.
3. Click New.
4. Name: Show Employee Start Date for Onboarding
5. Table: Incident [incident]
6. Order: 150
7. Applies to a new record: True
8. Applies to the updated record: True
9. Conditions:
• Category | is | New User Onboarding (or relevant condition)
10. UI Policy Actions (Click “New”):
• Field: Employee Start Date
• Visible: True
• Mandatory: True
11. Save the UI Policy.
12. Now, create another UI Policy to hide this field by default for all other cases.
13. Click New.
14. Name: Hide Employee Start Date by Default
15. Table: Incident [incident]
16. Order: 149 (lower than the previous one)
17. Applies to a new record: True
18. Applies to the updated record: True
19. Conditions: (Leave blank to apply to all records not matched by other policies)
20. UI Policy Actions (Click “New”):
• Field: Employee Start Date
• Visible: False
• Mandatory: False
21. Save the UI Policy.

Troubleshooting:

• ‘Employee Start Date’ field remains hidden: Verify the exact condition used in the ‘Show Employee Start Date for Onboarding’ UI Policy. Check for typos in category names. Ensure the ‘Hide Employee Start Date by Default’ UI Policy has a lower order number.
• Field is mandatory when it shouldn’t be: Review the ‘Mandatory’ settings in both UI Policies. The ‘Hide’ policy’s action should set ‘Mandatory’ to false.

Example 3: Enabling/Disabling Fields Based on State

Scenario: On an Incident record, when the ‘State’ is changed to ‘Resolved’, the ‘Resolution Notes’ field (a mandatory field) should become visible and mandatory. Once the incident is ‘Closed’, both ‘State’ and ‘Resolution Notes’ should become read-only.

Implementation Steps:

1. Navigate to System UI > UI Policies.
2. Click New.
3. Name: Make Resolution Notes Mandatory when Resolved
4. Table: Incident [incident]
5. Order: 200
6. Conditions:
• State | changes to | Resolved
7. UI Policy Actions (Click “New”):
• Field: Resolution Notes
• Visible: True
• Mandatory: True
8. Save.
9. Click New again.
10. Name: Make Incident Resolved/Closed Read-Only
11. Table: Incident [incident]
12. Order: 210
13. Conditions:
• State | is one of | Resolved, Closed
14. UI Policy Actions (Click “New” for State):
• Field: State
• Read only: True
15. Click “New” again for Resolution Notes:
• Field: Resolution Notes
• Read only: True
16. Save.

Troubleshooting:

• ‘Resolution Notes’ not appearing or mandatory: Ensure the ‘State’ condition correctly uses ‘changes to Resolved’. If the incident is already Resolved, and you open it, a ‘changes to’ condition might not trigger. Consider using ‘is Resolved’ or a combination.
• Fields remain editable after closure: Verify the ‘Order’ of the second UI Policy. It needs to execute after any policies that might make fields editable. Check the ‘Read only’ setting for both ‘State’ and ‘Resolution Notes’.

Example 4: Using Script in UI Policies for Complex Logic

Scenario: On a Change Request form, if the ‘Risk’ is ‘High’ and the ‘Assignment Group’ is ‘Change Management’, then a custom field ‘Emergency Change’ should become visible and mandatory. Otherwise, it should be hidden and not mandatory.

Implementation Steps:

1. Ensure you have a custom field ‘Emergency Change’ on the change_request table.
2. Navigate to System UI > UI Policies.
3. Click New.
4. Name: Conditional Emergency Change Field
5. Table: Change Request [change_request]
6. Order: 300
7. Conditions: (Leave blank initially, we’ll use scripts)
8. Advanced: Check this box.
9. Script:
• Condition:

function onCondition() {
if (current.risk == 3 && current.assignment_group == 'your_change_management_group_sys_id') { // Assuming risk 'High' has value 3 and you have the group's sys_id
return true;
}
return false;
}

• UI Policy Actions:
• Field: Emergency Change
• Visible: True
• Mandatory: True
10. Save the UI Policy.
11. Create another UI Policy to hide the field by default.
12. Click New.
13. Name: Hide Emergency Change Field by Default
14. Table: Change Request [change_request]
15. Order: 299
16. Conditions: (Leave blank)
17. UI Policy Actions (Click “New”):
• Field: Emergency Change
• Visible: False
• Mandatory: False
18. Save.

Troubleshooting:

• Script not working: Double-check the syntax of your JavaScript. Ensure you are using the correct values for ‘risk’ (e.g., ‘High’, ‘Medium’, ‘Low’ might have different numerical or string values depending on configuration) and the ‘assignment_group’ sys_id. Use gs.log() in a Business Rule or Script Include for debugging if needed, but for client-side scripts in UI Policies, use console.log() in your browser’s developer tools.
• Field not appearing/disappearing correctly: Verify the ‘Order’ of both UI Policies. The default “hide” policy should have a lower order than the “show” policy.

Interview Relevance: Being able to write simple client-side scripts within UI Policies is a significant advantage. Understand how to use the current object and how to set conditions using JavaScript.

Beyond UI Policies: Related Concepts

While UI Policies are powerful, they are part of a larger ecosystem of form customization and automation in ServiceNow.

Data Policies vs. UI Policies

Data Policies enforce data consistency and integrity at both the client and server sides. They are ideal for ensuring data quality regardless of how the record is accessed (e.g., through a form, import, or API). UI Policies are purely client-side and focus on user experience and form presentation.

You can convert UI Policies to Data Policies for broader enforcement, but there are limitations. Cases where UI Policies cannot be directly converted include controlling data visibility, views, related lists, or when heavy script logic is involved that might not translate cleanly to server-side data policy rules.

Reference Qualifiers

Reference Qualifiers are crucial for controlling the data presented in reference and list fields. They come in three types:

• Simple: Uses basic query conditions (e.g., active=true).
• Dynamic: Uses pre-configured dynamic filter options for context-aware filtering.
• Advanced: Leverages JavaScript for complex, custom filtering logic.

Understanding these is key to building efficient and targeted forms.

Dependent Values

Dependent values create cascaded dropdowns, where the choices in one field (e.g., Subcategory) are filtered based on the selection in another field (e.g., Category). This greatly improves usability.

Attributes

Attributes in dictionary entries modify field behavior. Examples include no_email, no_attachment, tree_picker, and more. They provide a declarative way to customize field functionality.

UI Actions and Client Scripts

While UI Policies handle dynamic form elements, UI Actions add buttons and links to forms, triggering server or client-side scripts. Client Scripts provide more granular control over client-side behavior and can be used in conjunction with UI Policies for more complex interactions.

Conclusion

UI Policies are an indispensable tool for any ServiceNow administrator or developer. By leveraging them effectively, you can create dynamic, user-friendly forms that guide users through processes, reduce errors, and improve overall efficiency. The ability to automate field visibility, mandatory status, and read-only properties based on real-time conditions is a cornerstone of modern ITSM. As you continue your ServiceNow journey, from Rome to Washington D.C. and beyond, mastering UI Policy automation will undoubtedly be a key differentiator.