User Tools

Site Tools


b

Welcome to our SNOW INFO PAGE Section B

B

Badge / Badges

- An icon / indicator that appears next to a permanent screen element, and indicates a temporary condition such as unread records available.


Benchmarks / Benchmarking

- Allow you to compare 23 Key Performance Indicators (KPIs) against those of other ServiceNow customers. 4,000 companies participate anonymously. - Allows members of an “Industry” to see how they are doing compared to others. It is Opt-In - Tells how the customer performs compared with peers in the industry. - What actions can the customer take to improve performance against process Benchmark KPIs??? - Benchmarks Dashboard

  1. Real time comparison with monthly updates.
  2. Allows customer to improve process performance by implementing proven recommendations.
  3. Drives continual service improvement by finding improvement opportunities on KPIs.

——

Business Logic

- To view the different types of Business Logic associated with a table, open any record, then from the Additional Actions menu, choose Configure - All. - Business Logic Types include the following…

Logic Type Table Involved Runs on Client or Server Involves Script Trigger Conditions Notes View Rule sysrule_view Client Yes Form Displayed Form Field Values (Filter) View rules can be used to force the user to see a particular view of a form. Style (Field Style) sys_ui_style Client HTML Allows you to declare individual CSS styles (such as colors) for a field in a list or form. Catalog UI Policy catalog_ui_policy Client Yes ExecuteIfTrue ExecuteIfFalse Catalog Item onLoad or onChange Variable Values (Filter) For setting variables to Read-Only, Mandatory, or Visible, OR for running arbitrary script, all based on a set of Conditions on one or more Variables. Catalog UI Policy Action catalog_ui_policy_action Client No Client Script sys_script_client Client Yes onLoad, onChange, onSubmit, and onCellEdit of Form's Table + Field “Desktop”, Portal, or All. 100% Script. No “Actions”. Uses these APIs: Glide Form, Glide User, Glide Record, Glide AJAX. May be used to abort Form Submission. Has access to the prior values of fields. Only apply to Forms and List Views. OnCellEdit is used in List Views when the list editor changes a cell value. Catalog Client Script catalog_script_client Client Yes Any onLoad or onChange of a Variable or onSubmit of the Catalog Item. “Desktop”, Portal, or All. - Used to manage the behavior of Catalog Items when presented to users. - Provides form validation and dynamic effects. - May be applied to the Catalog Item, Catalog Tasks, and/or a Target Record Producer Record. UI Policy sys_ui_policy Client Yes (Advanced View) onLoad or onChange Form Field Values (Filter) For setting form fields to Read-Only, Mandatory, or Visible, OR for running arbitrary script, all based on a set of Conditions on one or more Variables. These are executed After Client Scripts. UI Policy Action sys_ui_policy_action Client No UI Action sys_ui_action Client OR Server Yes Table Record presented on Form or List View Script Role A control (button, link or menu item), added to the Platform User Interface to execute some Script. The Script executed may be either Client-Side or Server-Side. You must specify a Table that the UI action is related to. A single UI Action may be presented in multiple ways, such as a button and a menu item. Dictionary Entry sys_dictionary Server No This is basically just a Column definition for a table. You may specify the data type, column name, column label, default value, mandatory flag, etc. You may also specify a choice list (reference) table, and if the field is a Calculated field. Dictionary Entry Override sys_dictionary_overridet Server No - Dictionary overrides provide the ability to define a field on an extended table differently from the field on the parent table. For example, a field for the Incident table may have a different default value than for the parent task table. Access Control sys_security_acl Server Yes Various User-Based Actions such as Record or Field Access Role, Filter, Script Limits access to Tables or Columns, or other objects such as Scripts or UI Pages, to only those users with a particular role, or where a particular record filter is met, or where arbitrary script returns a value of true. Business Rule sys_script Server Yes Database Access such as Query, Insert, Update, or Delete, OR “Query for Display” Role, Filter, DB Operation

May execute Before (record access), After (record access), or even Asynchronously.

Actions Tab may be used to set field values without writing Script. Advanced tab allows arbitrary “Conditions” Script and “Execute Rule” Script.

A “Display” Business Rule executes when a database record is queried for display on a form. It may pass data from the server to the client using the g_scratchpad object. All property values are passed as strings. g_scratchpad has no properties set by default. Any client script can use the g_scratchpad object passed in from the server. Note that “Display” is one of the “When to run” values for a Business Rule. Script Include sys_script_include Server Yes Explicitly called Arbitrary Server Side Script. This is library code which may be called (included by) script elsewhere in the system. Data Policy sys_data_policy2 Server No Insert or Update ??? Field Values (Filter) Allows you to enforce data consistency by setting a field to Mandatory or Read Only. No other logic comes into play. Applies to all entry points for a database update, including Forms, List Views, Import Sets, and Web Services. (May be enforced on the UI also, which effectively mimics the Data Policy as if it were a UI Policy, and causes fields to be marked as Read Only or Mandatory on the form.) Data Policy Rule sys_data_policy_rule Server No Flow / Workflow sys_hub_flow Server No (Not directly) Any Database Action, Scheduled Event (Date), Inbound Email, SLA Expiration, Script (explicit call), or Service Catalog Request. Field Values (Filter) A designed sequence of decisions and actions, linked together for the purpose of automating a business process. Notification (Email) sysevent_email_action Server No Record Inserted or Updated, Event Fired, or Flow Action Field Values (Filter) OR Scripted Condition An email to a fixed or variable set of Groups or Users. Notification Email Scripts sys_script_email Server Yes Scheduled Job sys_trigger Server Yes Schedule Scripted Condition Could be any one of these job types: Data Export or Import, Data Collection, Report Email, Script Execution, & others. Scheduled Script Executions sysauto_script Server Yes RunThisScript Schedule Scripted Condition Script Action sysevent_script_action Server Yes When an Event is generated Scripted Condition This is basically an event handler. Its script attached to an event. Installation Exit sys_installation_exit Server Yes

Business Partners * / ServiceNow Business Partners Fine a Partner - Summarized in separate document: “Partners.xlsx” ! - This lists all of the various business partners, and their “level” of engagement with ServiceNow. - Good resource for job hunting. - Partner Levels Registered Partner: For partners new to ServiceNow, who have met minimum qualification requirements for the program and who have yet to achieve measurable activity or certifications.

Specialist Partner: Provides highly specialized skills in a specific area in one or more ServiceNow products.

Premier Partner: Focuses on fewer than five ServiceNow products in multiple regions.

Elite Partner: Specializes in five or more ServiceNow products across the IT, Employee Experience and Customer Service workflows and has established operations in multiple geographies.

Global Elite Partner: An Elite partner with deep industry expertise; digital transformation skills, including business process re‑engineering and organizational change management; global scale; commitment to achieve a $1 billion (USD) ServiceNow practice within three to five years; and “CEO‑level” commitment to a ServiceNow practice. This designation is reviewed annually.


Business Rules

https://docs.servicenow.com/bundle/rome-application-development/page/script/business-rules/concept/c_ScriptingWithDisplayBusinessRules.html - Takeaway Much customization of platform behavior is done using business rules. A business rule is server-side logic, including Script, that is associated with database access. A business rule may launch an asynchronous operation, and may also pass information back up to the UI using the “scratchpad”. - Table

sys_script

- Modules [Any Record] - Configure - Business Rules System Definition - Business Rules. System Scheduler - Scheduled Jobs - Scheduled Jobs - [Look for Scheduled Job names starting with ASYNC] System Logs - System Log - Application Logs System Diagnostics - Session Debug - Debug Business Rule - Much customization of platform behavior is done using business rules. - A Business Rule is Server-Side logic which is tied to Database Access, and which may be configured and/or scripted. Configuration is defined using the “When to Run” and “Actions” tabs, while scripting is defined on the “Advanced” tab. - A Business Rule is always tied to database access, and may be set to run either Before or After, a database record is:

Inserted
Updated
Deleted	
Queried
Queried-for-Display

- Use Cases

  1. Set a database field dynamically (based on the values of other fields)

- Automation of a process

  1. Change field values
  2. Generate an informational message which appears at the top of a form or under a field, after an insert or update
  3. Prevent a user from accessing or modifying certain fields
  4. Abort the entire database action if certain conditions exist

- Important: Business rules automatically propagate to child tables. A rule on the Task table affects Incident, Problem, and Change. - Order of Operations (top to bottom)

User or Database Action			Business Rule			Number of Browser Request to Server
1) User or System Query Initiated						1
						1.1) Before Query		1
2) Database Query Runs								1
						2.1) Display			1
3) Form Submit Action								2
						3.1) Before			2
4) Database Operation Performed						2
						4.1) After			2
						4.2) Async			NA / After Request 2

- When to Run tab: - The business rule logic will only be executed against the table, for the selected database operations, if the Role Conditions and the Filter Conditions evaluate to True. - Filter Conditions further restrict when the Business Rule actually runs. Filter Conditions may check field values.

The Condition box is expected to Evaluate to true or false.  You do not "return" values from the condition box.

- Business Rules typically run after a user submits a form. - When field: Before - Use this when performing a calculation to generate a new value/ to write to the database.

	Display
		- "Display rules are processed when a user request a record form."  (Execute when a record is queried for display on a form.)

- The data is read from the database, display rules are executed, and the form is presented to the user. - Use this when you want to pass useful data from the database up to the client using the “Scratchpad” (g_scratchpad). - Dot walking is not supported on the client, so you can use the g_scratchpad object to feed dot-walked Server side values to the client. - Requires a corresponding Client-Side script (to do something with the g_scratchpad values) in order to be useful.

  1. Example - Server Side:

g_scratchpad.MyOwnVariable = “XYZ”; g_scratchpad.callerDepartement = current.caller_id.department.name;

  1. Example - Client Side:

function onLoad() {

		g_form.setValue("description", g_form.getValue("description") + " " + g_scratchpad.MyOwnVariable);	

} After - Use this when making a change to a related record. Async - Use this when invoking an external Web Service through a REST API, or when performing SLA calculations. - An Asynchronous (Async) Business Rule runs after a database operation, but also happens in a different processing thread, allowing the main transaction to complete more quickly, and return control to the UI/User. Async Business Rule logic is queued up by a scheduler, and run in “near real time” (as soon as possible). - Actions tab: - Without writing script, the “Actions” tab allows you to: - Push a message back up to the client for display on whatever form triggered the business rule. - Abort the entire database action. - Set field values, to arbitrary values, or based on the values of other fields. - Hidden Feature: Business rules can reference fields inside related records (Dot Walking) Access these fields by selecting the very last item in the Field Dropdown, which is “Show Related Fields”. This will refresh the list and allow you to choose related tables and fields in the very same dropdown. - Advanced (Script) tab:

  1. Allows you to incorporate/call:

Script Includes

	Glide Record API
	Workflows
	The triggering of Integration Logic

- Important! There is a “Script Tree” which provides a list of the objects you can access as you are writing script. The Script Tree may be toggled on by clicking on the Right arrow icon. (Note, the Script Tree is NOT available in other script editors such as the one for Script Includes or the one for Scheduled Script Executions.)

- Important! There are two GlideRecord objects available to Business Rule Scripts, passed in as objects to the executeRule() function: - current - includes the current value of all fields as they were set on the client, when the request was passed to the server. - previous - includes the values of all fields as they were when the record was initially loaded from the database record, and before any changes were made in the UI on the client.

  1. See also

Server-Side API Classes

	Debugging

——

b.txt · Last modified: 11/14/2023 12:07 by johnsonjohn