ServiceNow Certification Mock Exams
Click To View Now
A common task you will be asked to perform as a ServiceNow developer is to configure forms. Since forms are the main way to access and populate tables in ServiceNow, it will be necessary at some point for you to modify the behavior of fields on a form.
There may be a requirement to make a specific field read only or to clear the value of a field under certain conditions. The simplest and most convenient way to do these things and more is by using UI policies.
If you are not familiar with UI policies, this article will provide the necessary information for you to begin utilizing them. We will discuss what a UI policy is, when and where to use it, and other tips to help you better understand UI policies.
UI policies allow developers to control the behavior of fields on a form. They're mostly used as a way to make fields mandatory, visible or read-only. The best part about them is that they can be done with no code, so they're super easy and quick to configure.
UI policies work client-side, meaning the action is executed when the end user interacts with ServiceNow in their browser.
There is an option to use JavaScript in UI policies, however most of the time scripting is not necessary to achieve the desired results.
If scripting in a UI policy, it is important to note that UI policies have access to the client-side GlideUser (g_user) and GlideForm (g_form) classes.
For a reference on how to use g_user and g_form in your UI policies, check out our posts below on gs.getUser and g_form script cheat sheets:
The two areas within the ServiceNow platform where UI policies are most commonly used are tables and catalog item forms.
Table UI policies are found on the UI Policy table and catalog item UI policies are on the Catalog UI Policy table. They are both configured in a similar way. The UI policy record is where you define the conditions in which the UI policy will execute, as well as write any scripts.
There are also two related tables for UI policies that are important to be aware of. Those tables are UI Policy Action and Catalog UI Policy Action. These tables are where you configure the actions (make a field visible, mandatory, etc.) and associate that action back to a specific UI policy. UI Policy Action records have a reference to a UI Policy and Catalog UI Policy Action records reference a Catalog UI Policy respectively. This is relevant because when a UI policy triggers, all the related actions will also execute.
If this is getting confusing at all, don’t worry! These topics are covered in more depth as we move through the article.
There is one more thing to highlight regarding UI policies and scripting. You want to try to create UI policies that either don’t need scripting or require very simple scripts. The main value of a UI policy is that it’s low to no code. If you need to add more complex client-side logic, it is best practice to use client scripts.
UI policies and client scripts are both client-side records in ServiceNow that can be used for similar purposes. For example, either one could be used to make a field mandatory, visible, or read only.
As mentioned previously, it’s best practice to stick to UI policies for the simpler actions that require little to no scripting.
One important call out here is that UI policies will execute after client scripts. You will want to make sure that you are not overriding any necessary client scripts when developing UI policies. If you’re not careful, you may accidentally undo some logic from a client script by configuring a UI policy that does the opposite thing.
For instance, if a client script sets a field to mandatory and a UI policy sets that same field not mandatory, the field will end up being not mandatory. If unaware of the execution order, you could create a confusing situation for yourself as a developer. Pay attention to the execution order to ensure that you are not creating any conflicts.
Let’s discuss how to configure a UI policy in ServiceNow.
To create a UI policy, navigate to System UI > UI Policies. Click the “New” button at the top-right of the screen and you will be directed to the form shown below. Catalog UI policies can be created by navigating to any catalog item and creating a new record from the Catalog UI Policies related list.
The top section of the form only has a few fields available for configuration.
Table specifies which table the UI policy will apply to. This field is only available for standard UI policies. On catalog UI policies, you will instead define the catalog item that the policy applies to.
Unlike the majority of records in ServiceNow, UI policies do not have a name field. In this case the Short Description field is where to include some text to indicate what the functionality of the UI policy is.
The When to Apply tab contains additional configuration fields.
Conditions allows developers to build filter conditions to determine when the UI policy will trigger. UI policies will always execute when there is a change on the form and the conditions in this field evaluate to true. On load, which is checked by default, will ensure that the UI policy will run when the form loads as well as when something changes. If you would like a UI policy to always execute, leave On load selected and the Conditions field empty.
Reverse if false, also checked by default, will instruct ServiceNow to take the opposite actions if the conditions evaluate to false. For example, if a UI Policy makes a field mandatory under certain conditions and Reverse if false is checked, then when the conditions are not met the field will be not mandatory. This feature is convenient for developers as you don’t have to worry about creating separate UI policies for both true and false conditions.
The Inherit checkbox will specify if this UI policy should be inherited by child tables. If you ever experience a weird issue where a UI policy seems to be firing but you cannot find it on a specific table, check the parent table and see if there is a UI policy with Inherit checked as that may be causing the issue. Inherit is not available for catalog UI policies. Instead, there are options to define if the catalog UI policy applies to the catalog item view (front end), requested items or catalog tasks (backend for catalog items), or target record (backend for record producers). Those catalog UI policy fields are shown below.
The Script tab, like the name implies, is where all the scripting for a UI policy takes place. Instead of using UI policy actions (discussed in next section) to define what a UI policy will do when it executes, developers are given the option to script the behavior of a UI policy. The following is a screenshot of the Script tab.
When the Run scripts field is checked, the rest of the fields on this tab become visible (which coincidentally is handled by UI policies on the UI Policy table).
The Run scripts in UI type field has 3 options: “Desktop”, “Mobile / Service Portal”, and “All”. This field defines which user interfaces this UI policy will apply to. Usually, you’ll want to check ‘All’ but it totally depends on your requirements. When I first started in ServiceNow, I would wonder why my UI policy wasn’t triggering - it was always because this field wasn’t set to ‘All’ so the Service Portal wasn’t picking it up! So be sure to check here if it feels like your UI policy won’t trigger.
Make note that there are two fields that allow scripting, Execute if true and Execute if false. If scripting the actions for a UI policy, the “Reverse if false” logic discussed earlier does not apply. You must script both the true and false actions for your UI policy. It’s also a good idea to use either scripting OR UI policy actions in a UI policy because sometimes using both can cause issues.
Next, let’s take a look at UI policy actions. These can be created from the UI Policy record by clicking the “New” button on the UI Policy Actions related list. This is how you will define the behavior of your UI policy. We can see the available fields for UI policy actions below.
The UI Policy and Table fields are auto populated (if created from the related list) with the values from the UI policy.
Field name allows developers to specify the field that the action will apply to. You will be able to choose any fields from the table in the Table field, however each UI policy action can only apply to one field. There can be as many UI policy actions as you need on a UI policy to achieve the results you are looking for. Typically, a UI policy will have several UI policy actions with each applying to different fields on the table.
The Mandatory, Visible, and Read Only fields each have the same three options: “Leave Alone”, “True”, and “False”, with “Leave Alone” being the default. You can set each of these fields to whatever value makes sense for your UI policy.
The Clear the field value checkbox, if selected, will clear the value of the specified field when the UI policy executes. This is sort of counter-intuitive, since most developers will create UI policies to make something visible, mandatory, or read only. When doing that you typically would not also want to clear a value of that same field. However, using Clear the field value in combination with Reverse if false and some clever condition building, you can create powerful UI policies that can ensure you get all the correct data from end users while clearing any garbage data. We will see an example of this in the next section.
Now that we understand how to configure UI policies, let’s look at some examples! Our first example is a simple UI policy on the Change Request [change_request] table. It will make the Justification field read only when the change reaches a State of “Scheduled” or beyond. The following shows the UI policy configuration to accomplish this.
This is one of the many ways you can build conditions for your UI policies. For this example, it’s important to know that the State field in ServiceNow is an integer field and the actual value of “Scheduled” is -2. This can be verified by examining the dictionary entry for State. The condition is essentially checking if the State is greater than or equal to -2.
For change requests, the states are ordered numerically based on where they fall in the workflow, so this UI policy will cover “Scheduled” as well as any state after it. We could have also used State “is one of” for the condition and selected all the appropriate states. If you look at the UI Policy Actions related list, you can see that the Justification field is being made read only by this UI policy. As mentioned previously, you could add more UI policy actions if needed.
The next example is a bit more complex. The UI policy makes a field visible and mandatory under certain conditions. We created a new field on the change request table called Additional details for use in this demonstration.
This type of UI policy configuration was mentioned earlier when discussing using Clear the field value in combination with Reverse if false. Let’s walk through the logic of this UI policy. This UI policy will execute when the condition of Category is not “Other” is met.
The UI policy action does three things under this condition: make the Additional details field not visible, not mandatory, and clears the field value. Basically, this UI policy could be understood as when Category is anything besides “Other”, hide Additional details and clear the data in that field.
Since Reverse if false is selected, the UI policy will do the opposite if the Category is “Other”, which gives us the desired result of making Additional details visible and mandatory. This may seem like a backwards way of configuring UI policies, but the advantage of doing this is that you can then use Clear the field value to ensure that you aren’t taking in unwanted data. In this case, the Additional details will always be cleared unless the user selects the appropriate category.
Our final example shows how to use scripting in a UI policy. This UI policy prevents users from entering a Planned start date that is in the past. We use scripting to flash an error message and clear the value if an invalid date is entered.
The condition for this UI policy is checking if the value of the Planned start date is in the past. Since On load is not checked, this UI policy will only execute when the field is changed.
Remember, we have access to the client-side g_form API which was used for all the functionality in the scripts. The code in the Execute if true block will clear the value of this field and show an error message on the field informing the user that the “date cannot be in the past”.
Clearing the field value ensures that the user cannot submit invalid data.
The code in the Execute if false block simply clears all the messages once the user enters a valid date. This ensures that the error message is not visible to users when entering correct data. This scenario is a good example of when it is useful to script in a UI policy.
Creating and configuring UI policies is a valuable skill for any ServiceNow developer. Since UI policies are found across the platform, it is important to understand how they work and how to use them.
Our goal for this article was to provide you with enough information to begin configuring them on your own. There are many more use cases to explore regarding UI policies. As always, we encourage you to grow and expand your knowledge, but hope that we can help get you started on the right path!
Looking for something else? Check out our other posts below!
