mtcoffee

A ServiceNow and DevOps enthusiast. I use this blog to share ideas and learn from others.

  • Custom Social Profile Link

ServiceNow Automatically set Assignment Group

1 minute read

This is a useful tidbit for auto populating assignment groups. ServiceNow does have a few features that make it possible to auto assign groups based on criteria such as:

  • Assignment Lookup Rules
  • Data lookup definitions

However, sometimes a simple client script can offer less overhead. In this case I had the following requirements.

  • When a requester picks a group it will auto set the assignment group to the Configuration Item approver group
  • The requester can accept this or choose to override it
  • If a group is not found on the CI, a pop up will alert them to select it manually

To accomplish this the client script was as follows:

Name : Populate Assignment Group Type : onChange Field Name : cmdb_ci (Configuration Item)

Set that on your table (incident/change etc) and your all set!

Why not Assignment Rule?

I was asked, why not create an assignment rule, after all its built into the product. For example a simple rule under System Policy -> Assignment, defined using this script snippet will work.

Sample snippet:

However it is server side and does not set until after the user saves the record. This would be ideal if you wanted to “Hard enforce” that the assignment group must be set by the CI, however if your requirement is to allow the user to override then a client script is the preferred route.

Leave a comment

You may also enjoy, kubernetes servicenow discovery - the better way using cno for visibility.

3 minute read

Summary Recently I put together a walk through of Kubernetes ServiceNow Discovery using traditional Discovery Schedules. This works but is not a great method...

GitOps with ArgoCD on K3s

2 minute read

Summary For my ServiceNow readers, this post will not touch on ServiceNow but if you like Kubernetes and are interested in Continuous Deployment, read on! Fi...

Kubernetes Demystified and ServiceNow Discovery part1

Summary What is Kubernetes exactly? If you’re not in the DevOps space it can sound like voodoo. Let’s start with a little history.

Kubernetes Demystified and ServiceNow Discovery part2

Now that we have a Kubernetes Cluster to Discover, lets dive into ServiceNow Kubernetes Discovery. This example assumes you have a MID Server that can conne...

Advance Your Career

ServiceNow CIS-ITSM Exam Study Guide

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

  • Relevant Links - easily access the course, blueprint, and webassessor
  • Tables and Roles - all ITSM tables and roles listed 
  • Practice Resources - Links to resources I used to study for the exam
  • 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 

CMDB & CSDM

  • Ecmdb_admin
  • App_service_admin
  • System (discovery)

Service Request Platform roles - Fulfillment

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

Service Request Platform Roles

  • Catalog_builder_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

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

*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:

  • Workstations
  • Out-of-band devices
  • Network gear
  • Communication devices
  • Accessories
  • Computer peripherals

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:

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

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

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

 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. 

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

  • Can edit catalog records, manage categories, assign editors
  • Can create, modify and publish items within their catalog
  • 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)

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

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.

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
  • Mobile (Mobile Classic)
  • 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
  • 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:
  • 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 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.

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

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 

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:

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

3. Authorize

4. Scheduled

5. Implement

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

  • 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

populate assignment group based on ci/so

GlideRecord Cheat Sheet

populate assignment group based on ci/so

GlideForm (g_form) Cheat Sheet

populate assignment group based on ci/so

User Object Cheat Sheet

populate assignment group based on ci/so

ServiceNow Version Timeline

populate assignment group based on ci/so

How To Script In Flow Designer

populate assignment group based on ci/so

Š Snowycode 2022. All rights reserved.

ServiceNow Community servicenow community

developer

  • ServiceNow Community
  • IT Service Management
  • How to Set the Incident Assignment Logic based on ...
  • Subscribe to RSS Feed
  • Mark Question as New
  • Mark Question as Read
  • Float this Question for Current User
  • Printer Friendly Page

How to Set the Incident Assignment Logic based on the CI field groups

nikhitha24

  • Mark as New
  • Report Inappropriate Content

‎07-30-2023 05:11 AM

Solved! Go to Solution.

sushantmalsure

‎07-30-2023 11:07 AM

View solution in original post

  • All forum topics
  • Previous Question
  • Next Question

‎07-30-2023 05:29 AM

‎07-30-2023 09:51 AM

‎07-31-2023 12:12 AM

  • Restrict Access to edit on catalog task if member/role is from XYZ assignment group in Virtual Agent forum 11 hours ago
  • Need to populate group members in worknotes in ITSM forum yesterday
  • State from New to In Progress automatically changes when the incident is assigned to someone, can it in ITSM forum yesterday
  • Exporting all assignment groups and associated members in ITSM forum Tuesday
  • Breakdown by Assignment Group Manager and Age in Performance Analytics forum Monday

populate assignment group based on ci/so

GlideFast consulting

  • About GlideFast
  • Advisory Services
  • Application Development
  • Cloud Hosting
  • Design Services
  • Implementations
  • Integrations
  • Managed Support Services
  • Remote Services
  • Service Portal
  • AgileGenius
  • Case Studies
  • Content from our Experts
  • GlideFast University
  • GlideHits Designed Portals
  • ServiceNow Guides

Incident Assignment Group from CI in ServiceNow

By: GlideFast

With Colin Christie

In this article, we will give an example of an Incident Assignment Group from CI in ServiceNow. Let's say we’ve sent an incident to ServiceNow. We will take a look at how our flow will run.

Incident to Reboot a Windows Server

Our new incident just came in, and it's an incident to reboot a Windows server; it has a configuration item populated which is good. We can also see that the assignment group of the incident got set to the Windows Server Support group. Shown here is the support groupset to Windows Server Support on that CI (reference video at 0:40). Here's an example of how our flow was able to pull the support group directly off a CI and set it on an incident. This is a big benefit for anyone who has populated their CMDB and gone a step further to make sure that they have the proper data populated on their CIs to make sure that everything is going to be set up to go to the right support team.

Incident For Database That Has Gone Down

For this example, we'll show another incident coming to ServiceNow for a database that has gone down. We also have a configuration item populated here, and we can see that the assignment group is set to the Database assignment group. Shown here is the support group set to Database on that CI (reference video at 1:50). Now we’ve demonstrated two different support groups going to two different incidents, using the single flow that we've set up. people might think this could be done very easily with assignment rules. This is true; however, assignment rules depend on users opening tickets properly. For example, say the user who opened this ticket accidentally picked hardware as the category. If you have assignment rules that depend on the category being set properly, then the assignment group on an incident like this would highly depend on the category being set properly.

Let’s say that same incident was opened with a category instead of the category. Under different circumstances, that might go to a different assignment group and cause a delay in this incident being addressed; however, since we can utilize the support group directly from the configuration item, we can set the proper assignment group even if the user picks the wrong category for the incident. By utilizing Flow Designer’s low code solutions, we can very easily set up a rule in a few minutes that will help route incidents to the proper teams and get them resolved and addressed more quickly.

Automation Through Flow Designer

Let's see how our flow will handle new incidents that come into ServiceNow. We've just received a new incident for a Windows server that needs to be rebooted. The configuration item was populated, and as we can see in the CMDB, the support group is set to the Windows Server Support team — that's exactly what we can see on the assignment group for the incident. Now let's see what will happen if another kind of incident comes in. we've got a new incident for a database that has gone down, and the configuration item is also populated. Looking in the CMDB, we can see that the support group is populated as the Database support group, and again that's what we see for the assignment group on the incident. This is showing how the same flow can set two different assignment groups on two different incidents by utilizing that dynamic step we have in our flow that is pulling from the support group on the configuration item.

Lastly, let's see if that same incident came in for the Database server, but say the user who submitted accidentally picked the Hardware category. Now if we were relying on the more static type of rules that is parsing category to determine the assignment group, this incident may have been sent to the wrong group, which can slow down the amount of time it will take to resolve the issue. Relying on a well-built CMDB and automation through Flow Designer allows us to handle routing incidents correctly to the proper team and get them resolved more quickly. That's going to help us keep the business running smoothly.

Did you find this Incident Assignment Group from CI article in ServiceNow helpful? Are you ready to start your journey with ServiceNow? If you want to find out more information about GlideFast Consulting and our ServiceNow implementation services, you can reach out to us here .

About GlideFast Consulting

GlideFast is a ServiceNow Elite Partner and professional services firm that provides tailored solutions and professional services for ServiceNow implementations, integrations, managed support services, application development, and training. Reach out to our team here .

Related Posts

populate assignment group based on ci/so

Inbound Email Actions in ServiceNow

With Omari Warren

populate assignment group based on ci/so

ITOM: Extending Discovery/Service Mapping Patterns

With Chris Tessier

populate assignment group based on ci/so

Event Rule With CI Binding In ServiceNow

populate assignment group based on ci/so

ServiceNow: Building Powerful Workflows by Tim Woodruff, Ashish Rudra Srivastava, Martin Wood

Get full access to ServiceNow: Building Powerful Workflows and 60K+ other titles, with a free 10-day trial of O'Reilly.

There are also live events, courses curated by job role, and more.

Setting the Assignment group with Assignment Rules

Assignment Rules are a simpler alternative to Data Lookup. While Data Lookup is very powerful, allowing you to set any field, it does involve a quite a bit of configuration, including creating a new table.

In contrast, an Assignment Rule uses the simpler condition builder to specify when it should run. If it matches, then it'll either populate the Assigned to and Assignment group fields with a hardcoded value, or you can use a script. We have got the group we want to use in a property, so this option is perfect. Follow these steps:

  • Name : Assign to External Team
  • Table : Maintenance [x_hotel_maintenance] ...

Get ServiceNow: Building Powerful Workflows now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Don’t leave empty-handed

Get Mark Richards’s Software Architecture Patterns ebook to better understand how to design components—and how they should interact.

It’s yours, free.

Cover of Software Architecture Patterns

Check it out now on O’Reilly

Dive in for free with a 10-day trial of the O’Reilly learning platform—then explore all the other resources our members count on to build skills and solve problems every day.

populate assignment group based on ci/so

404 Not found

ExamTopics Logo

ServiceNow CIS-ITSM Exam Actual Questions (P. 18)

The questions for cis-itsm were last updated on feb. 19, 2024..

  • Viewing page 18 out of 48 pages.
  • Viewing questions 69-72 out of 196 questions

What optional Incident table is extended from the Task table?

  • A. Child Incident [incident_child]
  • B. Major Incident [major_incident]
  • C. Incident Task [incident task]
  • D. Parent Incident [incident_parent]

Correct Answer: C 🗳️

Category and Subcategory values can be set manually on the Incident form. What are disadvantages of this approach? (Choose two.)

  • A. Too many options may confuse users and increase mis-categorization
  • B. Choices have no additional metadata to drive process
  • C. It is difficult to implement
  • D. It is not part of the baseline instance

Correct Answer: AB 🗳️

When using the baseline business rule, Populate Assignment Group based on CI/SO, what behavior would you expect on an Incident form? (Choose two.)

  • A. If selected CI does not have an Owner group, write the Support group from the Service Offering to the Assignment group field
  • B. If selected CI has a Support group, write that group to the Assignment group field
  • C. If selected CI has an Owner group, write that group to the Assignment group field
  • D. If selected CI does not have a Support group, write the Support group from the Service Offering to the Assignment group field

Correct Answer: BD 🗳️

On an incident record, where are the fields that appear on the caller lookup select box defined?

  • A. The Caller lookup field on the [user] table
  • B. The ref_ac_column attribute from the dictionary entry
  • C. The ref_contributions attribute on the caller lookup form
  • D. The form design of the caller lookup form

Correct Answer: A 🗳️

Log in to ExamTopics

Loading discussion, report comment, contributor access, want to unlock features that will help you study for cis-itsm.

By buying Contributor Access for yourself, you will gain the following features:

  • 31 days 1.45 / day
  • Full Exam Access
  • Inline Discussions
  • No Captcha / Robot Checks
  • Support ExamTopics
  • 365 days 0.18 / day

Certified Implementation Specialist - IT Service Management v1.0

Please signup or login to view the entire exam for free.

In what table are Change records stored?

  • A. Change [change_task]
  • B. Change Request [rfc]
  • C. Change Request [change_request]
  • D. Change [change]
  • E. Change [task_change]

Risk is configured by default, to calculate Risk = High for a change that is scheduled with only 3 days lead time. Your customer’s change policy requires that changes be requested with 5 days lead time. How would you satisfy this requirement?

  • A. Update the Risk Property for Insufficient lead time
  • B. Update the Risk Assessment Matrix for Insufficient lead time
  • C. Update the Calculate Risk UI Action
  • D. Update the Risk Matrix for insufficient lead time
  • E. Update the Risk Condition for Insufficient lead time

How are Releases related to Projects?

  • A. Project tasks and Release tasks are interchangeable
  • B. Projects can be part of one or more releases
  • C. Project features are components of a release
  • D. Projects need to be completed before releases can be defined
  • E. Projects are used to do root cause analysis for releases

What baseline Change Flows support the baseline Normal Change model?

  • A. Change - Normal - Assess, Change - Normal - Authorize, Change - Normal - Implement Change - Implementation tasks
  • B. Change - Normal - New, Change - Normal - Review, Change - Normal - Close, Change - Implementation tasks
  • C. Change - Normal - New, Change - Normal - Assess, Change - Normal - Implement, Change - Implementation tasks
  • D. Change - Normal - Assess, Change - Normal - Authorize, Change - Normal - Close, Change - Implementation tasks

Which of the following Change Task Types are available by default? (Choose three.)

  • A. Planning
  • D. Deployment
  • E. Verification

Answer : ABC

What is the Business Rule that triggers automatic group assignment on Incident, Problem or Change requests?

  • A. Populate Assignment Group based on CI/SO
  • B. Auto-populate ITSM Assignment Groups
  • C. ITSM Assignment Lookup Rule
  • D. Automatic Assignment for ITSM

In the CAB workbench, what are some ways the CAB manager can identify the Change requests to be added to a particular meeting agenda? (Choose two.)

  • A. Change requests meeting different conditions, like Risk level or Type
  • B. Change requests planned within a certain date range
  • C. Use any of the options on the Agenda Criteria Tab
  • D. Change requests for a certain Change Flow Definition

Answer : AC

A change user complains that with the new Preapproved tab, they have to search through many options to find the Reboot Windows Server change. Since they use this change several times per day, it is inconvenient. What should you suggest to make it easier for the change user?

  • A. Use the Pin feature
  • B. Make a Favorite
  • C. Use the keyword search
  • D. Drag the change tile to the Navigation pane

Roles control which users can perform which actions on a change record. What are actions, which cannot be performed by anyone, even an administrator? (Choose two.)

  • A. Update Change Type on an existing change record
  • B. Delete a Change record
  • C. Delete a Standard Change Template
  • D. Delete CAB Definition

Answer : BD

Question 10

In the baseline Change - Normal model how can Change Tasks be added? (Choose two.)

  • A. Automatically via the Change - Implementation subflow
  • B. Manually by the user during New, Assess, and Authorized states
  • C. Automatically depending on the category selected on the Change Request
  • D. Manually by the user during all states, except Closed or Canceled

Answer : AD

Question 11

In the baseline Change - Normal model, when the Change request goes to the Review state, what happens to the implementation and testing tasks, if they have not been closed.

  • A. They are automatically canceled
  • B. They are automatically closed
  • C. They are automatically assigned to the Change assignee and closed
  • D. An error displays, requiring that the Tasks be closed before moving to Review

Question 12

On the Unauthorized Change Properties module what can you configure? (Choose two.)

  • A. Enable/Disable creation of Unauthorized changes
  • B. Maximum number of unauthorized change records for a CI
  • C. Unauthorized Change Dashboard
  • D. CI classes to monitor

Answer : AB

Question 13

How do you describe the relationship between a Knowledge article and a Knowledge base category?

  • A. Articles can only be published to one category
  • B. Articles must be published to at least one category
  • C. Articles must be approved by the selected category owner
  • D. Articles can be published to a category and subcategory

Question 14

What are the different ways a user can provide feedback on a knowledge article? (Choose four.)

  • A. 10 Star scale
  • B. Comment on Article
  • C. Helpful?
  • D. Flag Article
  • E. 5 Star scale
  • F. Pin Article

Answer : BCDE

Question 15

When using the Knowledge - instant Retire workflow, how does the Valid to date enact a Knowledge article?

  • A. On Valid to date, article is automatically retired
  • B. On Valid to date, retire notification is sent to the Knowledge article author
  • C. On Valid to date, retire notification is sent to the Knowledge base owner
  • D. On Valid to date, the article is archived

Talk to us!

Have any questions or issues ? Please dont hesitate to contact us

[email protected]

IMAGES

  1. Learn Glide Ajax ServiceNow

    populate assignment group based on ci/so

  2. Populate Assignment group using before Business Rules explained in

    populate assignment group based on ci/so

  3. Incident Assignment Group from CI in ServiceNow

    populate assignment group based on ci/so

  4. Unlock more value of your ITSM processes with grou...

    populate assignment group based on ci/so

  5. Article

    populate assignment group based on ci/so

  6. Creating an Assignment Group

    populate assignment group based on ci/so

VIDEO

  1. database/ group by,having and case statements (28)

  2. PSA Assignment Group 6

  3. Highest populate group of refugees in each country #mapping #mapper #refugees

  4. Assignment Group BCD 1073

  5. Calculus Assignment Group 7 Section 2 (23/24)

  6. PROJECT ASSIGNMENT (GROUP 4)

COMMENTS

  1. Incident Assignment Group from CI

    In this ServiceNow Tutorial, Colin Christie gives an example of Incident Assignment Group from CI in ServiceNow.Define assignment rules to identify the right...

  2. ServiceNow Automatically set Assignment Group

    When a requester picks a group it will auto set the assignment group to the Configuration Item approver group; The requester can accept this or choose to override it; If a group is not found on the CI, a pop up will alert them to select it manually; Solution. To accomplish this the client script was as follows: Name: Populate Assignment Group ...

  3. ServiceNow CIS-ITSM Exam Study Guide

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

  4. How to auto populate "Assignment Group" field present on the RITM

    The requirement is to auto-populate the "Assignment Group" field present on the 'sc_req_item" table

  5. Populate an application service using the Dynamic CI Group method

    Skip to page content ...

  6. Solved: How to Set the Incident Assignment Logic based on

    Populate Reporting Entity based on assignment group on SC Task table in ITSM forum yesterday; Allow inbound action to update incidents for a group of inactive users in Incident Management forum yesterday; Override Hint information in Incident Change and Problem tickets in ITSM forum Tuesday

  7. How to auto populate an Assignment Group Based on Sub Category and Area

    You may start mapping out all the possible combinations and define a rule. Make use of a Rule group and set rule under it could help you here. Assignment I = Rule Group - (SubCategory A)..... under it are Rule Area 1, Rule Area 2 ..etch. Assignment II = Rule Group - (SubCategory B)..... under it are Rule Area 1, Rule Area 2 .. etch.

  8. Incident Assignment Group from CI in ServiceNow

    For this example, we'll show another incident coming to ServiceNow for a database that has gone down. We also have a configuration item populated here, and we can see that the assignment group is set to the Database assignment group. Shown here is the support group set to Database on that CI (reference video at 1:50).

  9. Configure group types for assignment groups

    Configure group types for assignment groups - Product Documentation: Tokyo - Now Support Portal. Use the Type field to define categories of groups. Once defined, you can use these categories to filter assignment groups based on the group type using a reference qualifier. For example, when selecting.

  10. Incident Assignment Group from CI in ServiceNow

    In this article, we will give an example of an Incident Assignment Group from CI in ServiceNow.

  11. Setting the Assignment group with Assignment Rules

    If it matches, then it'll either populate the Assigned to and Assignment group fields with a hardcoded value, or you can use a script. We have got the group we want to use in a property, so this option is perfect. Follow these steps: Navigate to System Policy > Rules > Assignment, and click on New. Use the following values, and Save.

  12. Exam CIS-ITSM topic 1 question 71 discussion

    Question #: 71. Topic #: 1. [All CIS-ITSM Questions] When using the baseline business rule, Populate Assignment Group based on CI/SO, what behavior would you expect on an Incident form? (Choose two.) A. If selected CI does not have an Owner group, write the Support group from the Service Offering to the Assignment group field. B.

  13. How to use CSDM to Improve Incident Management

    If we take an Incident example where "ServiceNow PROD is down" and have a proper CI selected to see how Service Offerings are filtered based on CI selection and how an Assignment group is populated based on the Support Group on the Service Offering. First, the CI is selected (1), but "ServiceNow PROD" doesn't have a Support Group (2 ...

  14. ITSM Module 3: Incident Management Flashcards

    Have the category (and sub‐category) populate based on the configuration item selected. How is the Assignment group field populated? 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 ...

  15. Auto Populate assignment group

    And it depends on you how you want to resolve the conflict. You can assume one of the primary assignment group and set it to at first index in assignment group field of operator record.So that every time by default this group will be set in new interaction form and user can change it to his requirement if he is not satisfy with it.

  16. Solved: How to auto-populate Assignment group, if the Conf

    In is an "On Change" client write we used where will auto-populate Assignment class when a CI will changed on an incurrence form. ... Kindly mark my answer as Correct and Helpful based on the Impact. Regards, Alok. 0 Helpfuls Share. ... So for each CI we outlined a support_group or whenever the CI is selected on an incident form its respective ...

  17. how to get auto-populate fields in servicenow

    If so you have a few possibilities: Since Caller is a reference field you can just put the fields on the form via form designer and make them read-only with a UI-Policy. On every Reference field you have a reference icon, you get a preview when you hover over that icon. You could use this functionality to display the additional fields.

  18. Exam CIS-ITSM topic 1 question 36 discussion

    A. Populate Assignment Group based on CI/SO B. Auto-populate ITSM Assignment Groups C. ITSM Assignment Lookup Rule D. Automatic Assignment for ITSM Show Suggested Answer Hide Answer. Suggested Answer: A 🗳️. by som_420 at Dec. 16, 2022, 8:59 a.m. ...

  19. Exam CIS-ITSM topic 1 question 172 discussion

    Question #: 172. Topic #: 1. [All CIS-ITSM Questions] Your customer wants Problem records to be assigned automatically to the Support group associated with the CI on the problem record. Which business rule already satisfies this requirement? A. Populate Assignment Group based on CI/SO.

  20. Assignment group is auto-populating the value, on new ...

    When creating a new record, the Assignment group was auto-populating to an incorrect value.

  21. CIS CSM and ITSM Exam preperation : r/servicenow

    Avenues for initiating problems, Priority, Problem Properties (com.snc.create_from_incident.attributes, etc.), Assignments (problem, problem tasks), business rules (like Populate Assignment Group based on CI/SO), script include, best practices( refer to states in code using constants rather than values, etc.), Communicate Workaround UI ...

  22. CIS-ITSM Exam

    A. Too many options may confuse users and increase mis-categorization. B. Choices have no additional metadata to drive process. C. It is difficult to implement. D. It is not part of the baseline instance. Reveal Solution Discussion 2. Question #71 Topic 1. When using the baseline business rule, Populate Assignment Group based on CI/SO, what ...

  23. ServiceNow CIS-ITSM Exam

    A. Populate Assignment Group based on CI/SO; B. Auto-populate ITSM Assignment Groups; C. ITSM Assignment Lookup Rule; D. Automatic Assignment for ITSM; Expose Correct Answer. Answer : A. Next Question. Question 7 In the CAB workbench, what are some ways the CAB manager can identify the Change requests to be added to a particular meeting agenda? ...