7.1: UI Policies and Business Rules Flashcards
Scripting Areas in ServiceNow
ServiceNow has over 30 places where code can be inserted to change the behavior of the platform.
- Data Policies
- UI Policy and UI Policy Actions
- UI Actions ———-
Business Rules ———-
Client Scripts ———-
ACL Scripts ———-
SCRIPTING ———-
UI Macros
UI Scripts
UI Properties
UI Pages ———-
Flow Scripts ———-
Transform Maps ———-
Script Includes ———-
JavaScript is used almost everywhere, and it is a very flexible and powerful language commonly known for its inclusion in most modern web browsers.
This has made it almost mandatory for web development these days, with its simple syntax allowing many people to quickly add simple logic to web pages with minimum effort. Taking advantage of this familiarity, ServiceNow uses JavaScript both on the server and on the client. In this module, we will cover the highlighted concepts. 346
Sample Policies, Actions, Rules, and Scripts
*UI Policy can make fields read-only, mandatory, or hidden
*UI Action can make Save button visible on form for appropriate users
*Data Policy can enforce mandatory data on form
*Data Policy can enforce mandatory data on import
*Business Rule can trigger confirmation email to caller when Incident is first submitted.
*Client Script can prompt that an Incident has been successfully submitted
What is Scripting in ServiceNow?
Scripting in ServiceNow or Platform Scripting is the customization of an instance and/or applications using JavaScript.
JavaScript may execute on the client side (web browser) or the server side (ServiceNow database) and can fundamentally alter the baseline instance and user experience.
Client / Server
Client refers to an application or system that accesses a remote service or another computer system, known as a server. A server is the computer program running as a service; a physical computer dedicated to running one or more services, or a system running a database.
ServiceNow uses an Application Platform as a Service ( aPaaS) model
the web browser is the client. The web browser is the only thing that is installed on the client. The application server and the database live at the Data Center. Client scripts run on t he client browser. Server scripts run on the server (which includes the database).
Client-to-server round-trips take time and make the end-user wait for the round-t rip to complete. Request + Response = Round t rip
UI Policy and UI Policy Actions
*A User Interface (UI) Policy is a rule that is applied to a form to dynamically change information or the form itself.
*UI Policies execute on the client side.
*Use a UI Policy to set fields on a form to:
* Mandatory or Optional
* Hidden or Visible
* Read-only or Editable
*To apply a UI Policy to all views, set the Global setting to true.
*Once a UI Policy is saved, UI Policy Actions determine what happens on the form, including:
* Setting a field as mandatory – requiring a value in order to save the record
* Setting a field as hidden – no longer displaying a field on the form
* Setting a field as read-only – preventing a user from updating its value
*UI Policies are not about security, they are about managing the user experience and data integrity.
To immediately implement updates and changes to form s and lists, you can use UI Policies which allow you to
add sophisticated controls without having to write scripts and define custom process flows for tasks. 349
Data Policies
Internet <->Application Server <->
ServiceNow Database
are similar to UI policies, but UI Policies only apply to data entered on a form through a standard browser. Since UI Policies can also manage the visibility of fields on a form, you may want to augment UI Policies with Data Policies.
A Data Policy is
a rule that enforces data consistency by setting fields as mandatory and/or read-only.
Internet
Application Server
ServiceNow Database
Data Policy controls are similar to UI Policies, but UI Policies are only enforced on data entered into a form (passing through the UI).
Data Policies are similar to UI policies, but UI Policies only apply to data entered on a form through a standard browser. Since UI Policies can also manage the visibility of fields on a form, you may want to augment UI Policies with Data Policies.
Data Policies are applied to all data entered into the platform: form (UI), Import Sets, or Web Serv ices.
A Data Policy executes on the server side but can also run as a UI Policy on the client side.
A Data Policy enforces
(Presadzujú sa zásady údajov)
requirements on field and record data when the data is inserted into ServiceNow or when the data in an Import Set is submitted through an external system. Data Policies can be opted out for Web Services and Import Sets. A Data Policy is used to set mandatory and read-only states on form fields. Data Policies can be used on lists to make a field read-only; the field will appear to be editable, but the update will fail.
*The purpose of a Data Policy is to standardize the same data across ServiceNow applications.
*NOTE: Data Policies are not about security, they are about managing the integrity of the information stored in the database. Defining a Data Policy enforces the policy when a record is submitted from the UI. This behavior cannot be changed. 350
User Interface (UI) Actions
add buttons, links, and context menu items on forms and lists, making the UI more interactive, customizable, and specific to user activities.
The New button on the existing list of All Incidents is an example of a UI Action.
UI Actions can contain scripts that define custom functionality.
UI Actions can be server or client side depending on the ‘client ‘ check box selection. This setting determines when a UI Action can appear.
UI Act ions include:
- Form buttons
- Form context menu items (right-click the header)
- Form links (Related Links in a form) * List buttons
- List context menu items (right-click a record)
- List choices (at the bottom of a list)
- List links (Related Links at the bottom of a list)
NOTE: When the UI Actions Active box is checked, the UI Action is visible and can be interacted with by a user. 351
Client scripts
make “real-time” changes to the appearance of the user interface, especially forms.
Client Scripts can be created to do the following:
✓ Automatically update the location field to reflect the value
(user) entered into the caller field
✓ Disable the attachment link of a closed record when the form is loaded so a user is unable to add or modify attachments
✓ Display a notice at the top of the page to confirm a catalog request was submitted