Data policies, unlike UI policies, execute on the server. They are closely linked to UI policies in terms of behavior and functionality. They can even be used as UI policies on the client, when implemented (however, with limited functionality). Strangely, data policies reside in the sys_data_policy2 table. That 2 is not a typo; it has been that way at least as far back as Eureka.
Data policies allow you to prevent certain changes on the server, by rejecting database updates that don't fit the criteria laid out in the data policy. You can either prevent edits by making a field read only, or you can require a field value by making a field Mandatory, using a data policy rule.
While data policies can be used as UI policies on the form, they lack some functionality provided by UI policies. You cannot, for example, make a field visible or hidden using data policies, because there is no server-side equivalent of a contextually hidden field. There is also no advanced view, no scripted conditions, and no UI or server-side scripting possible through a data policy (except to the extent that scripting is possible inside of any condition builder to make a determination about whether the data policy should run).
Data policies do however, have Reverse if false functionality. This applies to both the server-side actions, and the effective UI policy on the form, if the Use as UI Policy on client field is enabled.
When a data policy rejects an update, it is basically the same thing that happens when you call current.setAbortAction(true); in a business rule script. We'll go into more detail about business rule/server-side scripts in a later chapter.
As with UI Policies, let's explore data policies in ServiceNow by creating one! Let's create a data policy that prevents users from re-opening a Virtual War Room, once it's closed:
- Navigate to the Virtual War Room table that we created in an earlier chapter, and click on the hamburger menu at the top-left. Choose Configure, and then click on Data Policies.
- On the Data Policies list, click the blue New button at the top-left to create a new data policy record. The Table field will automatically be set to the Virtual War Room [
u_virtual_war_room] table, since that was the table that was automatically added to our query on the data policies table when we navigated there from the Virtual War Room list/form. - On the data policy form, set the Short description to
Prevent re-opening War Rooms, and ensure that Use as UI Policy on client is checked. - Add a condition to the Conditions field that contains:
[State] [is one of] [Closed Complete, Closed Incomplete, Closed Skipped]. Include any other closed states in your instance, if you have any:
- Right-click on the form header, and click on Save to save the record and reload the form without returning you to the previous page. This step, saving the record to the database and thus assigning it a Sys ID, causes the related list Data Policy Rules to render.
- In the Data Policy Rules related list, click on the blue New button. The Table field should again be automatically populated.
- In the Field name field, select State. Set the Read only field to True, but leave Mandatory as Leave alone. Then, click Submit. This will return you to the Data Policy record.
Now, if you set the State field on a Virtual War Room record to a Closed state, it will turn the field to read-only because the Use as UI Policy on client check-box was checked. If we didn't have that field set to true, then the field would not appear to be read-only on the client, but once a record was saved with a Closed state value, if you tried to re-open it and save it again, you would receive an error in the client saying Invalid update, and another error with a Data Policy Exception.
You might be thinking: "Why not just use a UI Policy to prevent this change?"
This is a legitimate question. The answer is that UI policies only execute on the client, and only inside of the user's browser. This means that any sufficiently clever user can bypass UI policies, but it also means that any alternative method of making a change to the database (such as via a script, a web services API, or even editing a field in the list view) can bypass this protection. For this reason, anything that's quite important to conditionally protect or require, should be done via a data policy, or some other server-side mechanism in addition to the client-side mechanism.
Data policies have a unique place and purpose within ServiceNow, just like UI policies and ACLs each have their own place.