Key Concept - Server - 'Set Redirect URL' Function - Use the Debug Now UI Action to debug scripts from table sysauto_script (“Scheduled Script Executions”) with syntax highlighting and breakpoint capabilities. - Use action.setRedirectURL(current) in a UI Action, to keep the user on the very same web page after any UI action is executed.

Name -Debug Now Table -Scheduled Script Execution [sysauto_script] checked; active, show insert, show update, Form button« Comments -Runs a scheduled script execution script in the current session so that it can be debugged using the script debugger, and also so that messages pushed up to the client may be displayed

Hint -To hit breakpoints, be sure to launch the Script Debugger BEFORE clicking this Debug Now button

Condition 'gs.hasRole(admin)

Script

try{ 
     var evaluator = new GlideScopedEvaluator();
     evaluator.evaluateScript(current, 'script');
     action.setRedirectURL(current);
}
catch(e){
     gs.addInfoMessage(e);
}

- Modules

System Definition - Tables - [My Table] - Edit Table - Related List "Database Indexes (x)"
System Definition - Tables & Columns - Related List: Database Indexes

https://docs.servicenow.com/en-US/bundle/sandiego-platform-administration/page/administer/table-administration/task/t_CreateCustomIndex.html Index Suggestions for Slow Queries - To find the table in the list of Table Names on the left, type in the LABEL of the table, not the name. For example to find task_ci type in “CIs Affected”. - You can find Indexes on the “Database Indexes” related list on the Base table sys_db_object record.

1. Ex: Task table in Dev instance has 62 indexes.

Deactivating / Decommissioning / Retiring Objects To decommission a ServiceNow object, such as a Group, without breaking anything, search for the object two ways, as follows: 1) Use the Global Search function to search all standard objects for the TEXT of the group name in double quotes. 2) Use the Global Search function to search all standard objects for the sys_id of the group. 3) Use the “Find All Record References” UI Action to search all tables for the sys_id of each object. For each item found, manually open it and consider if it seems important or not. If it's just an entry in a log or history table, the reference can most likely be ignored.

- Takeaway A dashboard is a tabbed collection of Data Visualization Widgets, such as Reports. Any user can share a Dashboard with others. Dashboard Widgets may be easily configured, resized, and re-ordered. - Modules: Self-Service - Dashboards Performance Analytics - System - Dashboard Administration Table: pa_dashboards - Roles: pa_admin pa_power_user - Documents: csc-quick-answer-creating-custom-dashboards.pdf - A Dashboard is a canvas of Data Visualizations, organized by Tabs and drag-and-drop Widgets. - Allows users to share “Widgets” (including reports) that reflect live data. - A good dashboard presents select information (metrics) to specific users to inform their work and show trends. - The Self Service - Dashboards module shows all the dashboards you have access to. The last dashboard you viewed is the one that is displayed. - Any user can share a Dashboard with other Users and Groups. - If you are viewing a Dashboard, the dropdown at the top left allows you to switch to other dashboards. - Under User Settings, a dashboard may be set as the user's ServiceNow landing page. - Dashboards are superior to Home Pages, and are replacing them. - An older version of “Responsive Dashboards” was just called “Dashboards”. - Good candidates to have custom-made dashboards include: Executive Sponsor - Metrics that track platform adoption and business value. Platform Owner - Metrics on platform performance, use, adoption, and business value. Service Owner - Metrics that track their service performance and use. Process Owner - Metrics that track their process performance and use. - Best Practices:

1. Keep your dashboards simple. Don't assume that more metrics will help stakeholders derive more value. Shoot for < 9 metrics per dashboard.
2. Focus on business value, not the technical performance of the system.
3. Display “goal” thresholds for important metrics so stakeholders can quickly see if something is off-track.
4. Title the dashboard with the target audience. Example: “Platform Owner Dashboard”.
5. Consider adding Filters so the user can explore deeper when needed, without cluttering the dashboard by presenting all information at once.

- Edit Mode: - The plus (+) button puts you into Edit mode: - To resize a widget, grab the bottom left corner of the widget with your mouse, and then drag. - To re-order widgets, drag them from their title bars. - Close the right panel to exit Edit mode. - Interactivity / Interactive Filters is a premium feature that requires separate licensing.

- Takeaway A Data Policy defines just two data rules for a table (Mandatory, and Read-Only), and can be set to be enforced on any attempted data changes, whether those changes be from the UI, from an Import Set, or from a SOAP Web Service. Additionally, once a Data Policy is written, a simple checkbox allows it to be applied as a UI policy on the client side. - Modules

System Policy - Rules - Data Policies

- A Data Policy allows you to enforce data consistency by setting a field to Mandatory / Required or Read Only. - Similar to a UI Policy, with these exceptions:

1. Execute on the Server
2. Applied, optionally, but by default, to all data entered into the platform:

From the UI (Including the List View) From Import Sets From SOAP web services. - A Data Policy may be enforced (early) at the UI layer by setting the “Use as UI Policy on Client” field to true.

1. This causes the Data Policy Rules underneath the Data Policy to be enforced on the client.

- For example, if a Data Policy Rule for the “City” field is set to Mandatory, then it will show up with a * next to it on the form, and the user will not even be able to submit the form without supplying a value for that field. If the field is set to Read Only, then the field will appear grayed out on the client, and the user will not be able to make any changes. - An alternative to the Mandatory rule for a Data Policy is a Dictionary Override. - Data Policies are an excellent way to handle Mandatory Fields, especially if you add a data policy for each field which needs to be handled, and you use the Conditions section to define when the field should be mandatory. Example:

- Modules

System Definition - Database Views

- Tables

sys_db_view
sys_db_view_table
sys_db_view_table_field 

- A way of taking 2 or more tables and joining them together into one “virtual” table, so that you have some columns from each joined table. initially setting up the view. - Process - You create your view, then you add tables in the related list “View Tables” (table sys_db_view). - Then for each of those tables, you drill into it, and you add fields in the related list “View Fields”. - Remember that after you add a new field to the view, to see the field show up in a List View, you may need to “Configure List Layout” (using one of the column menus), or you may need to Personalize your List Columns (using the gear icon). - You can use the “Try It” UI Action (under Related Links) on the sys_db_view form in order to see a preview of your view. - Left Join - Left Join gives you the records in the left table, whether or not they match to something in the Where clause. - For any related table that you want to pull in fields from, if you do NOT want that table to be strictly necessary, you can mark that table as “Left join”. - It seems like the table with the lowest “Order” value is treated as the “Left” / leftmost table, in that records will appear from that table even if no where conditions are defined (as long as that table is marked as “Left Join”). - Where Clause

1. Used to join tables.

- You give each table a prefix, such as “t1” or “t2” which may then be used as shorthand in the “Where clause” field of each table. - You really need to have a “where” clause (join clause) in mind when you design your database view. If you are not planning on returning records where data matches between two tables, then the Database View concept is probably not the right way to go.

1. Important: Use only lowercase letters for variable prefixes.

- Important: To specifiy a field in the Where clause, start with the variable prefix of the table, then add an underscore, then add the field name: - Example where clause: t2_sys_id = t1_cost_center - If you get an error on your Where clause when using the “Try It” link, it may be because one of your tables does not actually contain that view field in the list of fields to display. The field must be displayed in order for you to join on it or use it in a Where clause. - There is no support for LIKE or CONTAINS conditions in the Where clause of a database view - Important: By default, unlike tables, Database Views Do Include the sys_id column! - You can pull up your view directly from the filter navigator the same way you would for a table, for example by typing: u_user_geoff.list. - Quirks! - Often changes to the fields included in a Database View are not reflected immediately in the UI. You may need to use cache.do frequently when - Example:

Modules

Self-Service - My Profile (or get to Profile via the User dropdown menu at the top right of the title bar.

Delegates allow a user to delegate Approvals, Assignments, Email Notifications, and Meeting Invitations to a designated user, for a period of time. - Delegate records do NOT cause records to get reassigned. All they do is cause work or approvals to SHOW UP in additional queues such as My Work and My Approvals. If user A delegates to user B, and an approval record comes in for user A, it will show up in user A's queue, and user B's queue. If user A delegates to user B, and user B delegates to user C, approvals coming in for user A will NOT SHOW UP in user C's buckets, but work coming in for user B will.

- Allows users to do development work without being assigned the Admin role. - Allows specific permissions to be granted or withheld, per user, per scoped application. - Delegated Development allows an Administrator the ability to give a non-admin Developer development permissions for a single application. - An admin is still required to apply Update Sets.

- Passing a delta exam certifies that a participant has successfully understood the new features offered in the latest release of the Now Platform. - Release Notes are divided into three sections: Learn, Prepare, and Upgrade.

- To verify that your “ServiceNow Certified Application Developer” certification is “Current” and not “At Risk” or “Expired”, go here:

John Johnson https://nowlearning.servicenow.com/lxp?id=profile&parent=1eb3e5d31b08705002ed2f89bd4bcb75&child=a02b266c1ba0fc1002ed2f89bd4bcb4f

- Tokyo

1. https://docs.servicenow.com/search?labelkey=rn&labelkey=tokyo&labelkey=&rpp=10&sort.field=score&sort.value=dec

- San Diego

1. Learning Path

https://nowlearning.servicenow.com/lxp?id=learning_path_prev&path_id=bc210df11ba24990f95e99b8bd4bcb6c

1. Test

https://nowlearning.servicenow.com/lxp?id=learning_course&path_id=bc210df11ba24990f95e99b8bd4bcb6c&child_id=56836896db6e8514ad1cf9c8f4961946&spa=1

1. Product Documentation - Filtered

https://docs.servicenow.com/search?labelkey=sandiego&labelkey=&labelkey=rn&rpp=10&sort.field=score&sort.value=dec

1. From Rome

https://docs.servicenow.com/bundle/sandiego-release-notes/page/release-notes/concept/rn-n-1-landing-page.html

1. ITSM Changes
   1. New Features
      1. Service Operations Workspace (ITSM)
         1. A replacement for ITSM Workspace!
            1. Better Dashboard?
            2. Announcements
            3. Improved Layout (Contrast)
      2. On-Call Scheduling Integrations
      3. Recommendation Framework
   2. Modernization
      1. Next Experience UI
      2. Major Incident Workbench

- Orlando Release Notes - All the relevant articles start with “xx release notes”. If you are looking at the right article, the exam questions will be easy to answer. Good Search Method: - Knowledge Search with Left Pane Facets Selected 1) Form the docs site: https://docs.servicenow.com/ type in “Knowledge Management”. This will give you over 10,000 results. 2) From the filters on the left, under Versions, select Orlando. This will narrow your results to 6,700. 3) From the filters on the left again, under Products, select “Release Notes and Upgrades”. This will narrow your results to 93, and your most relevant article will be listed first.

- Rome - I spent about 4 hours reading about the release and taking the Delta certification. The key for taking the test is to use the Search, and the sort by “Rome” and also by “Release Notes”. All of the relevant articles start with “Release Notes”. Release Notes Search - Links to Articles which were on the Test https://docs.servicenow.com/bundle/rome-release-notes/page/release-notes/now-platform-app-engine/api-rn.html https://docs.servicenow.com/bundle/rome-release-notes/page/release-notes/now-platform-app-engine/delegated-development-deployment-rn.html https://docs.servicenow.com/bundle/rome-release-notes/page/release-notes/now-platform-app-engine/sn-studio-rn.html https://docs.servicenow.com/bundle/rome-release-notes/page/release-notes/now-platform-capabilities/automated-test-framework-rn.html https://docs.servicenow.com/bundle/rome-release-notes/page/release-notes/now-platform-capabilities/flow-designer-rn.html https://docs.servicenow.com/bundle/rome-release-notes/page/release-notes/now-platform-app-engine/api-rn.html

- ServiceNow has a number of Graphical Design tools, and they all work a little differently. - Design Tools Include: - Platform UI / Console View (more of a configuration tool, but also the main UI for all users) - Developer Studio (more of a development tool) - Flow Designer - Service Portal Designer - Virtual Agent Designer - Workflow Editor (obsolete) - Widget Editor

- This refers to displaying a note or comment, specific to a single record, which will be seen by others. - See file “ServiceNow_Knowledge_CustomNotesTable.docx”! - Other methods of adding custom notes:

AddFieldMsg		Cannot include line breaks.

AddInfoMessage Would need to include a conditional check against the specific sys_id you want the message for. Annotation Not sys_id specific. Custom Text Field Appears for all records, even if empty. Length 256 and greater is implemented as a varchar and really has no max length. Embedded Help Not displayed very prominently. Appears in the header as a “badge” over the “Toggle Help Sidebar” question mark icon. File Attachment Not very prominent. Cumbersome to open. Knowledge Article ?

- Takeaway - A Personal Developer Instance, or PDI, is a limited ServiceNow instance for practice and learning purposes. A PDI is free. A PDI may not be used in cloning, and PDI content may not be published to the ServiceNow Application Repository or the ServiceNow Store. - Docs Personal Developer Instance Guide https://developer.servicenow.com/dev.do - ServiceNow offers free Personal Developer Instances (PDIs) to those who want to develop apps or improve their skills on the Platform. - A tool for registered users for improving skills with ServiceNow or learning how to develop applications. - It takes about 3 minutes to “wake up” a “hibernating” developer instance. - After 10 days of inactivity, a hibernating instance is backed up and deactivated. You can restore a backed up instance for a limited time. - PDIs cannot be clone targets or clone sources for customer or partner instances. - PDIs cannot publish to the ServiceNow Application Repository or the ServiceNow Store. - Note that you CAN import update sets to a PDI and you CAN export update sets from a PDI. - See also: GitHub

- Developer Training Courses - These ServiceNow “Personal Developer Instance” Training Courses are designed for Software Developers, to enable them to gain a deep hands-on knowledge of the Now Platform. As of 04/16/2020, I have completed ALL of the 32 modules! Each module takes between half a day and a full day to complete. There are 801 Lessons in total. This took approximately 50 Days of Study, and I compiled over 100 pages of organized notes. - Note: There is no recognition for completing developer training courses. The system records your completion, but there is no direct way to publish/share that information. Also, there is significant overlap between the developer training courses and the Now Learning courses. Training Module Confidence A - C Module Number Lessons Complete Using the Automated Test Framework C 01 38  Application Properties B 02 13  Notifications B 03 31  Scheduled Script Executions and Events A 04 19  Workflow B 05 19  Guided App Creator and ServiceNow Studio C 06 15  ServiceNow Basics A 07 08  Create the NeedIt Application and Application Files B 08 27  Introduction to AngularJS in ServiceNow C 09 12  Embedded Help B 10 24  Developing Domain-Separated Applications B 11 29  Developing for Flow Designer B 12 32  Flow Designer Bonus Content: Decisions A 13 09  Using Flow Designer B 14 37  Importing Data B 15 19  Source Control C 16 29  Build My First Mobile Application C 17 23  Developing Mobile Applications C 18 40  Data Visualization C 19 39  Performance Analytics C 20 55  Inbound REST Integrations C 21 16  Outbound REST Integrations C 22 21  REST in Integration Hub C 23 23  Scripted REST APIs C 24 26  Client-side Scripting B 25 22  Introduction to Scripting in ServiceNow A 26 05  Server-Side Scripting B 27 31  Securing Applications Against Access from Other Applications B 28 15  Securing Applications Against Unauthorized Users B 29 20  Creating Custom Widgets C 30 33  Service Portal Introduction B 31 31  Developing Virtual Agent Topics B 32 40 

Modules

System Definition > Dictionary

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

https://docs.servicenow.com/bundle/paris-platform-administration/page/administer/data-dictionary-tables/concept/c_DictionaryOverrides.html - Dictionary overrides provide the ability to define a field on an extended table differently from the field on the parent table. - For example, for a field on the Task [task] table, a dictionary override can change the default value on the Incident [incident] table without affecting the default value on Task [task] or on Change [change]. - Administrators can override these aspects of a field:

Calculations
Default column display value
Default Value
Dictionary Attributes
Field Dependencies
Mandatory status
Read Only Status
Reference Qualifier

- Procedure for creating: Navigate to System Definition > Dictionary - Open the record for the field - In the Dictionary Overrides related list, click New.

- Can be used to control what information goes into the CMDB. - Different classes of devices may be easily turned off. - Software packages may be filtered out.

Discovery - Critical Concepts - Discovery is an Application within the ServiceNow platform; it is part of the ITOM product suite. - The purpose of Discovery is to populate the CMDB with current and reliable information about devices and software on the company's network. - Discovery enables and supports mature Infrastructure Management; tracks hardware, software, and dependencies. - Discovery finds IP-enabled Configuration Items and related Configuration Items. - Discovery requires a MID Server in order to be able to reach / discover company devices. - The MID Server software runs on a Server WITHIN the customer's Network, behind any corporate Firewalls, so it is Trusted. - A Configuration Item (CI) is a uniquely identified component which provides a service, and for which changes are controlled. - Examples of CIs are Servers, Applications, Databases, or Files. - Before discovery is run, there should be an understanding of the full company network topology and which parts of it will be scanned, and why. - HTTPS (port 443) is used to communicate between the MID Server and other entities. - At a High Level, the steps for Discovery are more or less as follows: The MID Server is instructed to scan targeted IP Addresses for open ports. Open ports are queried to classify each device based on operating system or function (power, print, switch, route, etc.). If the device is already known to ServiceNow (that is, it's in the CMDB already), its record is updated; otherwise a new CMDB Record is inserted. Then Discovery looks for running processes and dependencies, and again update the CMDB with those. - Definitions - Behavior

1. Determines the Probes that Shazzam launches. Limit the Protocols utilized.
2. External Communications Channel (ECC)
3. A ServiceNow table which is used as a bi-directional queue of both input and output instructions.

- Pattern - A Series of Operations that tells Discovery what CI to find, what credentials to use, what properties to retrieve, and what CMDB tables and fields to populate. Runs much faster than a Probe.

1. Probe
   1. An Instruction

- Schedule

1. Defines when Discovery will happen and what it will search for. Usually there is one schedule for each Data Center.

- Sensor

1. Updates the CMDB
2. A ServiceNow Business Rule the processes INPUT records in the ECC Queue.
3. Typically passes the work to be done to a sys_trigger record.

1. Discovery Fundamentals On Demand
2. Certified Implementation Specialist - Discovery Voucher - Eligible to take the Exam. But the cost is still $450.

- Lab Instance Instructional Video How to use Instances in Now Learning 2.0 - Lab Instance - URL

		https://nowlearning-nlinst00752670-001.lab.service-now.com/ 

- Username and Password - admin / q7dUFH2abAq7 - Tip: Right Clicking the “Open My Instance” button, and selecting Copy URL, then Pasting in a text editor, reveals the Username and Password! - MID Server Remote Desktop URL

1. nowlearning-nlinst00752670-mid-001.lab.service-now.com

- Administrator / q7dUFH2abAq7 - Simulator FAQ

	Simulator - Frequently Asked Questions  

- Web Log ServiceNow Discovery Simulator Question and Answer Blog

What Discovery is - Discovery is an Application within the ServiceNow platform. - Discovery is part of the ITOM product suite. What Discovery does - Captures IP-enabled configuration items (CIs), and related configuration items. - Maps CI relationships and dependencies, and stores the information found in the CMDB. - “If it has an IP Address, we can find it.” Value Discovery Provides - ServiceNow Discovery lays the groundwork for mature Infrastructure operations management. - Example Scenario: - Cloud Dimensions wants to identify, support, and approve various applications running on Windows systems in their datacenter. In addition, they want visibility to applications and their dependencies to other applications or to the hardware they are installed on. How Discovery works - Uses common communication protocols, not secret protocols. No Agents to deploy (optional). Discovers info about devices just as your Admins manage them.

1. Using probes, sensors, and discovery patterns.

- High Level Steps

	1.  Instructions called "Output Probes" are placed in the External Communications Channel (ECC) Queue (table).
	2.  A worker job on the MID Server periodically monitors the ECC Queue (via the SOAP Table API) for discovery work to be performed.
	3.  The MID Server follows Output Probe instructions and interrogates IP-enabled devices for information.
	4.  The MID Server reports back via Input records in the ECC Queue.  Each Input record may contain information in the form of an XML payload.
	5.  The Input record is processed by "Sensors" or "Discovery Patterns", and the CMDB is updated accordingly

Miscellaneous / MISC - Tables

1. Discovery Schedules (discovery_schedule)
2. Discovery is initiated via this table.

- Discovery Status (discovery_status)

1. Each time Discovery is run a status record is created here.
2. Quick Discovery status records go here also.
3. Discovery Log (discovery_log)

- Available as a Related List under each Discovery Status record. - Device (discovery_device_history) - Available as a Related List under each Discovery Status record. - Queues (ecc_queue) - This is the actual Electronic Communications Channel (ECC) Queue - Available as a Related List under each Discovery Status record. - Quick Discovery button

1. Found at the top of the Discovery Schedules (discovery_schedule) List View.

- Configuration Files that belong to certain applications can be copied to the CMDB. These are saved as separate CIs. - To Do List for Any New Company - Ask team (and network team) if any alarms will be raised if we run discovery whenever we want. Find out if they need to be pre-informed. - Run credential-less discovery on a small IP range, again to verify that there are no surprises. - Run full discovery on a small IP range, again to verify that there are no surprises. - Get an understanding of the full network topology, and what parts of it we are and are not scanning, and why.

- How you invoke any page, form, or list in ServiceNow. - The “.do” extension means “Do” something. - Used by JavaServer Pages using the struts framework. Struts is the ultimate “separate content from display” implementation. - The .do extension tells the Application Server to find a config file which calls the proper action class to process the form.

- A field type which may be used to reference any field on any table. - Uses 2 fields which work together. One identifies the table, and the other identifies the specific record.

1. The sys_id of the specified record is stored in the document ID field.
2. The table name is stored in the referenced (string) field.

Stages for success: 1) Define the business case guidelines. 2) Establish governance. 3) Define the development model. 4) Learn customization demands. - Use Configuration (within the Now platform) as the preferred option to meet business demands. - Decide on your North Star, the objectives and value you're trying to capture with ServiceNow.

1. Engage the executive sponsor and/or key IT and business Process Owners to define objectives and value metrics for your ServiceNow implementation.
2. Uses Cases for customization should then be tied to the North Star objectives.

- Understand how ServiceNow is working “today”. - Platform Owners should take the time to understand workflows of users like service desk personnel, who use ServiceNow to carry out their daily work. This can help determine where customization can help, and where older customization is getting the in the way.

1. Interview template:

1. Is there a documented guide/diagram/flowchart for the process?

		2.  Could you demo the process?
		3.  How does the process integrate with other processes?  And are these integrations documented?
		4.  Are there process activities today that are no longer useful?
		5.  Are there any process-improvement activities that are in-flight or under consideration?
		6.  How clear is the process in ServiceNow?  Where could it be made simpler?
		7.  What ServiceNow features work well?  What could be improved?
		8.  What ServiceNow features have been problematic during ServiceNow upgrades?

- Evaluate proposed customizations to determine Costs vs real Value:

Low - Customization supports experience for service consumers or process owners, but does not necessarily promote a business value objective.
Med - Customization promotes a business value objective, but another workaround is already available.
High - Customization is a "must have" to realize a business value objective.
Mandatory - Customization is required for regulatory or compliance purposes.

- Score Customization Proposals by their potential to impact Upgrades, Performance, or Technical Debt.

Configuration Scenario Impact to Upgrades Notes Change Form Layout / Design Low Will not delay upgrades. Add Fields to Forms Add UI Policies to Forms Low Will not delay upgrades, but it is suggested that the number of new form fields be kept low. IntegrationHub Integration Low Will not delay upgrades Extend a Table by adding fields Low Will not delay upgrades, but new fields should be strictly tied to business requirements. Use a Table for a new Purpose Low Effort should be preceded by clear process-mapping and acceptance testing among SMEs. Extend a Table with new Scripts Low/Medium Complexity is dependent on the extent of the scripting. Extend a Table for a new Application Low/Medium Effort should be preceded by clear process-mapping and acceptance testing among SMEs. Change a state Choice List Low/Medium May affect Upgrade time or new functionality if modifications change underlying business logic, rules, and/or policies. Build a new Application Medium Complexity is dependent on the extent of scripting. Build a new Global Application Medium/High May affect time to upgrade due to testing new functionality if app changes underlie business logic, rules, or policies. Change baseline business rules such as the SLA process High May affect time to upgrade due to testing or new functionality. Build a complex integration High May affect time to upgrade due to testing or new functionality.

- To prevent customizations from being overwritten during a system upgrade, the upgrade process skips (does not upgrade) any objects that have been customized. “Upgrade Monitor” can be used to list all objects skipped during the upgrade process to assist in identifying customizations. Customer may then decide if they wish to back out any of these customizations. - Big changes to Business Rules should come with a strong business justification, given their potential complexity. - In considering Cost vs Benefit, remember to consider the total volume of demand you anticipate for the proposed feature. - Establish Governance. - Executive sponsors and platform owners need to put guardrails in place to ensure that project teams implement ServiceNow customization only when there is explicit, defined business value that outweighs the potential cost. - A “federated governance model” is one that balances oversight of global standards and policies with front-line management of local demands. - A federated model for customization demand management is the best way to allow demands but also avoid risks to global platform stability. - Excessive customization is usually the fault of bad governance. - Scoped Applications give individual lines of business, regions, or teams, the freedom to develop custom applications and configurations locally, without risking platform stability. - For global applications, establish a demand board to ensure that the proposals adhere to the explicitly defined criteria for business value. The demand board should meet at least monthly (or as needed) to accept, intercept, vet, and prioritize new demands submitted by process owners, business partners, and others. - There should be a well-defined and well-communicated roadmap that makes service consumers aware of planned upgrades and customizations, to avoid redundant requests. - Limit your use of domain separation to a narrow set of use cases, such as when you must isolate data between entities. Domain Separation allows an organization to separate ServiceNow data, processes, and administrative tasks into logically defined groups. You can share some global properties, data, and processes across all domains, but individual domains may have customized process definitions and user interfaces. Most commonly domain separation is implemented for managed service providers required to isolate data between legally separate entities. - Use scoped applications to build custom apps in restricted or encapsulated environments. Custom applications in ServiceNow should be built “in scope”, as opposed to in the Global namespace. This ensures that an application has boundaries that allow the system to uniquely identify application artifacts like tables, properties, user roles, and public and private API definitions, encapsulate the runtime code, and provide table-level data access control. Application scoping protects applications by restricting access to application files and data. By default, all custom applications have a private scope that uniquely identifies them and their associated artifacts with a “namespace” identifier.

- Questions to Ask for a Successful Implementation:

1)  Do we have clear, explicit, and documented goals for our ServiceNow implementation?
	Example Goal Topic Areas: Improving Employee Experience, Reducing Service Outages, Increasing Speed of Delivery.
2)  Do we have consistent engagement with an executive sponsor for the implementation?
	Topics:
		- Progress.
		- Anticipated obstacles that may require additional resourcing.
		- Any changes to business priorities that may affect the implementation.
		- Early warning signs or risks that could affect the implementation.
		- Key messages for other executives.
3)  Have we defined a phased approach to implementation with an early emphasis on incremental wins?
4)  Have we explicitly committed to sticking to out-of-the-box functionality?
	- Customization can create downstream maintenance costs, and increase testing time required for upgrades.
	- Geoff:  But ServiceNow is a Platform!  It was designed from the ground up to be built upon.
5)  Have we explicitly defined and documented governance rules for the implementation?

- Create a defined decision model that explicitly identifies who approves different categories of decisions, and who is required to be informed or consulted about these decisions.

6)  Are we engaging certified and experienced partners to help lead the implementation?
7)  Do we have comprehensive training plans in place for technical staff and end users?
	- Poor training is a recipe for slow adoption.
8)  Do we have a fully budgeted plan for organizational change management?
	- A ServiceNow implementation Will change how people work.  Do expect confusion, inertia, and resistance.

- Ensure that your plan includes time and support for the teams most affected by the change. Elicit their voices and address their concerns. - Invest in demonstration and training activities that make teams confident they can navigate ServiceNow.

Takeaway - Domain Separation is used to segregate Data, Process, and UI components within a single ServiceNow instance. Domains exist in a hierarchy so a domain member sees the data of his own domain, and any child domains. Most commonly domain separation is implemented to allow a Managed Service Provider (MSP) to have centralized management of ServiceNow, but also to isolate data between legally separate entities (the Tenants); this allows both the MSP and the Tenants to take advantage of volume licensing, and also share in maintenance costs. Generally Domain Separation is invisible to the Tenants. When Domain Separation is installed on an Instance, additional fields are added to tables and allow records from one domain to override those from another domain. One confusing aspect of Domain Separation is the concept of Domain Scope (not to be confused with Application Scope). When a user is working in a Domain-Separated instance, there is a concept of Session Scope (the domain of the actual user) and Record scope (the domain of the record the user is working on); generally Record Scope takes precedence. Domain Separted Apps - Modules

Domain Admin - Domains
Domain Admin - Domain Map
Settings - General (to change domains)

- Plugins

Domain Support - Domain Extensions Installer 	(com.glide.comain.msp_extensions.installer)

- Domain Separation is used to separate Data and Business Process components in a single Instance. - A Domain is a logical security (visibility) grouping which may include Data, Business Processes, Tasks, and UI elements. - Some domain element may be global/shared, while other elements may be customized and specific to only one domain, or one group of domains. - Domains are configured in a hierarchy to structure how data and business processes are managed in the environment. Members of a domain see only the data contained within their domain or the child domains lower in the hierarchy. UI and Business Logic is inherited from parent domains, but can be overridden. - A user with access to multiple domains can change between active domains using Settings - General. - Settings - General may be used to add the “domain picker” to the header. - Domain Separation is designed to be invisible to Tenants. The Domain field is not visible on forms or lists. - System Administrators can manually set the domain on 5 types of records, as follows:

1. User
2. Group
3. Department
4. Location
5. Configuration Item

- Records: - A record with no domain is considered to be Global. Users in any domain can see Global records. - To protect customer data, Domain Separation is never activated on a production instance that includes customer data. Instead, Domain Separation would be activated on a new instance, and data would be migrated directly to the correct domain. - Customer data should always have a Domain. - Each record is assigned to a single domain.

1. Any records created before Domain Separation is activated will end up in the Global domain.

- The domain of each record is stored in the Domain (sys_domain) field.

1. A developer would need to manually add the “sys_domain” field to any custom tables in order to domain-separate the data in the table.
2. If the sys_domain field is not populated when a record is committed to the database, the record is added to the default domain.
3. If a user is assigned to a domain, any records the user creates are automatically added to that domain.
4. To see the domain that a record is assigned to, use the Personalize List icon, and add the Domain field to the Selected slushbucket.

- Default Domain:

1. If a domain is not assigned (explicitly or via script) when a record is created or updated, the record is global.

- To prevent data from mistakenly being exposed, Business Rules on baseline tables assign records without a domain to a default domain. - Tables that extend baseline tables, such as the Task table, inherit the Business Rules that assign records to the default domain. - Developers who build custom tables should include business logic to assign records to the default domain if no other strategy assigns a domain. - Managed Service Provider (MSP) - Most commonly domain separation is implemented to allow a Managed Service Provider (MSP) (or simply “Provider”) to have centralized management of ServiceNow, but also to isolate data between legally separate entities. - Organizations that use the MSP's instance are called “Tenants”. - The data for each Customer (Tenant) is separated into its own domain, so one customer's data is not visible to another customer. - MSPs may take advantage of volume licensing. - Benefits to Tenants using an MSP:

1. Lower minimum license threshold.
2. Access to pre-built processes and capabilities.
3. Reduced staff requirements.
4. Faster onboarding.
5. Lower (shared) instance costs.
6. Other services offered by the MSP.

- Each Tenant has its own domain in a domain-separated instance. - Domain Separation on an Instance can be disabled after it is activated, but it cannot be entirely removed, and it adds a level of administration overhead. - Domain Separation should only be used when ALL of the following requirements are in place:

1. Logical Data Separation OK (as opposed to a physical data separation requirement)
2. Small Scale (as opposed to requiring multiple Nodes and/or dedicated hardware)
3. Platform Requirements OK The customer can utilize the Products/Services provided on the shared platform.
4. Few Business Process Differences Customer has only a 5% (1 in 20) delta from the Processes provided on the shared platform.
5. Administration Requirements The Customer is OK with most of the Administration being done by the MSP.

- Alternatives to Domain Separation include:

1. Business Rules
2. Access Controls
3. Filters
4. Security on Records
5. Custom Views
6. Form layouts
7. Notifications
8. UI Action conditions
9. Advanced Reference Qualifiers

- Activation - RequestDomainSeparation

1. The plugin must be activated by ServiceNow personnel.
2. The plugin includes demo data.
3. Requires a Subscription to use on a production instance.
4. Should not be activated on a production instance that already contains customer data.

- User Interfaces in Domain Separated Instances:

1. Generally, user interface elements (forms, lists, and views) are configured in the Global domain.

- Tenant-specific UI elements can be overridden at the domain level. When the ServiceNow user belongs to a particular domain, the domain-specific UI elements are used.

1. Even though a table field may not be visible on a domain-specific form, it is still available for reporting and filters in the instance.

- Business Logic:

1. Business logic such as Business Rules, Client Scripts, and UI Policies may be configured globally, and all domains will inherit that configuration.

- Tenant-Specific logic elements may be overridden at the domain level. When the logic runs in a particular domain, that domain-specific version of the logic element is executed. - Domain-specific user interface (UI) and business logic are overrides in the table for the UI element or business logic. For example, a domain-specific Business Rule is an override record in the Business Rule table. The Domain (sys_domain) field identifies the domain of the override record and the Overrides (sys_overrides) field references the overridden record. When viewed from a domain, only the override record shows in the list. - By default, only global business logic appears in a list when global is selected in the domain picker. The Incident Business Rules list in global only includes global Business Rules. To see all the overrides in the global list, click the “Expand Domain Scope” Related Link. - Studio - Developer Studio should only be used to make changes to the Global domain! Studio has no domain picker/indicator, but studio will reflect changes made first in the ServiceNow Platform UI.

1. Developers should make domain-specific changes in the main ServiceNow Platform UI, with the domain picker visible in the ServiceNow banner.

- Domain Scope:

1. Controls the domains and data available.
2. Every user has 2 domain scopes when working in a domain-separated instance:

1) Session Scope - This is the domain configured in the user's record, as well as all child domains of that domain.

2) Record Scope - This is the domain of the currently open record.
- Record Scope takes precedence over session scope, by default.
	- Reference fields reference only data in the record scope's domain.
	- Form layouts are shown, and business logic runs, according to the record scope's domain.

A user with the “domain_expand_scope” role can use the Additional Actions hamburger menu and the “Toggle Domain Scope” menu item to change from record scope to session scope. A blue information message at the top of the form says “Domain scope expanded!” when the user does this. This will affect the form layout, business logic, and reference fields. - If a user from the more limited Domain views a record for which a field has been set to a value outside that domain, the value will appear to be blank; however the “Preview Record” icon will be displayed next to the field. - Domain Visibility:

1. “Contains Domains” may be used to allow an entire domain to access another domain in a different part of the domain hierarchy!
   1. Configure a contained domain on the “Contains Domains” related list on a domain record.
2. “Visibility Domains” allows specific users and groups to view records in a domain in a different part of the domain hierarchy.

- Configure from a Group or User record using the “Visibility Domains” related list. You may need to first click the Additional Actions menu and select the Toggle Domain Scope menu item. - Contains Domains and Visibility domains are not a substitution for proper hierarchy configuration and should be used where hierarchy cannot meet the data separation and business logic requirements. For example, an MSP might have its own processes but needs to work with tenant data. The MSP domain cannot be a parent domain of the tenants, because the tenants would inherit business logic from the MSP domain. Planning a Domain Separated Application:

1. At a minimum the plan should include Business Logic, the Data Model, and the User Interface.
2. Clearly state the business problem to be solved, and the desired outcomes (business value).
3. List all stakeholders for the application, including the provider, tenant admins, and tenant users.
4. Clearly define each business process that will be a part of the application, including the Steps, Stakeholders, Data Sources, and Outputs/Visualizations.
5. Decide when the MSP should be able to see (or not see) the tenant's data.
6. Determine what Setup will be necessary for onboarding or offboarding tenants who use the application.

- Data Model: Determine the data model for the application, as well as the relationships between the tables. Note that changing the data model during the application development process can cause extensive re-working of an application's logic.

1. Include the Domain field for each domain-separated table.
2. Decide how records will be assigned a domain.
3. Determine which properties are global and which should be configured per tenant.

- Applications are developed to support Domain Separation. - Domain Support Levels:

1. Determine the degree to which an Application supports Domain Separation.
2. Levels:

0) Data Only - A “Domain” field is used on most tables to identify the domain for each record. But Logic does not exist to route data to the proper domain for all use-cases. Tenants are able to use the application without being aware of other tenants.

1. Data Separation
   1. Add a Domain (sys_domain) field to each custom table to separate data per domain.
      1. ServiceNow automatically converts the data type you add to the Domain Id data type.
      2. ServiceNow automatically creates a Domain Path field that is used to optimize domain queries.
2. Business Logic Separation
   1. Add an Overrides (sys_overrides) field to allow domain-specific configurations.

1) Tenant Data Management - Data routing to domains is handled automatically by the application. - Domain support Level 1 requires records to automatically route to domains regardless of who creates the record and the session scope of the user. For example, if a technician from a Managed Service Provider creates a record for a tenant in the Initech domain while in the MSP domain, the record should be created in the tenant's domain. Users should not need to manually assign records to a domain. Tenants should never see the Domain [sys_domain] field. Domain routing is handled by Business Rules. Most Domain Separation Business Rules begin with the word Domain. To see sample domain-routing Business Rules, use the Application Navigator to open System Definition > Business Rules. Search for Business Rules that contain the word domain. - Auto-Routing based on Record Data

1. The most common way to assign a record to a domain is to set the Company field on a record.

- Another field may also be used, such as a “task_for” field on Task records. Any table that extends the Task table, such as Incident or NeedIt, can populate the task_for field to assign a domain to the record. - In most situations a child or related record inherits the domain of the parent record, or record from which it is created. However, in some cases this may not be correct; for example, if a user in the MSP domain toggles the domain scope of a User record and then assigns a role to the user. Business rules must be setup to account for this. - To prevent global records from unintentionally being created, a Business Rule that runs after the other domain-assignment Business Rules should assign any records without a domain to the default domain. 2) Tenant Process Management - The MSP (instance owner) can configure basic Logic and Data parameters per tenant, as needed by the application. - To create properties that can be configured per domain, create a table in the application. Create a column for each application property. Use a data type appropriate to the property. To configure properties per domain, the table needs two additional columns: - Domain - Set the Name to sys_domain. The instance converts the field to a Domain ID type and creates a Domain Path field used by Domain Separation to optimize domain queries. - Overrides - Set the Name to sys_overrides and use the Reference field type that references the properties table.

1. To configure domain-specific values for a tenant, the instance owner creates an override record for the properties.

- Select the tenant's domain in the domain picker. - Open the global properties record. - Configure the domain-specific property values. - Click the Update button. - Instead of updating the global properties record, the instance creates an override record for the domain. 3) Tenant Self-Managed Configuration - Tenants can configure Logic and Data parameters for themselves.

1. Here you simply use an application admin role to grant tenant users access to the domain-separated properties table (from level 2).

- Tenant users should NEVER be given the admin role in a domain-separated instance. Users with the admin role can change the domain on user records and reassign themselves to other domains. An application admin role is used to grant permissions within an application. - In most situations, the domain of a record should not change after the record is created. Changing a domain can be dangerous, as field values configured on the record in one domain may not be available in another domain. Alternate business logic may not be applied properly or business logic for multiple domains might be applied to the record, leaving the record in an unstable state. Records added to the default domain, however, may need to be reassigned to the correct domain. If a record's domain changes, related records should also be reassigned. For example, if a knowledge article needs to be moved to a different domain, all feedback on the article should also be moved to the different domain. - Approvals automatically inherit the domain for the record being approved. - Segmentation is not recommended.

https://docs.servicenow.com/bundle/quebec-platform-user-interface/page/use/navigation/reference/dot-walking-examples.html - Gathering info from a series of table reference fields, or object reference fields. - Condition Builder - In a List View's Filter Condition Builder, when you go to select a field, each reference field is followed by the fields in that referenced table. For example, if you are filtering on the incident table, there is a Caller field which is of type User. So the field selection dropdown shows “Caller =⇒ User Fields” to give you an opportunity to select one of the fields from the Caller's record in the User table. If you do NOT see reference fields displayed in this way, select the last item in the list which should be “Show Related Fields”. This will cause the dropdown list to re-load, and display the related fields. When you select a Reference Field such as Caller, the list again reloads, and displays the fields available in that referenced table. For example, if you select Caller, you will then have an opportunity to choose a field from the User table, such as City or Company. If you choose another reference field, such as Company, it then becomes possible to drill down another layer, and select fields from the Caller.Company record. The list displays a . prefix for each layer you have drilled down. Selecting the topmost list item allows you to back up in the hierarchy. For example, selecting “Incident fields” allows you to go back up and see the fields at the topmost level. - List Collector (Slush Bucket) - Reference fields show up in green and have a plus [+] symbol in brackets after them. Once a reference field is highlighted, an “expand” icon

appears.  Selecting the expand icon opens the list of fields from the related list in the Available pane.  

- Client Script - This is really just a JavaScript capability, and has nothing to do with ServiceNow. If you have an Object in memory, you can Dot Walk to other related objects. In client script, and use of the “current” object is NOT necessary. Example: document. getElementById ( 'label.incident.caller_id' ). style. backgroundColor = 'red' ; - Server Script

1. You can Dot Walk in server script by starting with the current object, for example:

try{ current. opened_by. manager; } catch (err) { } - Another example:

var grUser = new GlideRecordSecure('sys_user');
if (grUser.get(mySysId)) {
	var sReturnValue;

sReturnValue = grUser.manager.name + “”; “Kendra Dieter” OR sReturnValue = grUser.manager.name.getValue(“name”); “Kendra Dieter” sReturnValue = grUser; [object Object] sReturnValue = grUser + “”; [object GlideRecordSecure] sReturnValue = grUser.toString(); [object GlideRecordSecure] sReturnValue = grUser.first_name; [object Object] sReturnValue = grUser.name; [object Object] sReturnValue = grUser.first_name + “”; “Geoffrey” sReturnValue = grUser.name + “”; “Geoffrey Bishop” sReturnValue = grUser.getValue(“first_name”); “Geoffrey” sReturnValue = grUser.getValue(“name”); “Geoffrey Bishop” sReturnValue = grUser.manager; [object Object] sReturnValue = grUser.manager + “”; aecf1e76dbbad0507f39ce61399619b7“ sReturnValue = grUser.manager.toString(); aecf1e76dbbad0507f39ce61399619b7” Must be a different record type. Not sure what type though.

		
		//sReturnValue = grUser.getValue("manager"); //aecf1e76dbbad0507f39ce61399619b7"
		//sReturnValue = grUser.manager.getDisplayName() + ""; //undefined.  This must not be an actual GlideUser object.
		//sReturnValue = grUser.manager.getUserRoles() + ""; //undefined.  This must not be an actual GlideUser object.
		//sReturnValue = grUser.manager.name; //[object Object]
		//sReturnValue = grUser.manager.name + ""; //"Kendra Dieter"
		
		//sReturnValue = grUser.manager.first_name + ""; //"Kendra"
		//sReturnValue = grUser.manager.getValue("first_name"); //aecf1e76dbbad0507f39ce61399619b7
		
		//sReturnValue = grUser.manager.name.getValue("BOZO"); //"Kendra Dieter"			
		//sReturnValue = grUser.manager.getValue("BOZO!!!"); //aecf1e76dbbad0507f39ce61399619b7			

- Variables

1. Often you will be able to use Dot Walk syntax in variables, such as Notification variables. Example:

${assigned_to.department.manager.mobile_phone}

1. A “Tree Picker” may be available to help you locate the correct field in a reference record.