UI POLICY &

UI ACTION
UI Action:
◦ In ServiceNow, a UI Action is a button or link that can be added to a form, list, or related list to perform a specific action
or task. UI Actions are typically used to automate tasks or simplify user interactions within the platform.
◦ Configure UI actions to make the UI more interactive, customized, and specific to user activities.
◦ When a user clicks on a UI Action, the script associated with the action is executed. The script can perform a variety of
actions, such as creating a new record, updating an existing record, or running a script.
UI action controls:
You can create a UI action to provide any of these controls:
• A button on a form.
• A context menu item on a form that appears when you open the form context menu or right-click the form header.
• A related link in a form.
• A button in the banner on top of a list.
• A button at the bottom of a list.
• A context menu item on a list that appears when you open the list context menu or right-click the list header.
• A menu item for the action choice list at the bottom of a list.
• A related link at the bottom of a list.
◦ UI policies:

◦ UI policies dynamically change the behavior of information on a form and control custom process flows for tasks.
◦ For example, you can use UI policies to make the number field on a form read-only, make the short description field
mandatory, and hide other fields. Basic UI policies do not require any scripting, however for more advanced actions, use
the Run scripts option.
◦ You can also use client scripts to perform all of these actions, but for faster load times use UI policies when possible.

◦ UI Policies or Client script which is more faster When it comes to performance:

◦ UI policies are generally faster than client scripts in ServiceNow. This is because UI policies are executed on the server side,
while client scripts execute on the client side (i.e., in the user's browser).
◦ UI policies are used to dynamically set field attributes, such as read-only, mandatory, or visible, based on specified
conditions. When a form is loaded, UI policies are executed as part of the server-side processing of the form, and their results
are sent back to the client as HTML. This means that UI policies can take advantage of server-side resources, such as business
rules, ACLs, and database queries.
◦ list and view:

◦ lists and views are two different types of user interfaces for displaying and interacting with data in tables. A list is a tabular
view that displays a set of records from a table. Lists are typically used to display large sets of data, such as all incidents in
the system or all users in a group. Lists can be filtered, sorted, and grouped to help users find and manage records more
efficiently.
 ◦ A view, on the other hand, is a form-based view that displays a single record from a table. Views are typically used to
display detailed information about a specific record or to allow users to edit the record's fields. Views can include
related lists, which are lists of records that are related to the current record based on a defined relationship (e.g.,
incidents related to a specific user).
◦ UI Policy Form:
When to Apply

Conditions The conditions which, if fulfilled, cause the UI policy to be applied. Conditions are built with the condition builder. To set
conditions using a script, use a client script instead.
Global [Advanced Option for specifying whether the UI policy applies to all form views.
view]
View [Advanced Option for indicating which form view the UI policy applies to. This field is visible only if Global is not selected. If Global is not
view] selected and the View field is left blank, the script applies the default view.

Reverse if false Option for specifying that the UI policy action is undone when the conditions of its UI policy evaluate to false. In other words,
[Advanced view] when the conditions are true, the specified actions are taken and when they are false, the actions are undone.
On load [Advanced • Option for specifying that the UI policy behavior should be performed OnLoad as well as when the form changes..
view]
Inherit [Advanced Option for specifying whether extended tables inherit this UI [Link] a child table has an inherited UI policy from its parent
view] table, the UI policy on the child table always runs first. This event is true regardless of the Order of the UI policies.
•Consider the following example:A child table has a UI policy with Order value 500 that shows the Urgency field when its
conditions are met.
•Its parent table has a UI policy with the same conditions that hides the Urgency field. The parent table UI policy
has Order value 100.
•Although the parent table Order field has a lower value, the child UI policy runs first and then the parent UI policy runs. When
the conditions are met, the Urgency field is hidden.
◦ [Link] a button called Closed My Incident on incident form, so when user click on that button incident will be
resolved or close with correct resolution code. This ui action only visisble onnew state and created by user?
◦ [Link] = 6;
◦ current.close_notes = 'Closed by opened user';
◦ [Link]();