Module III notes.pptx

UI Customization Customization refers to any change that is made to the baseline installation code of an instance. These code changes are usually done by clients in order to come up with functionality that is not a part of ServiceNow. When a client doesn’t want to ad...

UI Customization Customization refers to any change that is made to the baseline installation code of an instance. These code changes are usually done by clients in order to come up with functionality that is not a part of ServiceNow. When a client doesn’t want to adopt the default ServiceNow workflows and wants to change the platform’s functionality according to their existing business processes and workflows, go for customization. 1  Customization Challenges Getting out-of-control Most clients tend to start their journey with configuration. As time passes, the desire to customize increases. But one customization can quickly become five and then five can quickly spiral out of control. 2  Customization Challenges Cost, efforts, and resources Since customization involves significant development time for functionalities to be built from scratch, the overall cost and effort go up. The degree of customization and increase in costs are directly proportional. Need to hire more ServiceNow developers and experts to implement, maintain and upgrade the customized platform. 3  Customization Challenges Upgrades ServiceNow releases two new upgrades for the platform per year, ie. the addition of new features, functionalities and applications, and enhancements to the existing ones. In a customized ServiceNow environment, upgrades usually are delayed. Involve lot of effort and resources Pose a threat of breaking or skipping the customizations Increase bugs and glitches May loose new functionality 4  When You Should Customize ServiceNow? A general recommendation to clients is to configure the platform but not customize. Only when the required functionalities cannot be offered at all customization is considered. Clients usually take the customization route when they want to retain their existing business workflows. 5  When You Should Customize ServiceNow? Customizing the ServiceNow platform requires a considerable amount of financial resources and multiple stakeholder buy-ins. To customize the platform, make sure that no constraints are there in these areas. Security is the major concern and always needs to be a priority while customizing the platform. 6  When You Should Customize ServiceNow? Upgrades have to be tested extensively before being implemented. The scope of work should be kept in mind, and shouldn’t extend beyond what is agreed upon. Time and cost should be considered, whenever new feature is built, the existing code doesn’t break. So intensive regression testing is necessary. 7  Customizing Instance Appearance An administrator can change system properties to alter the look and feel of the default instance interface, functionality is not affected. Organizations often use multiple instances to separate development, testing, and production activities. To help users avoid accidentally changing the wrong instance, administrators can configure each with a visually distinct theme. 8  Customizing Instance Appearance Several approaches are available for defining an instance theme. CSS (Cascading Styling Sheet) properties Navigate to System Properties > CSS. The following properties are available through CSS properties: 9  Customizing Instance Appearance Banner text color Banner and list caption background color Font used in forms and lists (a global font setting) Button styles (background color, border color, border width, text color) Field status indicator colors (including the indicators for changed, mandatory populated, mandatory unpopulated, and Read-only) 10  Customizing Instance Appearance List cell vertical alignment Navigator menu styles (text font size, background color, text color) Header font name and size List and form caption color override Global text search background color (both for catalog results and knowledge base results) 11  UI impacting System properties The behavior of a ServiceNow instance is controlled by System Properties. System properties can add options to the system and keep people from making modifications to back-end code later. Business rules, UI actions, and UI pages rely on system properties. 12 13  Set up an Approval Engine To manage the approvals for each of the Task tables in the system, set up an approval engine. Navigate to All >System properties> Approval Engines The Approval Engine option for each Task table is shown in the figure. If the Approval Engine option is greyed out and shows Turn engines off, the reason is that the workflow is managing the approvals on the table. Having the approval engine turned off prevents conflicts with the workflow that could cause a range of issues. To use an approval engine on the table, set the workflow to inactive. 14  LDAP Lightweight directory access protocol (LDAP) is a protocol that helps users find data about organizations, persons, and more. LDAP has two main goals: to store data in the LDAP directory and authenticate users to access the directory. LDAP integration in ServiceNow can simplify user management and enhance security by utilizing existing directory services. Proper configuration and regular maintenance are crucial to ensure a smooth and reliable integration. 15 16  System localization properties System properties are used to localize the instance for users from multiple countries. Some localization properties only appear after the international plugins are activated, some properties are available on the System Localization properties page, but some are available only from the System Properties [sys_properties] table. Access the properties by navigating to All>System properties> System Localization 17  System Diagnostics The System Diagnostics application provides logs that relate to the platform. To aid in performance evaluation, the Stats Tools records statistics for system activities that affect performance such as the execution of queries, scripts, and transactions. 18  UI impacting System properties Creating or Editing a Property Most of the system properties can be found in left navigation under the ‘System Properties’ application. All properties in the system are stored in the ‘sys_properties’ table and can be viewed and edited there by typing ‘sys_properties.list’ into the left navigation filter. Add a property to the system by creating a new record in the ‘sys_properties’ table. 19  UI impacting System properties Adding property to a properties page Properties pages are just a URL that pulls together one or more System Property Categories into a single UI page to be viewed. Create or modify these categories by navigating to ‘System Properties->Categories’. One of the properties categories for the Email 20 settings is shown in fig. 21  UI impacting System properties glide.email.smtp.active – System property that controls whether the SMTP server is active and can send emails from the instance. It has a Boolean value True/ False. glide.email.read.active – It enables / disables reader functionality. 22  UI impacting System properties glide.email.server – Specify the address of SMTP server that the instance will use to send e-mails. It enables e-mail notification alerts. glide.email.user – It holds the username the ServiceNow instance will use to authenticate with the SMTP server. 23  UI impacting System properties glide.email.user.password – It is a property to store passwords for the e-mail account that ServiceNow uses to send and receive e-mails. glide.email.username – It shows the identity of the sender when sending mails. glide.smtp.auth – It specifies whether SMTP authentication is required when sending emails. 24  UI impacting System properties Give the category a name, which will be referenced in the page URL, a title - which will be displayed as a section header and add properties to the related list at the bottom of the page. Accessing a properties page Create a module that points to the correct URL to include the categories and present them all in one page. How the email properties page works is shown in fig. 25 26  UI impacting System properties This example points to a properties page with a title of ‘Email Properties’ that includes 5 properties categories – ‘Email’, ‘POP3’, ‘Email Security’, ‘Email Auto User’, and ‘Email Advanced’. 27  UI impacting System properties A system properties page URL needs to have 3 different parts. 1. A pointer to the properties UI page (https://demo.service- ow.com/system_properties_ui.do) 2. A ‘sysparm_title’ parameter to add a title to your page (sysparm_title=Email%20Properties). 3. A ‘sysparm_category’ parameter to indicate which properties categories should be included in the page. 28  UI impacting System properties To access a system property in client script, the following ways are used. 1. Add the property to your session client data No need to do an expensive GlideRecord query to get the property information. It gets added to the client session data when the session is established for a particular user. 29  UI impacting System properties GlideRecord is a class used to interact with the ServiceNow instance's database from inside of a script. This GlideRecord class provides many helpful API methods to retrieve, update, create or delete records stored in your ServiceNow instance. GlideRecord allows developers to perform complex queries, and filter data based on a variety of conditions. GlideRecord queries can return one or more records, which can then be used to perform further operations. 30 In UI impacting System properties 2. Add the property to the ‘g_scratchpad’ object using a ‘Display’ business rule This option is similar to the previous one, but doesn’t set the property for the entire session, just for the table you’re working on. It is a Javascript variable which allows to store data and pass it between client side scripts and server side scripts. It acts as a container for temporary data that can be used within the context of a specific client transaction. 31  UI impacting System properties Accessing the value set in g_scratchpad on the client side ( in a Client Script): // Accessing the value from g_scratchpad on the client side var myValueFromServer = g_scratchpad.myKey; alert("Value from g_scratchpad: " +myValueFromServer); 32  UI impacting System properties Data stored in g_scratchpad is specific to the current user’s session and will not continue across different user sessions. The g_scratchpad data is automatically cleared when the current client transaction ends. It is recommended to use g_scratchpad for short-term storage of non-sensitive data only. 33  UI impacting System properties The g_scratchpad object is a dictionary-like structure, can store key-value pairs. It is automatically available on both client-side and server- side scripts without the need to declare it explicitly. Setting values in g_scratchpad on the server side: // Setting a value in g_scratchpad on the server side gs.log("Setting value in g_scratchpad"); 34 var myValue = "Hello, world!"; g_scratchpad.myKey = myValue;  UI impacting System properties gs.log is a server side logging statement in ServiceNow. When executing this code, it will create an entry in the system log, log entries are found in System Logs module in ServiceNow. 35  UI impacting System properties 3. Create a GlideRecord Query and pull from the ‘sys_properties’ table. It is the simplest, but can also be a huge performance killer. This method should only be used if no other method is available. Avoid Gliderecord in the client side script because running in user’s browser lead to excessive round trips between browser and server, thus slow down the user experience and result in performance issues. 36  UI impacting System properties Exposing sensitive data to users who have no access to it may cause security risks. The client side scripts may not have the same level of validation and data integrity checks as server side scripts. To perform a client-side GlideRecord query, set the script to run that query asynchronously which means that the query will run in the background without blocking other JavaScript code from executing. 37  UI impacting System properties The script will continue to run while the query is being processed. This approach allows the user interface to remain responsive, and other interactions on the page can still happen while the query is ongoing. Eg. To query the "incident" table, create a GlideRecord object for it: var gr = new GlideRecord('incident'); 38  Service Portal Configuration Page Most Service Portal configurations are accessible through the Service Portal configuration page. Access the Service Portal configuration page by navigating to Service Portal > Service Portal configuration. 39 40  Service Portal Configuration Page A portal is a ServiceNow user interface (UI), built using the Service Portal framework, which provides an alternative user experience to the standard UI. It is the way for users to interact with the Now Platform using a minimum number of clicks from any device: desktop, tablet, or smartphone. The Server Configuration Portal helps to configure, manage and troubleshoot User Workspace Manager servers and databases. 41  Creating a custom Home page Users with at least one role can create new personal homepages that are visible to themselves. If Unified Navigation is enabled, it is not possible to create new homepages or edit existing homepages. Role required: admin Create a new personal homepage with no content on it, or create a new homepage that uses the content of an existing page. 42  Creating a custom Home page The personal homepage is only visible if the administrator makes the homepage global. The dashboards provide an easier interface for creating, organizing and sharing content. 1. Navigate to All > Self-Service > Homepage to open current homepage. 2. Click the new page icon ( ). the new homepage appears with a single drop zone. 3. Add content as needed. 43  Widgets Widgets are reusable components which make up the functionality of a portal page. Widgets define what a portal does and what information a user sees. ServiceNow provides a large number of baseline widgets. Examples: Announcement widgets Users can view all active announcements. Use this base system widget to suit your own business needs. 44  Widgets Announcement widget 45  Widgets Approvals widget Users can approve or reject items directly within Service Portal. 46  Widgets Change password widget Users can change their passwords using the Change Password widget. 47  Widgets Organization Chart widget The Organization chart widget shows employees in a tree structure relative to their manager. One can use this base system widget to suit his/her own business needs. 48 49  Widgets A Widget is the code template used to display content in the portal. A Widget Instance is created when a Widget is added to a page. Every time a Widget is added to a page it creates a new Widget Instance. To customize a widget in Service now, In the main ServiceNow browser window, use the Application Navigator to open Service Portal > Service Portal Configuration> Widget Editor tile 50  UI and Data policies o ServiceNow defines UI policies as a tool through which, we can dynamically change the behavior of information on a form and control custom process flows for tasks. UI action makes the UI more interactive, customized, and specific to user activities. The UI action can be implemented through an easy-way-to-use interface and also through the client script. Writing client scripts will help to do advanced operations in the field. 51  UI Policies Navigate to All > System UI > UI Policies Click New, The UI Policy [Advanced view] form opens To change the view, in Related Links click Default view Complete the form, need to configure the form to see all the fields. 52 UI policy fields Field Description Table The table for the form to be modified. Active The active status of the UI policy. Only active UI policies are applied. Short description Short summary of the UI policy. Order [Advanced view] The processing sequence, from the lowest to highest number. If two policies conflict, the UI policy with the higher number executes. For inherited UI policies, the extended (child) table's UI policies are executed first. Then the base table UI policies are executed, both from lowest to highest specified value. 53 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. Conditions are only rechecked if a user manually changes a field on a form. Global [Advanced view] Option for specifying whether the UI policy applies to all form views. By default, the Global UI policy applies to all form views. 54 View [Advanced view] A UI policy can be specific to a view. Eg. define a UI policy for only the ITIL view of a form. Use the View field to achieve this. Option for indicating which form view the UI policy applies to. This field is visible only if Global is not selected. 55 Reverse if false Option for specifying that the [Advanced view] UI policy action is undone when the conditions of its UI policy evaluate to false. When the conditions are true, the specified actions are taken and when they are false, the actions are undone. 56  Reverse if false Reverse if false means that if the condition in the UI Policy doesn't meet the UI policy actions defined will reverse what they do on meeting the condition. i.e. If a UI policy action is making a field mandatory on some condition and if the condition is not met, the UI policy will make the field non mandatory. UI actions are faster and executed first, followed by client scripts. 57  UI Policy fields On load [Advanced view] Option for specifying that the UI policy behavior should be performed OnLoad as well as when the form changes. Check or clear the On load check box in a UI policy to control whether it runs every time a form is loaded when the conditions are satisfied. Eg. an administrator does not want an incident to enter the Awaiting user info state unless the user provides an 58 explanation to the customer.  UI Policy fields The administrator creates a UI policy with the following settings: In the When to Apply section, adds the condition [State] [is] [Awaiting user info] and clears the On load check box. This condition means that the UI policy applies only when the state is changed to Awaiting user info and clears the On load check box, ie the UI policy applies only when the state is changed to Awaiting user info. 59  UI Policy fields  The administrator creates a UI policy with the following settings:  In the When to Apply section, adds the condition [State] [is] [Awaiting user info] and clears the On load check box.  This condition means that the UI policy applies only when the state is changed to Awaiting user info. 60  UI Policy fields In the UI Policy Actions related list, creates a record that makes the Additional comments field mandatory when the condition is met. Inherit [Advanced view] Option for specifying whether extended tables Customizing a form view inherit this UI policy. to include additional fields and information that are When a child table has an not present in the default inherited UI policy from view. its parent table, the UI policy on the child table always runs first. 61  UI Policy fields 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. 62  Data Policy Data policies enforce data consistency and compliance across the platform without the need to write custom scripts. They help ensure that data entered into forms or imported into tables follows the specified rules and standards. Data policies ensure that data meets certain conditions before it is saved. They help maintain data integrity and standardization 63 across the platform.  Data Policy Client-side Data Policies: These are applied in the browser and enforce rules as the user interacts with the form. Server-side Data Policies: These are applied on the server side and enforce rules during data import or via business rules and workflows. Eg. Making a field mandatory, setting a field to read-only based on the role of the user. Automatically setting default values for certain fields based on other field values. 64  Data Policy Data policies are configured in the "Data Policies" module in the application navigator. Administrators can define the table, conditions, and actions for each data policy. Create data policies to enforce consistency. 65  Data policy 1. Navigate to Data Policies by completing one of the following actions. System Policy > Rules > Data Policies. From any form header, right-click the header bar and select Configure > Data Policies. 2. Click New. 3. Select any options for the data policy. 66  Data policy 4. Create the condition that must exist for the platform to apply this policy. For eg, the conditions might include [Problem state] [is] [Closed/Resolved] 5. Right-click the header and select Save. The Data Policy Rules related list appears. 6. Click New in the related list and create the 67 record that identifies the field and the policy to apply. 68  UI and Data policies Data policies are similar to UI policies, but UI policies only apply to data entered on a form through the standard browser. Data policies can apply rules to all data entered into the system, including data brought in through import sets or web services and data entered through the mobile UI. UI policies are used to dynamically change content of forms whereas data policies are used to enforce data consistency. 69  UI and Data policies Data Policies enforce data consistency by setting mandatory and read-only field attributes. Unlike UI Policies, Data policies execute server-side. UI policy logic only applies to data entered in a form. Data policy logic executes regardless of how a record changes. 70  UI and Data policies UI policies are user-friendly ways to control whether fields on a form are mandatory, read-only, or even whether they are visible. Criteria Client Script UI Policy Execute on form load Yes Yes Execute on form save/submit/update Yes No Execute on form field Yes Yes value change Have access to field's old Yes No value 71  Service Now Scripting There are two types of scripting in ServiceNow, Client side and Server side. The server side scripting process takes place at the web server, while client scripting process takes place at the user's machine. There are specific tasks, which could be accomplished by each type of script. 72