ServiceNow CIS-ITSM Exam Study Guide

In this post you'll find resources for studying for the ServiceNow Certified Implementation Specialist - IT Service Management Exam.

Everything in this post has been used by me to pass the exam and receive the ITSM Implementation Specialist certification in ServiceNow. Similar to our other study guides, you'll see a breakdown of relevant links, important tables and roles, links to resources I used when studying and my own personal notes from the ITSM Implementation Now Learning course.

Happy studying and good luck!

‍

You can also check out our exam guides for Certified Application Developer (CAD) and Software Asset Management (SAM) and Application Portfolio Management (APM).

‍

If you're new to ServiceNow certifications, learn how to get certified in ServiceNow.

‍

Structure Of The Study Guide

1. Relevant Links - easily access the course, blueprint, and webassessor
2. Tables and Roles - all ITSM tables and roles listed 
3. Practice Resources - Links to resources I used to study for the exam
4. Notes - a full list of notes from studying the content

‍

Relevant Links

• Course Link (must be signed in)
• Webassessor (must be signed in)

‍

Tables and Roles

ITSM Tables 

CMDB & CSDM 

• [cmdm_ci]: All technical configuration items extend from this table
• [cmdb]: non-technical configuration items, such as equipment extend direction from the Base Configuration Item [cmdb]
• [cmdb_rel_ci]: The CI relationship table, which stores CI relationship data

Service Catalog and Request Management

Primary Tables Associated with Catalog Definitions

• Catalog [sc_catalog]
• Category [sc_category]
• Catalog Item [sc_cat_item]
• Order Guide [sc_cat_item_guide]

Primary tables associated with managing open requests

• Request [sc_request]
• Request Item [sc_req_item]
• Catalog Task [sc_task]

Knowledge Platform 

• Knowledge [kb_knowledge]: stores knowledge articles. Does not extend from task
• Knowledge Base [kb_knowledge_base]: knowledge articles are associated with a single one of these. A single article may not be associated with multiple knowledge bases
• Knowledge Category [kb_category]: associated to articles. An article may be published within a single category. Categories may be nested through parent-child relationships. 
• Knowledge Use [kb_use]: tracks articles that have been “attached” to incidents as well as when articles have been viewed. 

Incident Management Platform

• Incident [Incident]: stores incident records
• Task [task]: incident table extends from the Task table
• Incident Task [incident_task]: A related table that extends from task. Appears as a related list on the incident form. 

Problem Management Platform

• Problem [problem]: table stores problem records
• Problem extends the [task] table
• Problem task [problem_task] is a related table which also extends task, and can be found on the form as a related list

Change and Release Management

• Change Request [change_request]: stories change request records
• Change request extends from the [task] table
• Change Task [change_task] extends from Task, but is related to change. This table is a related list on the Change Request form.

ITSM Roles to Know

Important roles throughout all of IT Service Management 

• Admin
• Itil_admin
• Itil 
• Admin + itil 

CMDB & CSDM

• Admin
• Ecmdb_admin
• Cmdb_read
• Itil_admin
• Itil
• App_service_admin
• System (discovery)

Service Catalog and Request Management

Service Request Platform roles - Fulfillment

• Catalog_admin
• Catalog_manager
• Catalog_editor
• User
• User_criteria_admin
• Sn_request_read
• Sn_request_write
• Approver_user

Service Request Platform Roles

• Catalog_admin
• Catalog_builder_editor
• Catalog_manager
• Catalog_editor

Knowledge Platform roles

• Knowledge_admin
• Knowledge_manager
• Knowledge_coach
• Knowledge_domain_expert
• Knowledge_group_manager
• Knowledge_group_member
• Knowledge (can contribute)
• Knowledge (can view)

Incident Management Platform Roles

• Incident_manager
• Major_incident_manager
• user(caller)
• Sn_incident_read
• Sn_incident_write
• System

Problem Management

• Problem_admin
• Problem_manager
• Problem_coordinator
• problem_task_Analyst
• Sn_problem_read
• Sn_problem_write

Change Management Platform Roles

• Sn_change_cab.cmdb_manager
• Change_manager
• Approver_user
• user(requested)
• Sn_change_read
• sn_change_write

Practice Resources

• ITSM CIS Practice Quizlet 
• ServiceNow CIS ITSM Exam Prep Quizlet
• ServiceNow IT Service Management (CIS - ITSM) Practice Tests

Notes

*This section is broken down by module of the Now Learning ITSM Implementation Course. The order is listed below: 

I. CSDM & CSM

II. Service Portfolio Management

III. Service Catalog and Request Management

IV. Knowledge Management

V. Incident Management

VI. Problem Management

VII. Change and Release Management

I. CSDM & CSDM

All technical configuration items extend from Configuration Item [cmdb_ci]

Non-technical configuration items, such as equipment extend directly from Base Configuration Item [cmdb]

For customers who are just beginning to design a CMDB, consider the base classes first, which can be found in Configuration > Base Items and include:

• Servers
• Computers
• Workstations
• Out-of-band devices
• Network gear
• Printers
• Communication devices
• UPSs
• Accessories
• Computer peripherals
• Software

Dynamic CI Groups

• A Dynamic CI group is a dynamic grouping of configuration items (Cis) based on some common criteria.
• By default, the maximum number of CI's that a dynamic group can contain is 10,000

Principal CI Class

• Once any class is set as a principal class, the principal class filter ia automatically applied to the Configuration Item field on change, incident, and problem records. The Affected CI related list will have the principal class filter available for us.
• This means that only CI's within a principal class can be selected on the configuration item field

Independent and Dependent CI's

• Independent: exist on their own and are not dependent on any other Cis
• Depend on a relationship to another CI and cannot exist on their own
• To establish CI Dependency, you can use the CI Class Manager to specify dependent relationship rules for a CI Class

Common Service Data Model (CSDM)

CSDM is prescriptive guidance, and the CMDB is in the instantiation of the guidance. CSDM is the backbone for the service configuration and connects your CMDB from both a business and technical perspective.

Key CSDM Concepts:

• Service
• Product
• Portfolio
• Lifecycle
• Ownership
• Risk

Key CSDM Principles:

• Simplified concepts
• Designed for reporting and analytics
• Prescriptive relationships
• Shared data model collaboration
• Definitions
• CSDM OOB tables
• Consistent data integrations
• CSDM adoption
• Data governance and process
• Product use documentation

II. Service Portfolio Management

Service Portfolio Management Provides:

• The ability to define multiple IT Service portfolios, each with its own unique taxonomy structure
• The ability to associate Services and Offerings with specific portfolios
• Expanded service and service offering data
• Service portfolio management is the creation, organization, and management of a portfolio of services. A service portfolio includes information related to the organization of services and data about each service, including status, as well as related items.
• Service offerings are added and maintained via Change and Release Management

What are services and offerings?

• Service: A means of delivering value to customers by facilitating outcomes that customers want to achieve without owning the costs and risks
• An offering is contained within a service record and consists of one or more service commitments that uniquely define the level of service in terms of availability, scope, pricing and packaging options

 CSDM domains and data model grouping

• From the CSDM perspective, application services and technical services fall within the Manage Technical Services data model. Business services fall within the Sell/Consume data model
• Service offerings will always have a parent service record and may also be associated to other service offering records when there are dependencies outside of the taxonomy structure
• In any given structure, the last layer will always contain the taxonomy lead node(s) and any layer above that contains taxonomy node(s)
• Each service must have at least one defined offering to move to the Catalog phase 

Services

• Services are intended to be a meta-container for offerings 

Service Scope

• Out of Scope items define what a service cannot provide and In Scope items define what a service provides. By defining scope, you can grant or deny specific services that define a more detailed view of a service

Offering

A service offering will always have a parent service and each service must have at least one defined offering to move to the Catalog phase.

Inherit form field values from parent Service records to streamline Offering form configuration.

The following offering form fields are inherited from parent service and are automatically populated:

• Business criticality
• Service owner
• Delivery manager
• Delegate

 Defining offerings and commitments

• Offering records define the different levels of service and service commitments for an existing service
• An offering should consist of a set of service commitments which uniquely define the offerings and their availability guarantee, scope and pricing.
• To create service commitments, each service needs at least one associated service offering.

Offering price

• Offerings inherit the pricing structure of the associated parent service.
• If the price model is defined in the parent service as per unit, then each offering must also have an associated price unit. The actual price for that unit is established in the offering record.

Digital Portfolio Management (DPM)

• Manage and maintain all your services, applications, and products from a single location using the SN Digital Portfolio Management (DPM) application.
• Using DPM enables you to surface data from solutions you own as well as from solutions that you don't own but rely on from other SN products.
• Without DPM, the business lacks a central place to view and manage their services, applications, and products.
• DPM is targeted for users who own solutions like services, service offerings, business applications, or other products. 

III. Service Catalog and Request Management

Relies heavily upon:

• The change management process for controlling changes to the service catalog
• The request management process for fulfilling items defined in the service catalog
• Asset and configuration management for providing information regarding dependencies between services, assets, and configuration items
• Release management to update and / or add services within the Service Catalog

Taxonomy

• The SP taxonomy only includes requests (items), the Employee Center is designed to curate different content types (such as requests, knowledge, external links, etc) through the lens of different departments or services
• The Employee Center taxonomy - the simpler the request catalog taxonomy is, the easier it is to build into Employee Center. Keep taxonomies as simple as possible.

How many Catalogs are needed?

• It is recommended to create at least two catalogs; a customer focused version and an IT focused version

Catalog Definition

Managers

• Can edit catalog records, manage categories, assign editors
• Can create, modify and publish items within their catalog

Editors

• Can create, modify and publish items within catalogs they are assigned to

Enable Wish List

• Allows users to save partially completed requests

Catalog Categories

Although there is no limit to the number of categories or the depth, it is important to keep in mind:

• Keep number of top-level categories to 8-10
• Do not go too deep. Nest categories 1-2 levels deep only
• Organize in a way that will make sense to the audience
• Use language the audience will understand

The key purpose of the category structure is to allow internal catalog maintenance teams to browse the catalog and discover what services are available to them.

Categories provide a logical grouping of services for storing in the catalog rather than one great long list.

Add catalog categories to the EC by associating the category to a content taxonomy

• Portal configuration
• Open taxonomy record from related list
• Open child topic record
• Add content from a catalog category related link
• Add the catalog category(ies)
• Click ok 

User Criteria

Used to determine who will have access to request particular items from the catalog

Can be created once and reused many times to grant or restrict access for both service catalogs and catalog items

User criteria can:

• Be identified by individuals, groups, roles, companies, locations, departments or a combination of all these things. More complex rules can be scripted if necessary
• Be used to specify who CAN have access to items and also the specify who CANNOT have access to items. CANNOT criteria overrides the CAN criteria, even if an individual appears in both settings. 

Catalog Items

• Define the forms used to order goods and services and the fulfillment process for those goods and services.
• May be published into multiple catalogs and categories to allow end users to easily find them

Configurable Items

• Cart widgets
• Preview screens
• Order status screens

VE Editor

• A formatter that ONLY applies to requested item and catalog form tasks.
• Shows variables entered in the catalog item form and may reflect catalog UI policies put in place for the item
• For a record producer, the default variable editor displays the values of questions for records generated from a record producer for task-extended tables
• Default variable editor is only for record producers. Veditor is for catalog items and catalog tasks

Catalog Builder

• Items published via Catalog Builder are automatically added to a unique update set.
• This allows for business users to focus on creating their required catalog items and eliminates their need to manage update sets.

Record Producer

• Provide a user-friendly way to generate records within SN and gather relevant info from users to expedite handing of their request or issue
• Rather than creating unnecessary fields on tables such as incident, problem, and change, a Variable Editor may be added to a form view instead

Order Guides

Allow organizations to group multiple items typically ordered together.

Common use of order guides is to onboard a new employee

Cascade variables checkbox on order guide form: pass variables in initial order to their equivalent additional items

• Rather than asking the user to complete identical fields on each included item, the user may be prompted for the info once as part of the order guide. Then if cascade variables is selected, the values for these common variables will be populated on each item
• Duplicate variables on each item may be hidden to help keep the user interface need and clean

TIP: write an onLoad Catalog Client script to hide cascaded variables

Limitations on Multi-Row variable sets

• Cannot include variable types: attachment, break, container end/split/start, HTML, Label, custom, custom with label, rich text label, and UI page
• Map to field functionality is not supported for variables used in the variable set
• Cannot be displayed when added within a container
• Not visible in variable summarizer
• Cannot add variables with read roles
• Not available in catalog tasks, UI policy conditions, unsupported ATF step configurations

 Catalog UI Policies

• Control the behavior of catalog item forms when presented to your users.
• Can be applied to a catalog item or variable set
• Allow variables to be set to mandatory, visible, or read-only based on defined conditions. These policies work on variables included on catalog item forms and variables displayed through a variables editor on the request, request item, and catalog task forms
• The variables in a service catalog UI policy condition must be visible (even if hidden by UI policy or read-only) on the form for the condition to be tested
• Service Catalog UI policies are applied to variables and variable sets of catalog items ordered in the service catalog. They can also be applied when the variables are present in a RITM or Catalog Task form

Catalog Client Scripts

• Run client side to control behavior of items presented to users.
• Use them to validate content, populate fields dynamically, or clear variable values based on changes to other variables. 

State, Request State, and Stage

• Fields to track lifecycle information
• The set active flag [sc_req_item] business rule is triggered when the stage is set to one of the closed values (complete, incomplete, skipped, or request cancelled) and sets Active = false
• Once Active = false, the task closer [task table] business rule is triggered, which updates the RITM's state to 3 - Closed Complete

Request Item Stage Sets

A stage set with generic stages that work in most cases is provided in new SN instances

When configuring in Flow Designer you can:

• Create any number of stages
• Change stage labels and names
• Set the estimated duration for a stage
• Import a copy of a pre-defined stage set from the Stage Sets table. Any changes made to the copy do not affect the original stage set record. (Only use stages in flows with record and SC triggers. Stages are not supported in subflows.)

Processing a Service Catalog Request

• A service catalog request workflow MUST be active, and upon approval of the request (whether automatic or manual) the requested item workflow(s), or flow(s) are initiated 

Processing a Service Catalog item

• ServiceNow provides a default Execution Plan, workflow and flow for service catalog item requests in the baseline.

Fulfillment in Catalog Builder

By default there are three types of steps available, but system admins can configure additional options if needed:

• Task - can be assigned to individuals or groups
• Custom approval - can be for an individual or group; can require a single approval or all group member approval
• Manager approval

Service Level Agreements (SLAs)

• Define SLAs for catalog items on the sc_req_item table and selecting the catalog item(s) to apply the SLA to within the start condition.

Reporting

• The request overview dashboard (Service Catalog > Request Overview), includes a number of widgets and reports to help users manage the request management process
• The Service Catalog Overview Dashboard includes widgets and reports to monitor aggregated catalog item data like fulfillment automation coverage, translation coverage, and conversational coverage
• Users must have catalog_admin to view this dashboard

Reporting on Service Catalog Item Variables

SC Item Variables are available for inclusion in filters, list layouts, and reports

Reporting on catalog item variables may help questions such as:

• How many dev laptops were ordered with upgraded storage and memory?
• How many database restores in the past month were requested due to application errors/data corruption?
• What is the most commonly requested software request with new computers?

Database Views

• Exist in baseline instances to combine information related to SLAs and metrics with requests, requested items, and catalog tasks

 Service Catalog API

• A robust scripted REST API has been created within ascoped application to facilitate integrations with the service catalog

IV. Knowledge Management

ITIL processes interact with Knowledge Management in many ways, for example:

• Provides access to knowledge articles via the service catalog
• Updates knowledge articles are part of change implementation (and release management)
• Provides troubleshooting and resolution steps to resolve incidents
• Provides workaround information to resolve incidents related to problems and known errors
• Knowledge articles may contain key information about a service or service offering

Knowledge Management Portal

Advanced commenting supports:

• Nested comments
• Adding attachments (admins can define limitations for number of attachments and size of attachments)
• The ability to format a comment, including the ability to add inline images within a comment
• The ability to "like" a comment
• The ability for users to delete their own comment (knowledge admins can delete any comment)

Employee Center

• Integrate knowledge base categories to Employee Center taxonomies for a streamlined experience for Employee Center users.
• Individual knowledge articles can also be added as Quick Links from the topic navigation bar

Taxonomy: Platform, Portal and Mobile vs. Employee Center

• The taxonomy for a knowledge base and employee center are separate as they organize content through different lenses for different personas
• The knowledge base structure that is accessed from the platform, portal, or mobile only includes knowledge articles, however Employee Center is designed to curate different content types (such as requests, knowledge, external links etc) through the lens of different departments or services
• Knowledge articles (and catalog items) can be added to an Employee Center taxonomy topic by category or individually
• If the Knowledge Mnagement KCS plugin (com.snc.knowledge_kcs_capabilities) is enabled, three additional roles specific to knowledge-centered service roles are also available: kcs_contributor, kcs_publisher, and kcs_candidate

Knowledge Base Form

• Users are automatically assigned the security roles required to manage a knowledge base when they are assigned to the Owner and Manager fields. These roles are automatically removed when they are no longer assigned as owner or manager on any knowledge base in the system.
• Available baseline workflows include Knowledge Instance Publish, Knowledge Instant Retire, Knowledge - Approval Publish and Knowledge - Approval Retire. If the logic included in these workflows does not meet customer requirements, copy the existing workflows to make custom workflows rather than editing the baseline workflows.

Managing Knowledge Base Access

• Access to a knowledge base is managed through User Criteria records
• To control access to logged in users only, administrators should leverage the glide.knowman.block_access_with_no_user_criteria property

Knowledge Article Creation

• Manual creation: users with knowledge role may create new articles manually from the knowledge application. Users with permission to contribute to a knowledge base may create new articles manually from the Create an Article button on the Knowledge Homepage
• Existing Records: on the incident form, select the Knowledge checkbox. A knowledge article is generated upon closure and is pre-populated with information from the record. On the problem form, click the Create Known Error article related link to generate a knowledge article that is pre-populated with the workaround and cause from the problem record.
• Import: Users with permission to contribute knowledge articles can also Import Work docs as knowledge articles - go to Knowledge > articles > Import Articles module. The External Content Integrations plugin allows you to integrate content from various external sources and provide consolidated knowledge search results
• Integrate Externally: Admins can integrate with WebDAV, external content sources to create knowledge article records in ServiceNow directly from the files within the source.

Publishing Workflows

• The KBWorkflowSNC script include contains the business logic for workflows that publish knowledge articles. If customers require different logic, copy the publishKnowledge() function from the customizable KBWorkflow script include and amend the code in the KBWorkflow script include
• The getApprovers() function in the KBWorkflowSNC script include determines approvers. Override this method in the KBWorkflow script include to modify approval functionality 

Retiring Workflows

• The business logic to retire articles is set in the KBWorkflowSNC script include. To override logic used to retire a knowledge article to meet customer requirements, copy the retireKnowledge function from the KBWorkflowSNC Script include into the KBWorkflow script include. Then, modify the logic in the KBWorkflow script include. There is no need to modify the retire workflows directly.

Search Logs

• The Knowledge Searchs [ts_query_kb] table tracks every query users enter into knowledge search (it does not log global search query terms). This log table provides insights into the demand for knowledge across an organization and should be monitored.

‍

V. Incident Management

Incidents move through a basic process that includes three stages:

1. Creation and Classification: after finding an issue, create a new incident or locate one that was submitted by the user, created automatically, or generated through another app. Document the details and assign it to the appropriate group and or user

2. Investigation and Diagnosis

3. Resolution and Closure

Incidents can be managed through the native platform and through Service Operations Workspace. The platform provides a variety of views to support the various personas, processes, and interfaces.

Examples Include:

• Default view (agents)
• Major incidents
• Metrics
• Mobile (Mobile Classic)
• Password
• Self Service (End users)

Avenues for Incident Creation:

• Employee Center and Portals
• Incident Application or Workspace
• Support Chat
• Inbound Email
• Universal Request
• Integrations (webservices, i.e. import sets, REST, SOAP)

Copying an incident, creating a child incident:

• You can copy or create child incidents without manually entering the value of all the fields in the new incident. The Copy Incident Functionality copies the details of an existing incident record to a new incident record.
• The Create Child Incident functionality copies the details of the parent incident and links the  new incident to the parent incident.
• The parent and child incidents are synchronized such that the state of a child incident changes depending on the state of the parent incident
• When an incident has a child incident, the following actions take place: If an ITIL user reopens the parent incident, then the parent incident as well as the child incident reopens. Both the parent and child incident state is set to in Progress. If an ESS user (caller) reopens the parent incident, the parent incident state is set to In Progress, but the child incident is not reopened.

Record Producers

• User friendly way to generate records within SN and gather relevant info from users to expedite handing of their request or issue
• You can create a record producer for tables and database views that are in the same scope as the record producer.
• Record Producers are created and maintained within the Service Catalog application: Service Catalog > Catalog Definition > Record Producers 

Inbound Actions

Similar to business rules: both use conditions and scripts that take action on a target table.

An inbound email action checks the email for a watermark that associates it with a task and checks for other conditions. If the conditions are met, the system takes the inbound email action that you configure. The system can take two types of actions

• Record action: setting a value for a field in the target table
• Email reply: sending an email back to the source that triggered the action

By default, if an email has no identifiable watermark, an inbound email action creates a new incident from the message.

If the email has a watermark of an existing incident, an inbound email action updates the existing incident according to the action's script. 

A big decision for every org is categorization. Besides the work it takes to define the category structure itself, another important question is "How is the category going to be populated on a form?" There are typically two options:

• Have the agent (or end-user) populate the category and sub-category manually
• Have the category (and sub-category) populate based on the configuration item selected

TIPS:

• Demo data categories and sub-categories must be deleted before loading client data. Do this carefully
• Categorization driven by CI is typically appropriate for customers with robust and mature CMDB's only
• Choice are on the [sys_choice] table, which contains choices for EVERY choice field in the syste,. Right-click on the Category field label and select Show Choice List to identify specific choices to be deleted.

Incident deflection: contextual search

• The related search results that appear on incident records is a form of incident deflection
• Incident deflection aims to help users resolve issues before they submit an incident by providing related items like knowledge articles, catalog items, open and resolved incidents, and open and resolved problems
• Portal users will only see knowledge articles or catalog items in the Related search results. 

Contextual Search Properties

• Contextual search displays knowledge search results on forms and record producers to help users quickly resolve their issues
• By default,  a link to the knowledge article is added to the Additional comments (Customer visible) field. You can specify the field based on the table, either globally or locally. The local field for a table overrides the global default field value.
• To specify the global field: Knowledge > Admin > Properties > Other Knowledge Properties and specify the name of the field in the glide.knowman.attach.fields property
• To configure the properties of contextual search on a table, admins can go to the Contextual Search > Table configurations

Major Incidents

A major incident is an incident that results in a significant disruption to the business and demands a response beyond the routine incident management process.

Major Incident Management:

• Allows you to accelerate resolution of incidents with high business impact by managing all aspects of a major incident, including communication and collaboration processes

To leverage MIM functionality, a system admin must activate the Incident Management - Major Incident Management plugin (com.snc.incident.mim). This plugin may also active related plugins if they are not already active:

• Incident Communications Management (com.snc.iam)
• Incident Updates (com.snc.incident.updates)
• Task-Outage Relationship (com.snc.task_outage)
• Additional roles are installed with this plugin:
• Major_incident_manager
• Communications_manager
• Incident_manager (added responsibilities) 

Using the 'Assign to me' UI action for an incident record will follow the bellow logic:

• Assignment group filled in & you are part of the group - record is assigned to you
• Assignment group is empty & you're a member of a single group - assignment group is filled in and the record is assigned to you
• Assignment group is empty & you’re a member of multiple groups, you're promted to select the assignment group. When you manually select the Assignment group, the record is assigned to you
• Assignment group field is filled in and you're NOT a member of the Assignment group, an error I displayed indicating the user must be part of the Assignment group and the Assigned to field remains empty

Support Group --> Assignment Group

• Auto-populate the assignment group field based on the support group available for the respective CI. If the CI does not have a support group, then the field gets populated with the support group available for the service offering.
• The business rule Populate Assignment Group based on CI/SO triggers the functionality when an incident, problem or change request is created or updated and when the Assignment group and the Assigned to field is empty
• Assignment group can be overridden manually by a user. If there is not a Support group defined on the CI or Service offering record, the assignment group field will remain blank on the change request as well.
• Create a new property to configure which CI field populated the Assignment Group field named com.snc.incident.ci_assignment_group.field_name or com.snc..incident.service_offering_assignment_group.field_name to define the service offering field 

Group Filters

• Filter options to show only appropriate choices
• Leverage the group Type field and reference qualifiers to restrict assignment options to only include appropriate groups. Group types in the base instance include catalog, itil, and survey. A group type may be assigned to several group types
• Once group types are assigned, use Dictionary Overrides to specify reference qualifiers on the assignment group field for each task type:

• Incident: javascript:GetGroupFilter('incident')
• Change: javascript:GetGroupFilter('change')
• Request: javascript:GetGroupFilter('request')

SLA flow

• SLA Flows use percentages to time Breach Warning and Breach Notice emails rather than actual time. This allows a single, generic SLA workflow to work in most instances.

State Model

As of San Diego, the State and Incident State fields are automatically kept in sync, but it is still recommended to always use State [state] rather than Incident State [incident_state]. This is especially useful for reporting across multiple types of tasks, since State is available at the task level.

As a best practice, refer to states in code using the constants rather than values.

On Hold:

• When the state field is set to On Hold, a UI policy makes the On Hold reason field visible on the form. Options for On Hold reason include:
• Awaiting caller
• Awaiting change
• Awaiting problem
• Awaiting Vendor

Incident: Script Includes

• Script includes with SNC in the name are meant to be read-only. This ensures that the SNC script includes are updated during upgrades
• To override a function defined in an "SNC" Script include, copy that function to the paired version of the script include that does not contain SNC. Paste and customize the function there.

Notifications: Outbound Mail

• The intent of the Watch list is to copy people on notifications sent to the caller. The intent of the Work notes list is to copy people on notifications sent to the Assignee or other internal recipients
• Many baseline notifications include only a subject line
• The incident closed notification will trigger anytime an incident is updated while the state is closed

TIPS:

• Go for under-notification vs. over-notification
• Guide and advise customers on what notifications they should be using
• Be aware if marketing and communications needs to approve the working and format

Mail Scripts

• Email scripts allow for business rule-like scripting within an outbound email message

Communication via Email Client

• The email client is activated with the Email Client plugin (com.glide.email_client), which is active by default on the Now Platform. The email client is enabled by default on the incident and change tables
• To enable the email client for another table, add the email_client dictionary attribute on the table's collection record

Automating System Responses to Inbound Email

You can define system responses to inbound emails in two ways: 

1. Create an inbound email flow in Flow Designer

2. Script an inbound email action

With the inbound email trigger in Flow Designer, you can create flows that define the automated processes that your instance takes when it receives an email

• Inbound email flows take priority over inbound email actions.
• If you create flows with inbound email triggers, emails are first processed by the inbound email triggers before they are processes by inbound email actions

Close Incident Tasks

• Enable system property - com.snc.incident.incident_task.closure to close open incident tasks when an incident is closed or cancelled.

Creating Knowledge from an Incident

• Within the Knowledge Management Advanced and the KCS Integration for Incident Management plugins, users are able to create a knowledge article directly from the (resolved) incident record

Incident Closure Timeframe

• Default: 7 days after resolution or updated date
• Enable auto-close of incidents based on the resolution date of the incident instead of the last updated date. This property is set to true only for new customers. Existing customers must manually set the property to true

Surveys

Users with the survey_admin role can create and maintain surveys and configure how they are distributed and published. Survey administration includes:

• Create, customize, and publish surveys
• Write and maintain survey questions
• Define trigger conditions for when surveys are sent to users, such as when an incident closes
• Maintain surveys and survey questions as the organization's needs change

Trigger conditions specify when to send a particular survey and the person(s) to send it to.

Trigger conditions are ideal for sending transactional surveys. Transactional surveys generally measure satisfaction with a recent experience, such as closing an incident or purchasing an item.

Survey Operations Workspace

• A configurable workspace that provides a unified experience for multiple IT Service Management workflows.
• To access this workspace, users must be assigned the sow_user [sn_sow.sow_user] role
• Users can access and review incidents, catalog tasks, requests, problems, and other tasks, and take any appropriate action directly from the workspace 

Incident Reporting

• The incident overview page provides an overview of the current state of the incident management process. The ITIL Overview homepage also includes many reports to drive the process 

VI. Problem Management

Problem management interacts with other ITIL processes in many ways:

• Resolve a series of incidents related to the same issue by permanently solving an issue or communicating a workaround
• Create a known error article for an existing problem which has yet to be resolved
• Proactively monitor Cis, services, and service offerings to identify recurring issues and trends
• Create a change request to fix issue with a CI or list of Cis
• Problems may be the result of a release, and may also provide insight into release planning

Problems move through a basic process that includes 3 stages:

1. Detection and logging

2. Investigation and diagnosis

3. Resolution and closure

Avenues for Initiating Problem Investigation

• You can detect a problem either proactively or reactively
• Proactive problem detection: identify problems or issues that could result in future incidents. This can be done by analyzing reporting trends, such as the health of your configuration management database, or by automated system notifications
• Reactive problem detction: one or more incidents have occurred, prompting you to explore the underlying cause of the issue. These issues may be resolved, and the problem investigation is primarily meant to understand the underlying cause and prevent the incident from recurring. In other cases, the incident cannot be resolved without a deeper dive into the root cause and the application of a workaround or permanent fix
• Problems can also be created from third party integrations

Problem Form

Problem has several form views.

Common ones:

• Default view (agents)
• Mobile
• Workspace

Categorization: Approaches to configuring categories

You can approach categorization in the following ways:

• Re-use Existing Categories: customers typically use the same categories for incident and problem
• Define New Categories: if a problem requires a different set of categories, you can use the out of box categories or define your own
• Drive Categorization by CI: if you have a robust CMDB, you can drive categorization based on the CI class. This would require additional configuration and scripting

Problem Priority

• Priority values based on impact and urgency may be updated in the Priority Data Lookups table. No scripting is required to calculate values

Creating a problem from an incident record

• If there is not an existing problem that the agent can associate the incident to, they may create a new problem by selecting the Create Problem UI action.
• This UI action creates a problem record and copies values from the incident to the newly-created problem record. It also updates the incident record to add a reference to the related problem and sets the State to On Hold and On Hold reason to Awaiting Problem.
• To add or remove fields copied from the incident to the problem: Problem > Admin > Problem Properties and edit the com.snc.problem.create_from_incident.attributes property.
• Manage the ability to copy attachments from an incident to the problem with the Copy attachments from the incident (com.snc.problem.create_from_incident.copy_attachments) property

Service desk agents and support groups (users with itil role) have limited access within the Problem application. They can create/update problems and problem tasks and add related records. They cannot move problems and problem tasks through their lifecycle.

Roles for groups and users working in the problem application:

• Problem_coordinator: responsible for working on problems and problem tasks. They can also communicate fixes, workarounds, and create known error articles.
• Problem_task_analyst: Responsible for working on problem tasks only. This should be assigned to support groups that are aiding in an investigation.
• The assigned to field on the Problem record is restricted to users with a problem role, but the Assignment Group field is not. If a group without any problem users is selected, the Assigned to field will not be able to be populated.

Support Group --> Assignment Group

• Auto populate the Assignment group field based on the Support Group available for the respective configuration item (CI). If the CI does not have a support group, then the field gets populated with the support group available for service offerings.
• The business rule Populate Assignment Group based on CI/SO triggers the functionality when an incident, problem, or change request is created or updated and when the Assignment group and the Assigned to field is empty
• To configure which CI field populates the Assignment group field, customers must create a new property, named com.snc.problem.ci_assignment_group.field_name or com.snc.problem.service_offering_assignment_group.field_name to define the service offering field. 

State: Problem

• Use State rather than Problem State [problem_state]. This is useful for reporting across multiple types of tasks
• To impose prereqs or limits for moving from one state to another, incorporate new logic in the ProblemStateUtils script include.
• As a best practice, refer to states in code using the constants rather than values
• Determine which problem role can re-analyze problem records through the Problem Management properties  (Problem > Admin > Problem Properties)

State: Problem task

To impose prerequisites or limits for moving from one state to another, incorporate new logic in the ProblemTaskStateUtils script include

Determine if:

• A problem task can be re-assessed by Problem Coordinators
• A problem task can be re-assessed when the associated problem is closed
• Through the problem management properties (problem > admin > problem properties)

Problem tasks cannot be canceled at New state, they can only be deleted by an Admin if they have been created unnecessarily.

Automatically Move to the Assess State

• Problem records and problem task records in the New state auto move to Assess when the required values (Fields) are filled in
• When a problem record that is in the New state is saved or updated, the Update Problem State to Assess business rule checks if the fields in the Assess Dialog Form View dialog are filled. If all the fields are populated, the problem record is auto moved to the Assess state
• When a problem task record that is in the New state is saved or updated, the Update Problem Task State to Assess business rule checks if all the fields in the PTASK Assess Dialog View dialog are filled and will move the PTASK to Assess if so
• By default, state and assigned to are required. To add or edit the required values: System UI > Form Sections and open Assess Dialog Form View or PTASK Assess Dialog View respectively. From there, open the Form section and navigate to the Section Elements related list.

Problem Tasks

• The smallest unit of work that you should perform to complete a problem
• Assign investigation tasks while retaining ownership of the overall problem
• Two types of problem tasks can be assigned: 1. Root cause analysis 2. General
• Appear in Service Desk > My work for assignees 

Communicate Workaround

Communicate Workaround UI action may be used to copy the problem workaround to related incidents

By default, the workaround gets copied to the Work notes of any active incident related to the problem record.

Communicate Workaround UI Action calls 2 scripts:

1. Copy Problem workaround to work notes: workaround is copied to work notes for all incidents where state = new, in progress OR on hold

2. Copy Problem workaround to Inc comments: workaround is copied to additional comments for all resolved incidents where resolution code = known error

To change the default behavior or to format the workaround text, navigate to System Policy  > Events > script actions

Communicate Fix

• Copies fix notes field to the Active stream of associated incidents
• By default the fix notes get copied to incidents that are New, On Hold, or In Progress. To change the default behavior or to format the fix text open the Copy Prb fix to Inc work notes script action by navigating to System Policy > Events > Script Actions

Create known error article

• With the Problem Management Best Practice -- Madrid and Problem Management Best Practice -- Madrid Knowledge Integration plugins, users can create a knowledge article using the Known Error template by clicking the Create Known Error article from the Related Links section of the problem record. 

Create a Change Request from a Problem

• If a fix or workaround requires a change to a CI, you can create a change directly from the problem. Te create normal change and create emergency change ui actions create a new change record and copy values from the problem record. The problem record is updated with the reference to the newly created change record.
• Edit the UI actions to add additional fields, or to remove an existing field, to be copied to the new changed record by navigating to System UI > UI Actions

Reporting

• The Problem Overview page provides an overview of the current state of the problem management process

Metrics, Database Views, and Reports

Unlike the incident management process, the intention with problem is not to close down the record as quickly as possible.

The goal is to permanently fix the error, no matter how long that may take, therefore care should be taken not to introduce KPIs and metrics that track resolution timeframes as this will drive the wrong kind of behavior from the process

Recommended metrics include:

• Percentage of problems responded to within target time
• Number of new problems per week
• Percentage of incidents resolved by problems

VII. Change and Release Management 

Change Management interacts with other ITIL processes in many ways.

For example:

• Provides capability for standard/preapproved changes to be recorded using the service catalog
• Related to incidents caused by or resolved by changes
• Relates to problems caused by or solved by changes
• Updates configuration item, service, and/or service offering record(s) after implementing changes (i.e. updates server information)
• Updates knowledge article(s) after implementing changes
• Encompasses the build, test, and execution activities within Release Management

Multimodal Change

• Allow customers to easily document and process any change without the overhead of traditional change types and change request lifecycle.
• State transitions allow customers to define the states and condition-based transitions for each change model, eliminating the documentation and click requirements for rapid release, lower environments, and low risk changes
• No role or user has the ability to update the change type or model on an existing record, or the ability to delete a standard change proposal
• The ability to read or write to a change model record is defined on the change model record via role based access controls
• The ability to create a change request with a given model is defined on the change model record via user criteria records

Change Process Lifecycle

• Creation and Scope: create the change request and document all relevant details. Or, locate one that was assigned to you/your group.
• Approval: if necessary, the change is reviewed and can be approved or rejected
• Implementation: one or more change tasks may be created to guide through the implementation
• Closure: Complete the Post Implementation Review if required. The change may close automatically, following completion of the final change task or PIR process. Or, you may need to automatically close the change record

Create a Change Request

• Manual creation: from the change application
• Incident management: UI actions on the incident form to create normal, emergency and standard changes. Incident smust be active and not already associated with a change request. The UI actions copy a number of fields from the incident record to the new change request and update the change request field on the incident to note the relationship between the incident and the change. The related records section on the incident form also includes a Caused by Change field to allow users to identify incidents caused by changes
• Problem Management: UI Actions are defined to Create Normal and Emergency Change on problem forms. To use these UI Actions, problems must be active and not already associated with a change request. UI Actions copy a number of fields from the problem record to the new change and update the change request field on the problem to note the relationship between the problem and change.
• Configuration Management: proposed changes may be associated with each affected CI for a change. Once the change is implemented, the proposed change is applied to the CI
• Service Catalog: Standard changes may be requested via the Standard Change catalog

Multimodal Change (change models)

Allows change managers to tailor change activities and flows for specific use cases in an easy and convenient way

An individual change model will have the following defined:

• State models
• State transitions
• State transition conditions

Change Model Records

Defines details like if the model should be the default change model, what the change model is used for, whether it appears in the Create New landing page, and which state the implementation activities occur.

This also impacts when the Apply Proposed Changes UI action button appears on a change request as the canImplement() function checks for this state

ACL's at the table level still apply, however, change managers can define granular read/write access of a change model through role based access control (RABC)

The ability for a user to select and create a change request with a given model can be defined through ser criteria when Advanced Security = true

• Read roles = roles able to read the change model definition record
• Write roles = roles able to modify the change model definition record
• Available for = users that match the user criteria can create change requests with this change model
• Can write = users that match the user criteria and the write roles are able to modify the change model definition record
• Users with the admin or change_manager role may read and write any change model record

Change Model States (in order 1-8)

1. New

2. Assess

3. Authorize

4. Scheduled

5. Implement

6. Review

7. Closed

8. Canceled

State Transitions

• Within each state defined in a model, there are state transitions. These transitions define which states a record can move from the given state.
• Automatic Transition column: if set to true the CHG will automatically move to this state if all conditions are met

Transition Conditions

• Define any state transition requirements through model state transition condition
• Transition condition example: validate the change request has been approved, is not on hold, or that a field or fields have a specific value, are not empty, etc
• Transition conditions do NOT replace UI policies or UI actions

Unauthorized Change Request

• Change managers can easily detect and respond to unauthorized change events based on their organizations specific unauthorized change policies.
• When an unauthorized change is detected, a change request is automatically created using the unauthorized change model and unauthorized = true
• When an unplanned CI activity occurs on Cis that are part of an application service, the change is captured to review the impact and for approval to requested. This activity is automatically identified, and an unauthorized, emergency change request is created. The CI field is automatically populated, along with the details of the change in the description field. The change request record is automatically assigned to Change Management and notifications are sent to the Change Management team and any defined owners or managing group of the CI

Change Request Form

During an implementation, review each field on the Change Request form and how it is leveraged in the change process

Planning: information provided in this section of the form is to aid reviewers and implementers. No process logic is driven off of values in these fields

Schedule:

• Planned start date and Planned end date are used in conflict detection and risk assessment. Planned start date must be before Planned end date
• Actual start date and Actual end date are set by functions in the Change Request State Model script includes. When the state changes to implement, the actual start date is set to the current date/time. When the state changes to Review, the Actual end date is populated
• Unauthorized: may be automatically set by ServiceNow when unplanned activity is detected or it can be manually set.
• CAB required: does not drive application logic.
• CAB date: set when the change is added to the CAB meeting agenda
• CAB Delegate: indicates the user who will represent the change in an upcoming CAB meeting. This user is included in the notification about the upcoming CAB meeting.
• CAB recommendation is informational only.

Conflicts: The Check Conflicts UI action runs the Conflict detection logic manually and populated the results in the embedded list view

Note: CAB-related fields are hidden from the form view through a UI policy when viewing standard change

Change Group --> Assignment Group

• Automatically populate the Assignment group field based on the change group available for the respective configuration item(CI).
• If the CI does not have a change group, then the field gets populated with the change group available for the service offering.
• Business rule 'Populate Assignment Group Based on CI/SO' triggers the functionality when an incident, problem, or change request is created or updated and when the Assignment group and the Assigned to field is empty.
• The assignment group can be overridden manually by a user
• To configure which CI field populated the Assignment group field, customers must create new properties, named com.snc.change_request.ci_assignment_group.field_name or com.snc.change_request.service_offering_assignment_group.field_name property for the service offering field 

Blackout and Maintenance Schedules

• Blackout windows specify times during which normal change activity should not be scheduled.
• Maintenance windows specify times during which change requests should be scheduled.
• These schedules can be applied to individual Cis, CI classes, or dynamic CI groups. 

Conflict Detection

• Conflict detection identifies potential scheduling conflicts for a change request based on the configuration items (Cis), planned start date, and the planned end date in scope for the change. If a scheduling conflict exists, conflict detection also checks any related blackout or maintenance schedules and other active change requests to determine the scheduling conflict.
• Conflict detection is triggered manually through the Detect Conflict UI action and upon insert and update of the change record. It may also run as a scheduled job based on the lead time to Planned Start.

Scheduled Assistant

Aims to help change initiators remove conflicts on their change request by suggesting an alternative target deployment window

Change Risk Conditions:

• Risk is assessed based on the Risk Conditions defined in Change > Administration > Risk Conditions. Add or modify risk conditions according to customer requirements
• Risk calculator requires the user to click the Calculate Risk UI action. However, the glide.ui.risk_calculate_rule property may be set to calculate risk on insert and update of changes

Change Management - Risk Assessment:

• This plugin adds an additional factor to use when calculating risk.
• Risk assessment surveys may be defined based on the type of change or any other conditions.
• On the Change Request form, users may click Risk Assessment and complete the survey questions. Responses are scored and the overall score is matched against thresholds to calculate risk.

Configuring Risk Conditions:

• Risk conditions may set the Risk and Impact fields
• When the Calculate Risk UI action is triggered, risk conditions are evaluated in order, and the highest risk value is returned.

Configuring Risk Assessments:

• Plugin required - Change Management - Risk Assessment (com.snc.change.risk_assessment)
• Assessment uses a weighted score approach for each question. The composite weighted score derived from the end user's answers is used to calculate risk. This is based on the thresholds associated with the risk assessment.

Risk Assessment Designer:

• Use to create and edit metric types, use different metric types for different risks, select multiple respondents for a risk assessment, as well as change scoring parameters

Change approval policies

• A change approval policy defines inputs and outputs
• A decision is an outcome of the policy, it applies when the conditions containe within it matches the Policy Input. Use a simple condition builder to apply the logic
• The Decision record also references an Answer (Change Approval Definition) which specifies a related approval action
• A change approval policy is a course of action that can be applied to a change request and defines the approvals that should be applied to a change request. It contains the inputs and decisions which dictate the policy

Policy Inputs

• Variable sources that you can use while evaluating a decision to determine the approval action
• The policy input record creates reference to some form of information which provides the variable sources to evaluate within a decision
• You can create multiple policy inputs to evaluate the decision created

Policy Decisions

• An approval policy can contain multiple decisions allowing a single policy to handle every approval required for a change model (type).
• When a decision condition matches, the policy inputs for the approval definition are evaluated, and the associated approval actions are triggered
• If one or more decisions match, all the related approval definitions are evaluated. Change approval polices are based on Decision tables, which guide complex decision making that depends on multiple factors.
• Decisions allow authorized users to quickly define approval process using conditions. Requesting approvals according to the state of a Change Request no longer requires script or unique sub flows

Change approval definition

Approval definitions define a set of criteria that are evaluated automatically before the policy is marked as approved.

The approval definition determines:

• If the approval is user or group based
• If the approver source is an approval definition or change request
• If a response to the approval is required
• If there are any wait for conditions, which means how many usrs from the group must approve; first response, all responses, or a percentage of users

Flow Actions

Automate a task with a sequence of related steps

Actions separate complexity from the Flow Designer environment, enabling flow designers to add actions to multiple flows with minimal configuration

Each flow action will have:

• Inputs (data variables required for the action)
• Action steps (reusable operations)
• Outputs (resulting data variables)

Change Advisory Boards (CABs)

• Scoped application
• Multiple CABs supported
• Conditions define appropriate CAB per change
• Setup Checklist: 1. CAB Definition 2. Schedule entries
• Enabled by default

CAB Workbench

• Leverages Service Portal functionality to provide an interface for managing CAB meetings. The change manager and delegates have control to run the meeting and take notes. Participants use the CAB Workbench interface to follow along and track progress.

Change Tasks

May be created manually or automatically when changes enter the Implement phase, and triggers the Change - Implementation subflow

Change tasks that are change specific should be created manually before entering the Assess or authoritze states, so the specific change tasks involved may be incorporated into the review process

Automatically generated tasks per change model include:

• Implement and Post implementation testing for Emergency, Normal and Standard changes 

Post-Implementation Review (PIR)

• A change task for PIR is automatically created when an unauthorized, emergency change request record moves to a state of Review. This change task is assigned to the Change Management group with the Short Description of  "Post Implementation Review". The assigned members who receive the notification can review and change the close task.

Change Overview

• This dashboard located at Change > overview, includes a number of widgets and reports to help users manage the change process

Metrics and database views

• Metrics track the length of time changes stay in each approval state
• Database views exist to facilitate reporting if and when SLAs are associated with change or the incident time_worked field is leveraged. 

Release Management Concepts

• Product: represents the hardware or software for which releases will be built. A product can be linked with a Business Service in the CMDB to link it with other ITIL processes
• Releases: represents a planned release for a product. The content of a release is defined by the features (and associated change requests) that it implements
• Release Phases: represents the planned phases that a release will have, which are used to group the tasks required to carry out the release
• Features: represents the individual changes being made to the product. A feature may be associated with a CI or with a change request, and to a parent release
• Release tasks: represents any of the tasks required to implement a feature of a product
• The release management application handles releases using the task record system
• Can be effectively used to coordinate releases as a vehicle for planning released, composed of individual features. Once a release is finalized, a change item can be generated (using a custom-built UI Action), allowing the implementation and deployment of a release to be handled within the change management process

 Release Phases and Process Integrations

• Release Planning: defines the specific plans for the release that are agreeable to all stakeholder and supports the fulfillment of the involved changes of the release. Plans are updated and refined as necessary throughout the lifecycle of the release.
• Build and Test: these activities start with the authorization to build the release and end with change management authorization for the release package to be checked into the DML through the Configuration Management process. During this phase, the release may cycle through multiple iterations of building, testing, and authorization (via sprints) until the package is ready for deployment and satisfies change governance
• Deployment: begin with the authorization to deploy the release package to one or more target environments and ends with a handover to service operations and early life support.
• Review and close: the release review and closure marks the conclusion of the Release Management process. This phase includes a formal review of the deployment activities from start to finish, including the final status of the release record, which is also reflected in the associated change records

‍