- Docs https://docs.servicenow.com/bundle/quebec-platform-administration/page/administer/contextual-security/concept/acl-rule-types.html - Create permissions are the same as whatever is defined for the Write permissions unless you define an explicit Create operation Access Control rule. - The Description field automatically populates when Access Controls are created. - When modifying and testing Access Controls, its very useful to have one web browser open where you do your work as security_admin, and have another, different web browser open where you try things as a non-admin user. For example, login into Chrome as admin / security_admin, and use that for modifying access control records, and log into Edge as a non-admin user with more limited rights. This will lower the number of times you need to execute Impersonate and Un-impersonate actions. - Important. When you stop impersonating a User who is having trouble with security, remember to 1) Stop Debugging, 2) Immediately Elevate Your Roles, so you can see Access Control Conditions. - Debugging Security Rules on a List View - When debugging Access Control issues via Session Debug, you really want to be working with a very small data set if you can. Otherwise you will have a very large number of Access Control debug records appearing at the bottom of each List View, and rendering such pages can become very slow. It can also help to temporarily remove irrelevant fields from forms, so that fewer irrelevant debug message are displayed. - Configure the system to allow list views to show Fewer records. Do this by going to System Properties - UI Properties - Items per Page - 1, 2, 3, 10, etc. - Impersonate the target user. Or use a query which limits the records to just a few. - From the Hamburger Menu of a List View, choose Show - X Rows Per Page, setting X to a low value such as 2 or 3. This will limit the number of log messages and also make it easier to see the security debugging messages under the list view. - You may frequently see the following two failed Access Control rules in the log. They relate to the Application Picker and the Update Set picker. They should normally be ignored in Access Control debugging:

ui/environment.current_application/write
ui/environment.update_set/write 

- Important Security Methods include the following:

Client-Side:
	GlideUser (g_user)
		hasRoleFromList()
		hasRoleExactly() - Returns true if the user has the role specified.
		hasRole() - Returns true if the user has the role specified, OR if the user is an Admin.
		hasRoles() - Returns true if the user has at least one role.
Server-Side:
	GlideRecord (current)
		isNewRecord() - true if the newRecord() method has been called.  Used in scripted ACLs, UI Actions, or Business Rules.
	GlideSystem (gs)

getUserID() - Returns the sys_id of the current user.

		getUser() - Returns a reference to the user object for the current user.
		getUserName() - Returns the name of the current user, such as jsmith.
		getUserNameByUserID()
		getUserDisplayName()
		getSession()
		hasRole("MyRoleName")
		hasRoleExactly() - Does not exist out of the box.  This Article explains how you can define this yourself in a Script Include.
		hasRoleInGroup()
		isLoggedIn()
		isInteractive()
	GlideElement - Provides convenient methods for dealing with fields and their values. Available for the fields of the current GlideRecord.					canCreate()
		canRead()
		canWrite()
		canDelete()

- Quirks - When you elevate your privileges to security_admin, if Developer Studio was already open, you may need to reload Studio using the browser's reload button for Studio to detect the elevated privileges. - If an Access Control does not seem to be working, check to see if there is a duplicate Access Control of the same type. For example, if there are two Delete Access Controls, the user only needs permission from ONE of them to perform the action. The other one may not even be run. - If the user interface is behaving strangely, when you are trying to edit Access Controls, try stopping debugging, and also be sure you have elevated your roles. It seems like the debugger can sometimes interfere with the Access Control forms. - Debug Security Rules (at bottom of web page) does NOT work on the Portal, but security information will be displayed in the independent debugging window. - zMisc - If you go to the Access Controls table, and you do not see a New button, it is because you have not yet issued an “Elevate Roles” command. - Similarly, if you are looking at a field (sys_dictionary), and you do not see the New button in the Access Controls tab, you need to issue an “Elevate Roles” command. - Two-gate system. An authenticated user that wants to access a record for a particular operation (read, write, delete) is first evaluated for the particular field(s) they affect in that table, and then checked for the table-level access - Interpreting Access Control debugging messages. - For a user who DOES have the appropriate role, the field is of course displayed on the form and the Security Rule appears as follows:

Line 1, in green:

Checkmark:					Access granted
Green text:					Access granted

Date and time Access Control was evaluated: 8:14 PM and 46.502 seconds. Time it took to execute Access Control: 0 milliseconds Type of ACL: “record” Table: “business_unit” Field: “u_mystringone” Operation: “read” Context: A record named “Sales” at the underlined URL. Return Code (RC): The entire Access Control evaluated to true (Access Granted) Line 2, starting with the 1st set of circles:

iAccessHandler:					Clear Circle = Not Evaluated.  Blue Circle = Cached result used.
Roles Result:					True (Access Granted).  Blue = Cached result used.  Hover over circle to see Roles required!
Condition Result:				True (Access Granted).  Blue = Cached result used.
Script Result:					True (Access Granted).  Blue = Cached result used.

Type of ACL: “record” Table: “business_unit” Operation: “read” App: “Global” Line 2, starting with the 2nd set of circles:

iAccessHandler:					Clear Circle = Not Evaluated.  Gray Circle = Not Evaluated.
Roles Result:					Check (Access Granted).  Green = Freshly Evaluated.  Hover over circle to see Roles required!
Condition Result:				Check (Access Granted).  Green = Freshly Evaluated.
Script Result:					Check (Access Granted).  Green = Freshly Evaluated.

Type of ACL: “record” Table: “business_unit” Field: “u_mystringone” Operation: “read” App: “Global” - For a user who does NOT have the appropriate role, field “MyStringOne” is omitted from the form and the Security Rule appears as follows:

Line 1, in red:

X mark:						Access denied
Red text:					Access denied

Date and time Access Control was evaluated: 10:46 PM and 51.99 seconds. Time it took to execute Access Control: 0 milliseconds Type of ACL: “record” Table: “business_unit” Field: “u_mystringone” Operation: “read” Context: null - The field won't be displayed, so it is apparently considered to not have a “context”. Return Code (RC): The entire Access Control evaluated to false (Access Denied) Line 2, starting with the 1st set of circles:

iAccessHandler:					Clear Circle = Not Evaluated.  Blue Circle = Cached result used.
Roles Result:					Check (Access Granted).  Blue = Cached result used.  Hover over circle to see Roles required!
Condition Result:				Check (Access Granted).  Blue = Cached result used.
Script Result:					Check (Access Granted).  Blue = Cached result used.

Type of ACL: “record” Table: “business_unit” Operation: “read” App: “Global” Line 2, starting with the 2nd set of circles:

iAccessHandler:					Clear Circle = Not Evaluated.  Gray Circle = Not Cached
Roles Result:					X (Access Denied).  Red = Freshly Evaluated.  Hover over circle to see Roles required!
Condition Result:				Clear Circle = Not Evaluated.  Gray Circle = Not Cached
Script Result:					Clear Circle = Not Evaluated.  Gray Circle = Not Cached

Type of ACL: “record” Table: “business_unit” Field: “u_mystringone” Operation: “read” App: “Global”

- This tool lets you know what related Access Controls exist on a table when you Insert, Update, or Delete another Access Control on the same table. - When Access Controls are created or updated, the Watcher runs to determine if there are other Access Controls acting on the same set of records. Believe this is used to reduce errors in the creation of Access Controls, and help prevent duplicate Access Controls from being created. - The name of the tab shows the type of Access Control you are updating (such as “Read” or “Write”). - The “ACL Execution Plan” is shown. - Color / Term Key

White Background - Related, but unaffected.
Red Highlight - Deleted or Deactivated
Blue Highlight - Modified
Green Highlight - Becoming Active
Masking - Will no longer be "effective" due to the change you are making.  Subordinate to the change you are making.
Unmasking - Will become "effective" due to the change you are making.

- You can click the hyperlinks to go directly to the related Access Controls to review them.

- This information may be out of date. - Takeaway - ServiceNow Agent is a native mobile app which can encapsulate custom-built “Applets” to perform various services. Applet construction is a very structured process where you follow a framework, and build pre-defined components within that framework. There is no HTML to worry about, since the Applet is not run within the context of a browser. This greatly simplifies Applet construction. Applets have Lists and Forms, and may perform database reads and writes, just like Service Platform applications. - Modules:

System Applications - My Company Applications
Studio - Mobile Studio...

- The ServiceNow Agent is a free native mobile application. It is available from the Apple App Store or the Google Play Store. - Allows access to ServiceNow Baseline and Custom Applications. - When the app launches for the first time, the user specifies an Instance to connect to. - Users must login, just like on the Desktop application. - Guided App Creator, and Developer Studio, are ServiceNow's development environments for creating and modifying applications, including mobile apps. - When you create a Mobile App using App Creator, the system automatically creates Applets and Functions for each of the tables in the application. - “Mobile Studio” is just a menu category within Developer Studio. It will only show up if you are currently working on a Mobile application. - Hidden Feature: In Studio, under Mobile Studio, when hovering over certain menu items, there is a Square with an arrow coming out of it, a Popout Icon, which provides access to some additional screens. Data Items is one such menu item that has a Popout icon. - Mobile App Hierarchy - ServiceNow mobile applications are made up of:

1. Applets
2. Applet Launchers
3. Data Items
4. Screens

- The basic flow inside of “ServiceNow Agent” works like this: 1) Launch the “ServiceNow Agent” mobile application on your phone. 2) Tap a “Tab” on the bottom “Navigation Bar” to display an “Applet Launcher” (a page of related Applets). 3) Tap an Applet to open a screen type such as a “Form” or “List”. 4) Possibly enter values in “UI Parameters” which in turn will be passed to “Data Item Parameters”. 5) A “Data Item” (basically a query) gathers data from the database for presentation on the screen. 6) Tap or Swipe to invoke a “Function” such as Navigation or an “Action” such as a record Create, Update, or Delete. - Actions

1. An Action is ONE type of “Function”.
2. Actions encapsulate Action items into buttons.
3. Has a Conditions section which determines when the action is available.
4. Has a Messages section that defines the message a user sees when using the action.
5. Create UI Parameters for Actions that require users to enter values.
6. To allow users to access Actions, place Actions on screens in an Applet.
   1. The screen type determines where an action can be placed.

- Action Item / Write-back Action Item - An “Action Item” defines a database operation allowed on a table's records, such as New, Edit, or Delete. - Action Item Parameter - Allow users to enter values for fields when invoking Action Items. - Specifies Type so that users will have the correct UI Control when adding or editing records in the mobile application. - Applet

1. A small application that runs within another application.
2. Has a fixed template that allows the user to view and interact with data from ServiceNow.
3. Normally address a narrow business need such as “VIP Incidents”.
4. Tapping an Applet opens a form, list, or other screen type.

- Applet Launcher / Landing Page

1. A page of related Applets that a user can access.
2. Activated from an icon (called a tab) at the bottom of the Agent mobile application.
3. Contains a Header, and the Applets the user is authorized to use.
4. Baseline Applets Launchers include:
   1. Incidents
   2. My Approvals
5. The Applet Launchers available depend on which Mobile Plugins are installed on an instance.
6. Section:
   1. Arranges applets and record information into logical groupings.
   2. Can have a horizontal or vertical orientation.
   3. Can display a Record or an Applet name.
   4. Divided by a line.

- Creating a Custom Mobile Application - To allow access to all users, select the Public role. - Data Item

1. A Filtered Set of data from a table. Like a query.
2. Data Items and Data Item Parameters determine which records are available in an Applet.
3. Can use Data Item Parameters to dynamically determine which records to send to an Applet.
4. Condition Type:

Declarative - Build the filter using the Condition Builder.

	Scripted - Write a server-side script to filter the table records.
	Instance Relative URL - Use a ServiceNow URL to define the table record filter.

- Data Item Parameters

1. Allow a User to pass values to a Data Item so records may be filtered BEFORE the Data Item retrieves the records for the client.
2. Parameters are used in the Data Item “Condition” field.
3. UI Parameters are mapped to Data Item Parameters.

- Function / Mobile Application Function

1. Defines UI elements that determine the things a user can do in a mobile application.
2. Determines how a user navigates through an App.
3. Allows a user to take an Action on a record. (Allows a user to access an Action)
4. Types:
   1. Actions - Change Data, such as modifying a field value.
   2. Navigation - Move between screens, such as opening a record from a list.
   3. Smart Buttons - Allow users to take action on demand, such as making a telephone call.
5. Invocation
   1. Users access a function by:
      1. Tapping a Top Menu
      2. Swiping
      3. Tapping a Field
      4. Tapping a Footer option.

- Mobile Application

1. A custom Application that runs within the Service Now Agent application, and is made up of Applets, logically grouped into Applet Launchers.

- Navigation Bar

1. The pane at the bottom of the App.
2. Each button on this bar is called a “Tab”.
3. Appears at the bottom of every mobile application screen.
4. Used to navigate to the following items:
   1. Applets
   2. Notifications
   3. Settings
5. To add a tab to the Navigation Bar in the ServiceNow Agent mobile application, go to Studio - Mobile Studio - Application Menu - Mobile Agent
   1. Since the Mobile Agent record is a part of the Global scope, ignore any warning messages about changing scope.

- Quirks - When a new app is created, users must log out and then back into the ServiceNow Agent mobile app to see the new app show up. - You may sometimes have to Swipe Down to refresh a list to see newly added records appear. - Hidden Feature: Swiping Right on a record may reveal a Delete button. - Layout

1. Determines the appearance and placement of fields on the screen.
2. Specifies which fields to display, and in which order.
3. Composed of numbered “Elements”.
4. A selectable “Pattern” provides a predefined template specifying which element numbers will go where, on the screen.
5. Table Fields are mapped to elements in the screen layout.
6. Not all data types can be mapped to every List Element. You can't map an image field to a text field, for example.

- Segment

1. A Tab-Like sub-menu on a Form screen.

- Screen Types

1. Calendar
2. Employee Directory
3. Form
   1. Opens when a user taps a record on a List screen.
   2. Composed of two parts, “Overall Settings” and “Body”.
4. Group List
5. List

A List Screen displays a list of records passed to an applet by a Data Item.

1. Map
2. URL

- UI Parameters

1. Allow applet users to set parameter values for Actions.
2. May be mapped to a Data Item parameter or an Action Item parameter.

- UI Policies / Screen UI Policies (?)

1. Control whether mobile fields are Mandatory or Visible.

—–

- Modules:

Project Administration - 'Properties - Agile'
Agile Development - *

- Unified Backlog - Allows a scrum_product_owner to add any task types (Change, Defect, Incident, Problem) to their backlog or sprints.

1. This is done using a “Triage Board”.
2. The Unified Backlog plugin adds 3 tables: original_task, backlog_definition, and agile_story
3. A product owner can choose which task types will show up on his backlog.

- Agile Development 2.0 Plugin

1. There is a guided setup wizard. Products, Releases, Scrum teams.

- Considered a part of ITBM/SPM - ATF Plugin

1. Provides Test Cases (Quick Start Tests) and Test Suites that can be run against the Agile 2.0 Plugin.
   1. Ensures that the application still works after you make configuration changes.
   2. Execute Test Cases whenever you do an upgrade.

- Sprint - A single development cycle with adjustable scope. Using sprints helps the team address rapidly changing development needs. - Common Roles

1. Product Owner
2. Scrum Master
3. Group Member

- Supports two different types of development: - Product-Based

1. A Product is defined as a set of features or functionality offered to users.
2. Has a product owner.
3. Product could be a component of a larger product.
4. Agile development takes place indefinitely during the product lifespan.
5. Long-term approach.
6. Features and Functions are defined as Stories that clearly define the user, his goal, and the reason for the goal.
7. Stories go into a Product Backlog which is prioritized by the product owner.
8. High priority stories may be selected and moved into a Release Backlog, organized into Themes and Epics.
9. The agile development team tackles the Release Backlog implementation and testing, in sprints.

- Project-Based

1. Led by a project manager.
2. Has a clearly defined end-date
3. Here, agile development methods are incorporated within a traditional waterfall project structure.
4. The financial side of many companies is structured to fund development efforts as discrete projects.
   1. Method 1 - “Project First”
      1. You use the Demand Management Process (Idea → Demand → Project) to create and fund a project.
      2. You execute the project using a mix of traditional project tasks, and agile stories and sprints.
   2. Method 2 - “Stories First”

- You collect stories (via enhancement requests) in a backlog over time. Multiple stories might be collected together into an Agile Theme. When there are enough stories, you create a project and use the Demand Management Process for funding and implementation. - Backlogs

1. Personal Backlog - A backlog managed by a Product Owner.
2. Sprint Backlog - A list of stories the group has agreed to complete for a Sprint.

- Retrospective - A review meeting, conducted at the end of a sprint, which allows group members to discuss what went well and what did not. - Sprint Planning - The exercise where the scrum master moves stories from a Personal Backlog into the current Sprint. Also, the team members help select the stories they can commit to in the Sprint. - Daily Scrum - A meeting in which the group members including the Scrum Master meet to discuss progress, planned work, and any impediments (blockers). - Sprint Review - A meeting where the Scrum Master and Group Member demonstrate new features to the Product Owner. - Scrum Artifacts - Velocity Chart - A chart displaying the historical performance of a group; used to estimate the amount of work the group can deliver in a future sprint. - Burndown Chart - A chart created during a sprint that provides an at-a-glance report of ideal sprint progress against actual progress. - Scrum Units of Work

1. Theme - The highest level of the requirements hierarchy. Describes a view of either a tangible product, or an abstract goal.
   1. Epic - A group of User Stories that together provide an increment of value to the business, such as a new feature or significant enhancement.
      1. Story - A brief statement of a product requirement or business case. Expressed in plain language. Often created by a product owner.
         1. Task - A discrete piece of work required to complete a story.

—–

- ServiceNow is phasing out its dependency on Angular, and all third party APIs which are not true Web Standards. Do not learn Angular. - Takeaway - A JavaScript library (framework) for web applications that allows you to use directives in elements, attributes, or CSS classes, to extend the functionality of HTML. All built-in angular directives start with the letters ng. Events are used with a publish-and-subscribe pattern such that client-side widgets/modules may communicate with each other. A model-view-controller © pattern is also used. The view is data-bound to the data model, such that any changes made in either layer are immediately reflected in the other layer. Modules

Service Portal - Angular Providers
Service Portal - Widgets

Docs https://docs.angularjs.org/guide/introduction - A structural framework for dynamic web apps. - Allows user-defined directives to extend the functionality of HTML in applications (using “Angle brackets < >, and thus the term Angular). - Any stable AngularJS library may be used with ServiceNow, including angular.min.js. - Styling - ServiceNow provides default styling for AngularJS applications called “Heisenberg” styling. The style guide is not publicly available. - If you want to use “Bootstrap”, it must be explicitly included in your UI page:

	Bootstrap CDN Site 
	<link href="https://stackpath.bootstrapcdn.com/bootstrap/4.3.1/css/bootstrap.min.css" rel="stylesheet" 

integrity=“sha384-ggOyR0iXCbMQv3Xipma34MD+dH/1fQ784/j6cY/iJTQUOhcWr7x9JvoRxT2MZw1T” crossorigin=“anonymous”></link> - To avoid caching issues when developing web applications:

1. Use a private/incognito browser window.
2. Force a reload of the page.
3. Clear the browser cache.

- A simple Angular JS application in ServiceNow consists of two application file types:

1. UI Pages containing the application's HTML.
2. UI Scripts containing the application's client-side logic. Table sys_ui_script.

- Directives

1. A Directive is an Extended HTML attribute.
2. All built-in Angular JS directives start with “ng”, which stands for “aNGular”.
3. Directive names are camelCase, but in HTML you must use all lowercase, with hyphens before all letters that were previously uppercase.
4. Creating Custom Directives
5. A Directive can appear in any of the following object types:
   1. Element
   2. Attribute
   3. CSS Class
   4. Comment
6. Common Angular Directives:
   1. ngApp
   2. ngRepeat
   3. ngShow
   4. ngModel
   5. ngClick

- Events - Uses a Publish and Subscribe strategy for handling events. - Events are useful for notifying widgets about things happening in other widgets. - Example events:

1. Record selected
2. Changed value
3. Data deleted
4. Data added
5. $emit() - Send an event up the scope hierarchy.
6. $on() - Listen for events of a given type.
7. $rootScope - Used to emit and listen for events. Contains all widget scopes.

- Model / View

1. In Angular JS applications, the View and Model are data bound.
   1. Changes to the View (the UI Page / DOM) update the Model
   2. Changes to the Model update the View
   3. Updates are continuous and dynamic

- Providers / Angular Providers

1. These correspond to Angular Directives.
2. Believe these contain the implementation for the corresponding Angular Directives.
3. After an Angular Provider has been defined/implemented, it may be added to a Widget via the “Angular Providers” related list.
4. For performance reasons, Widgets load only those Providers they utilize.

- UI Pages

1. Used to create a custom page for an application. Used similarly to how an index.html page would be used, outside of ServiceNow.
2. Note, UI Pages are implemented with a technology called “Jelly”, and ServiceNow is moving away from Jelly.
   1. UI Pages may need to be re-written as Service Portal Widgets.
3. Jelly
   1. Every UI Page is a “Jelly” template. Jelly turns XML into executable code.
   2. The Angular JS logic is contained within the <j:jelly> tags in the page's HTML element.

https://docs.servicenow.com/bundle/orlando-application-development/page/script/general-scripting/reference/r_JellyTags.html https://docs.servicenow.com/bundle/orlando-application-development/page/script/general-scripting/concept/c_ExtensionsToJellySyntax.html

1. A UI page is accessed in a browser with the Instance URL followed by the UI Page Endpoint.

- Direct Option

1. This checkbox does the following:

- Disables Heisenberg styling. - Removes access to ServiceNow's client-side APIs such as GlideForm (g_form) and GlideUser (g_user). - Removes all boilerplate ServiceNow HTML, including JavaScript and CSS includes.

1. When the Direct option is specified, developers must supply all styling and application logic.

- UI Script

1. Works similarly to an app.js file. Holds JavaScript.
2. For AngularJS applications, UI Scripts (in table sys_ui_script) typically contain module definitions.

- You can use the Script field directly on a UI Page, or you can include a separate Script file, which may be more modular. To include a separate script file, create a UI Script Application File, and then reference it in your UI page by appending ”.jsdbx“. This tells ServiceNow that the file is stored in the database. Example: <script src=“x_461867_angular_a.angular_app_client_lo.jsdbx”></script> - For stand-alone UI Scripts, the Script field is automatically populated with a template in new UI Scripts, but is not applicable to AngularJS UI Scripts, so delete it. When you do this, and you save the Script for the first time, you will see a warning message, which you may safely ignore. - Widget Client Scripts create the Widget's Controller, “c”.

- Takeaway GlideForm and GlideList are client-side APIs. GlideSystem and GlideRecord are server-side APIs. The g underscore (g_xx) objects are all client-side only. The gs object is server-side only. There are GlideUser and GlideRecord APIs for both the client and server, but GlideRecord is used mainly on the server side; if used on the client-side, AJAX is utilized so method calls could be slow. The client-side onChange() variables named “oldValue” and “newValue” should not be confused with the server-side business rule parameters “previous” and “current”. - Client - On the client side, the main API Classes and associated, automatically-instantiated, global object are as follows:

Class		Global Object

GlideForm g_form GlideList g_list GlideUser g_user - Methods from these APIs are guaranteed to work in Client Scripts (and UI Policy Scripts), and MAY work in Client Catalog Scripts (via both the Platform and the Portal) but must be tested first. - g_form - Very important methods on the g_form object include addErrorMessage(), addInfoMessage(), getValue(), and setValue(). - g_user - Provides info on the current user and his roles, and this info is obtained quickly, directly from the user session, not from the server. - There IS also a GlideRecord API on the client side, for the Global scope only, but it relies on AJAX calls to the server, and should be used sparingly. Also, I do not believe that it works in the Service Portal. Platform UI only. - Server

1. GlideQuery is new server side api to use in a ‘global script include’ used to find errors with ‘NiceError’

New GlideQuery(‘sys_user’) .where(‘department.name, ‘IT’) .where(‘role’, ‘admin’) .limit(100) .select(‘user_name’, ‘phone’, ‘user_id’, ‘email’) forEach(function(u) {

  gs.info(u.user_name + ‘, ‘ + u.phone + ‘, ‘ + u.user_id’ ,  ‘ + u.email);

});

- On the server side, the main APIs Classes and automatically instantiated global object are:

Class			Global Object	- or -	Local Variable Instantiation

GlideSystem gs GlideDateTime var glideDateTime = new GlideDateTime(producer.date_field); GlideRecord var grUser = new GlideRecordSecure('sys_user'); GlideElement GlideUser gs.getUser(); - There are no g_xx objects (except for g_scratchpad), and the only major API object which is global and automatically instantiated is gs. GlideSystem (gs) is used for general system interaction, and for information about the currently logged in user. Of course, gs includes the logError() and addErrorMessage() methods. (addErrorMessage() is confusing at first because it is a server-side method, but pushes its result up to the client.) - The retrieved fields of a GlideRecord query are of type GlideElement. - The GlideUser object provides info about Any user and is faster than using generic GlideRecord queries. Info about the current user is best obtained via gs.getUser() whereas information about any other user may be obtained after a call to getUserByID(). - GlideRecord - The server side GlideRecord API is used for database operations on a single table. - getValue() and getDisplayValue() may be used to retrieve a single field value instead of an entire record. - get() may be used to retrieve matching records from the database with a single line of code. - query() runs a query against the table based on filters already specified via methods such as addQuery() or addEncodedQuery(), and it requires an explicit call to next() to move to the next record in the GlideRecord object.

1. To insert a new record into a table, call initialize() or newRecord(), then set your values, then call insert().

- previous object - Another GlideRecord object which, in some business rules, gives the values of all fields as they were when the record was initially loaded from the database, and before any changes were made in the UI on the client. - current object

1. A server-side object of type GlideRecord, which is passed in as an explicit argument to business rules in the “executeRule()” function.

- “current” is available for Business Rules and Workflows

- Guided App Creator and Studio are ServiceNow’s development environments for creating and modifying applications. - Most ServiceNow client companies DO end up building at least some custom ServiceNow applications. - If a customer feature is going to involve Multiple Tables and Integrations, it may be a good idea to create an entirely new Application with its own Scope.

/ Global Search / Code Search / Text Index / Token Search / Keyword Search / Text Search / Script Search / All Scripts) https://docs.servicenow.com/bundle/sandiego-application-development/page/build/applications/concept/c_ApplicationFiles.html - Tables

sys_metadata

- To get to the Application Files table, type sys_metadata.list into filter navigator. - The Application File table provides a series of standard fields that define the attributes for a configuration record. - It is the parent table for all tables that contain configuration records. For example, the Business Rule [sys_script] table extends the Application File table. - Important! You can do a search “for text” in the Application File table to find log messages or code snippets. Do this in the search box that appears ABOVE the List View. You can use Double Quotes around your search string to find text exactly as you have typed it. - The system tracks application file records in Update Sets. Whenever you change an application file record or its related configuration record, the system adds a corresponding record in the Customer Updates [sys_update_xml] table.

- A place for a company to share its completed, “published” applications, which are ready for distribution between its instances. - From there, Apps may be easily installed on other instances such as Test or Prod. - Makes it easy to Install, Uninstall, or Update an App.

1. Note that the “glide.appcreator.company.code” value must be the same on all instances.

- The Application Repository is available to instances owned by the customer.

1. “Public” is the Store. It's a repository in HI.
2. “Private” is your own Organization.

- Personal Developer Instances cannot publish to the ServiceNow Application Repository. - ServiceNow customers have their own namespaces in the repository that are invisible to everyone else and can only be used within that specific company. - Believe the Repository is accessed via Studio, but not sure.

Modules: System Definition - Application Menus - In SN, an “Application Menu” is just a collection of related modules. It's just a category in the application navigator that can be individually collapsed. - Order Determines the on-screen placement sequence in the Filter Navigator. Items with the same order value are displayed alphabetically. - Quirks: - If NO roles are assigned to an Application Menu, then ALL roles will actually have access. - How many Application Menus can there be for an application? - As many as you want. You can define multiple applications in the sys_app_application table. Each such application may have one or more modules, and each of those modules may display data from a particular table. Two or more modules may both point to the same table, and thus two or more applications (application menus) may be created for the same logical application.

/ Application Property / Application Parameters / System Property / System Properties * - Takeaway Application Properties are just variables used within an application, such as in scripts. Application properties, also called System Properties, are created in Studio, and are typically accessed via a Category and a Module. By convention the module is named Properties and it resides in a menu section called Administration. When set to “Private”, Application Properties are automatically excluded from Update Sets, and this is useful for setting those properties which are instance-specific. Typically, only the System Administrator role is setup to be able to edit Application Properties. - Modules Table: sys_properties

[Custom Application Name] - Administration - Properties
Studio - Create Application File - System Property Category
Studio - Create Application File - System Property
Studio - Create Application File - Module

- An Application Property is a configurable variable, which can be used to change how an Application behaves. - Usually only System Administrators or Application Administrators can read or write Application Properties. - Using Properties instead of hard-coded values allows an Application's behavior to change without the need for a code change or reinstallation. - Application Properties can be retrieved, and used in Scripts. - By convention, properties normally reside in under an “Administration” menu and a “Properties” module - By convention, a “Properties” module should appear at the END of an Application menu, so give it a high Order value. - Creating a System Property Category creates the page layout for an Application's Properties. - Private - The “Private” Application Property attribute excludes the Property from Update Sets. This prevents a Property from being moved between instances. This is useful when a Property value needs to be kept different on Production, Test, and Development instances. - Note, a System Administrator can set property values (via sys_properties.LIST) without using the Properties module that you create, but creating a module allows related properties to be managed in a single place. - Usage:

1. The Scoped GlideSystem getProperty() method is used to retrieve an Application Property value in script. Example:

var daysNotice = gs.getProperty(“x_snc_employee_spe.daysNotice”, 10);

1. The optional 2nd parameter specifies a value to use if the Application Property has No value at all.

- In Script Includes, the “initialize” function should be used to retrieve Application Properties. This makes them available to all Script Include functions. This is a “retrieve once, use many” pattern. - Steps for creating in Studio: 1) Create a System Property Category 2) Create System Properties, and give each a data type, and specify which roles may read and write to them; typically, the <Application>_admin role. 3) Associate the System Properties you created with the System Property Category, using the Related List. 4) Create a new Module for the Application's System Properties and associate it with the Application's (existing) Menu. Assign Read Roles.

1. Set the Link Type to be “URL (from arguments)
2. Set the Arguments to be something like:

system_properties_ui.do?sysparm_title=Loaner Request Properties&sysparm_category=Loaner Request This says “Open the generic system_properties_ui” page and show a title of “Loaner Request Properties”. Include all the properties with a category of “Loaner Request”. - Misc

1. glide.ui.response_time is one useful property in this table:

https://docs.servicenow.com/bundle/rome-platform-user-interface/page/use/common-ui-elements/concept/c_ResponseTimeIndicator.html —–

- See separate document “ServiceNow_Knowledge_APM.docx”. - Also called ITBM

- Modules

System Properties - Approval Engines

- The differences in the way that companies handle their approvals, as well as the differences between approvals for the various applications (such as Service Catalog Requests and Change Management), calls for supporting flexibility in setting up approvals within applications. This flexibility is provided through the selection of an approval engine that is used to manage the approvals for each of the tables that extend the Task table. Alternatively, approvals may be explicitly generated via a Flow. - Engines Approval Rules A simple set of rules that are evaluated until one matches for the Task table. The matching approval rule is used to create the users that are to approve the task. Set up approval rules by navigating to System Policy > Approvals.

Process Guides

This option is deprecated and should not be used!

	A sequence of approval steps over which you may control how approvals and rejections are handled.

- Turn off Engines

Turn off both approval engines for this Task table. 

This option should be selected and is made read-only when a Workflow is used to manage the approval process for the table.

Archiving - Archive rules may be found under Archive - Archive Rules. These are the conditions under which records are moved out of the main tables and into archive tables! - Archived Users may be found under Archive - Archive Users (ar_sys_user table)! - This archiving process is how users may seem to “disappear” from one of the main tables, with no record of deletion in the logs!

- Important: See Tables Involved and spreadsheet “SurveyTablesAndModules”. - When to use each?

1. Assessments
   1. To collected detailed insights, and evaluate the results.
   2. Requires an “Assessable” Record.

- You can create a single assessment that pulls feedback from multiple functional units, by assigning different parts of the assessment to different stakeholders. - Useful for gathering detailed feedback across multiple records.

1. Surveys
   1. To get User Feedback about the Output of a process.

- To query about the perceptions of those being surveyed. - Surveys do not look at much detail of what is happening within the process. - Example: When an incident is closed, the Service Desk manager gathers feedback on user satisfaction with the service received.

- Signature - A signature on an assessment questionnaire contains assertions that can communicate directions, a legal statement, or any text that you want the recipient to consider. You can require the recipient to select a check box or provide a full signature to acknowledge acceptance of the assertion before submitting the form. You can display assertions without requiring a signature. An assessment property called Require authentication for user signature allows you to require users to provide their username and password when an assessment asks for a full name signature.

- General Process

1. Decide which sets of records in the system to assess.
2. Decide which “Themes” you are interested in.
3. Decide which “Traits” to measure.
4. If Questionnaires will be utilized, decide which people in the organization will be able to answer it.

- Assessments, Surveys, and Quizzes all run on the same underlying technology, and so they have many features in common. The Design - Assign - View process is the same for Assessments, Surveys, and Quizzes.

- Metric - A particular Question / Variable in an Assessment or Survey. - A trait or value used to evaluate assessable records. A metric can measure subjective values in an assessment questionnaire, or gather objective values in a database query run by a script. Examples of metrics include courtesy of sales representatives or number of incidents per vendor.

- Category - Metric Category

1. Contains one or more individual metrics.
2. Examples
   1. Overall Vendor Performance
   2. Quality of Delivery Services

- A metric category represents a theme for evaluating assessable records. Categories contain one or more individual metrics, which define specific traits or values that comprise the theme. You can set filter conditions that control which assessable records to evaluate for the metrics in a category.

1. Category User
   1. A person who knows about a specific category.
   2. Examples
      1. Vendor Manager
      2. Supervisor of Sales Team
2. Stakeholder
   1. A Category User with knowledge about a specific Assessable record.

- Metric Type

1. A Survey or Assessment.
2. Defines a set of records to evaluate, such as Vendors, Projects, or Employees.
3. Example
   1. Major Incident Managers
4. Geoff: I guess that a particular Metric could be applied to multiple, even unrelated, Metric Types.

- Assessable Record

1. A record which links a Source record you want to evaluate, with a Metric Type (Survey or Assessment).

- You define sets of assessable records when you create metric types.

1. Metric Types / Categories
   1. Examples
      1. Vendor
      2. Employee

- For Each Assessment, the system generates unique assessable records that link it to records that need to be evaluated, such as the individual records for the vendors Amazon and Intel. There may be multiple assessable records for the same source record if the source record meets the criteria for more than one Assessment. For example, you might want to evaluate a record on the Company table, such as Intel, as a vendor and as a manufacturer, with different categories and metrics.

- Assessment Instance

1. One Assessment Questionnaire, assigned to One user.
2. Generated On-Demand, or when an assessment Scheduled Job runs.

- Scorecard

1. Seems to be a built-in graphical widget which shows the results of an Assessment.
2. A visual illustration of an Assessable Record's performance, based on assessment results.
3. May be compared to the ratings of other Assessable Records.

- Decision Matrix

1. A graph with two axes that plots the assessment results for multiple assessable records.
2. May be used to determine the relative standing of assessable records in selected categories.

- Scaled Result

1. A target mapping from an actual value. May or may not be a linear mapping.
2. Makes more sense in the context of Scripted Assessments.
3. Example

Actual Value in Database Record Scaled Result

	< 0					0	
	0 - 20					1
	21 - 50					2
	51 - 100				3

- Assessments Assessments - Product Documentation

1. Used to Evaluate, Score, and Rank records from any table.
2. Within Assessments, questionnaires may be sent to users, or scripts may be used to generate results directly.
3. Scripted Assessments only work on the data types Duration, Number, and Percentage.
4. An Assessment questionnaire looks similar to a Survey, but there is a lot more happening behind the scenes with an Assessment.

- Assessments is a core application on the ServiceNow platform. - Allow you to evaluate, score, and rank items from any table, and provide weighted results. - Examples - Projects may be assessed for effective management. - Vendors' goods and services may be assessed, for example on metrics of Dependability, Price, and Selection. - You can send Assessment questionnaires to selected users, or write scripts that query the database directly. - Let you evaluate, Score, and Rank items from any table. - Lets you provide (in graphical form) weighted, normalized, results. - You select some metrics, and you evaluate those metrics across multiple instance records. - Scorecards are used, apparently. - The assessment application goes deeper than surveys, and has advanced capabilities. - An Assessment allows you to evaluate, score, and rank items, and provides normalized/weighted results. - For an assessment to work, it needs to have an “assessable record”, which is Not the case with surveys. - Common use cases for assessments include:

1. Vendor, Demand, Project, GRC Audit, Security, Employee.

- Assessments are good for deep, insightful feedback to evaluate, rank, and see a normalized score of multiple records together, so that you can make quick decisions.

1. Live Feed Groups

???

1. Scale Factor

???

- Surveys

1. Roles:

Survey Admin

1. Schedule Period
   1. Determines how often a Survey Instance is generated for each user. This is done using a scheduled job.
   2. If you are using Trigger Conditions, rather than a schedule, to generate Survey Instances, set the Schedule Period to “No Limit”.

- Surveys are good for collecting customer satisfaction data or feedback on a Task activity, such as when a request is closed. - Public Surveys may also be created, for users without a ServiceNow account. - Surveys are ideal for simple use cases like getting feedback. - You drag question types onto the designer and then edit content. - Surveys may be scheduled, or attached to trigger conditions, such as when a Request is closed.

1. The trigger condition defines the User table field which will be used to decide who to send the Survey to.

- Publishing a survey makes it available via a specific URL. - The Assessment Properties page has a setting which allows surveys to be filled out on the Service Portal rather than the Platform UI. - Availability

1. Limits those who can be Assigned to the Survey.
2. Categories
   1. Anyone (Public)
      1. URL may simply be copied and pasted into emails, or posted to a web page.
   2. Specific Users
   3. Specific Groups

- Assignment

1. For “Triggered Surveys”, they are assigned when they are generated, at the time of the trigger.
2. For “General Surveys”…
   1. Manually
   2. Scheduled
      1. Can provide a “Net Promoter Score”. (Promoters are those who rate something highly, such as 9 or 10 out of 10)

- Results

Methods
	1) Survey - Overview.  One way to review survey results.
		- Displays a variety of Reports from several surveys.
		- Widgets may be changed and rearranged.
	2) Individual Survey
		- Displays Response Trend and Summary chart by default.
		- View Scorecard shows results at the question level.

- Buttons:

1. Assign Survey

- Creates an instance of the survey for ONE arbitrary user. Sends the user an email with a link to the survey. - Send Invitations - Custom UI Action? Creates an instance of the survey for those users already on the “Survey Users” list or on the “Survey Recipients” list. Sends each user an email with a link to the survey. - Email - Custom UI Action? Allows you to send an arbitrary email, with a Survey link to any number of users, and also include users on CC and BCC lines. Does not create any survey instances up front. - Survey Pitfalls - If you don't see some of the questions you recently added for a survey, it may be because they are on the next “Page”. Double check if the button at the bottom of the Survey page says “Submit” or “Next”! - If you make changes to a Survey, but you are not Seeing the changes when you go to Take the survey, it may be because the system is showing you an existing Instance of a survey that was created for your user account, previously. Until you complete this survey or remove your name from it, the system will not generate a fresh survey instance for you. Article Here - When there are multiple instances of a survey queued up for a particular user, the survey link will take the user to the oldest survey that is waiting. This happens even if the survey questions have changed; that is, there are multiple versions of the survey. - When you go through the Survey object to design your questions, depending on the View you are in, some important field may be missing. For example, on the Survey view, for the Reference question type, the Reference Table does not show up! You should see all the correct fields however, through the Survey Designer. - Quizzes - Quizzes are Questionnaires that may be assigned to users to assess their knowledge of any subject. - If a user follows a survey link, and there is not an Instance already waiting for the user, one will be created on the fly. - When a Survey Invitation is sent via a Trigger Condition, the “Introduction” page seems to automatically include a reference to the triggering record, such as: “Survey is in reference to INC2651274 General Issues - Markets: Desktop/Laptop for California

SURVEY OPTIONS FOR VICTOR MACK - Have the user Select the Major Incident Manager as one of the questions.

- Option 1. Use a Triggered Survey (which generates specific survey Instances, and specific survey instance URLs, right up-front)

1. Features
   1. The idea behind a Triggered Survey is that:

1) The survey is tied to a specific instance data record.

		2) The users that will actually take the survey are pulled from a user field or "watch list" field of that specific instance data 

record, and are identified right “up front” before survey invitations are sent out. - The Trigger level “Table” and “User Field” determine what ServiceNow known users receive the Survey.

		3) The survey is "Triggered" by a state change in the instance data record. 

4) When the survey is Triggered, a Survey Instance is pre-created for each user identified in the Instance Data record. Those users are specifically invited to take the survey, and Only those users may do so.

1. Triggered Surveys discussed here in the 2nd bullet point.
2. Pros
3. The Trigger is straight-forward, and maintained in the same place as the Survey itself and the Survey questions.

- When a Survey Invitation is sent via a Trigger Condition, the “Introduction” page seems to automatically include a reference to the triggering record, such as: “Survey is in reference to INC2651274 General Issues - Markets: Desktop/Laptop for California”. - You can pull in (store) up to 4 Related Records when the survey is triggered, for reporting purposes. The terminology is confusing, but these records that you reference are called “Related Fields” (the should be called Related Records), and are discussed here under “Related Field 1-4”.

1. “To view the fields, configure the form for any survey instance”. ??? Not clear on what this means.
2. Cons

- I don't believe you can HARD CODE a list of users. You have to reference a list of users via the instance record that is triggering the survey, or a related record you can dot walk to. For example, you may choose any single User field such as Caller, or any Multi-User field such as Watch List. The Trigger User field is discussed here. - Populating a watch list field with an arbitrary email address (distribution list email address) does NOT work in this case. ServiceNow simply skips over the arbitrary email addresses and does not generate surveys or survey invitations for those entries. - The Question Level “Source Field” lets you populate Question Text with a variable from the “Source Table” defined at the Survey level. - The RESULTS of the survey will still not be parsed by this value, however. Don't believe that this value is actually stored anywhere. It is rendered in the survey as part of the Question text, but is not stored anywhere as Answer information and cannot be reported on.

1. Victor Requirements

- Believe the MI Manager could be a “Related Field” (1-4), but a little unclear on how to setup the reporting, or how satisfactory it would be. - In order to reference a hard-coded list of users, we might have to create a bogus watch list field on the target record type, and give it a default value, or populate it via a business rule. :\ - Even if you create a fake “User” with an email address of the distribution list, when the survey is sent out to that email address, the users will not be able to actually log in and take the survey. They will not be able to authenticate. ServiceNow apparently cross-references the logged in user with the email address the survey was sent to.

Example Link:  https://[YourInstanceName].service-now.com/sp?id=public_survey&instance_id=a59f9552db066850b21ede46d49619b5 
			- Believe we would need to Maintain a separate list of users in ServiceNow.  Dual Maintenance.

- But even if we had this list, I believe we would need to Somehow expand the list to get each of the individual members into a Watch List field.

- Option 2. Use a General Survey (which is available to any user who has the link) - Features - Survey Instances are not generated up-front. They are generated on-the-fly when the link is followed. - Invitations are Manually triggered, or triggered by notification / script / schedule.

1. Survey - Assign Survey button or Survey - Send Invitations button or Survey - Email button (custom UI action?)
2. Pros
3. Cons
   1. Survey could theoretically be forwarded to someone we really don't want to take it.
   2. The survey can be started with an Email Notification, but variables pulled into that Email will NOT be fed into the Survey.
   3. The survey will not indicate any variables automatically such as the Major Incident Manager.
4. Victor Requirements

- We could ASK the user who the MIM was using a question. The maintenance on this, if the MIM's change, would not be very great. - Also, we can't pull in other data fields for the survey itself. But we can put other data fields in the invitation Emails.

- Option 3. Use one general survey per MIM. - Pros - Would also simplify the reporting because there will be one less “dimension” involved (user). - No hidden fields and no need to maintain any user list in ServiceNow. - Cons - Duplicate Maintenance. But honestly not that difficult to maintain.

- Tables

Sys Audit / sys_audit
	- Tracks activity in tables that are flagged for auditing, including for journal fields and history sets.

- Where the system stores historical information for all records. - These records are intended to be kept forever so that administrators can always track the history of audited records. As the number of auditing records grows over time, it becomes more inefficient to directly query the Audit table for historical information. It is much more efficient to run queries only on the smaller subset records you actually want to view historical information for. Audit Relationship Change / sys_audit_relation Tracks relationship changes between sys_audit table and the source tables that the audited records originated from. It also tracks when a record might have been deleted. sys_history_set

Identifies which particular records from an audited table have historical information.

The system automatically generates History Set and History records as needed from the Audit table when a user either creates a record or requests its history. The system limits History Set and History records by: Having the table cleaner delete History Set records that have not been updated in 30 days. Using table rotation to rotate between 4 History tables every seven days. The system drops History records that are older than 28 days. After the system generates History Set records, the context menu choice History uses the History Set rather than Audit records. From the user's perspective, the same historical data is available in the same user interface, but the way the information is stored is different. History / [sys_history_line] Stores the actual changes to field values that occurred. The system automatically generates History Set and History records as needed from the Audit table when a user either creates a record or requests its history. - The tracking of changes to records. - By default, the system tracks changes to the incident, change, and problem tables, among others. - You can hide fields you do not want to track using a dictionary attribute. - Tables do not derive the audit flags from parent tables. For example, if you enable auditing for the Configuration Items [cmdb_ci] table, only CIs stored in that base table are audited. - Whenever you audit any record in a table, a relationship is created between the various originating tables to the store that records data. This relationship information is saved in the sys_history_set, sys_history_line, and sys_journal tables.

Automated Test Framework * (ATF *) - See Separate Document “ServiceNow_Knowledge_ATF”.

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

- 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.

——

- 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.

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

——