Search icon CANCEL
Arrow left icon
Explore Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Conferences
Free Learning
Arrow right icon
Arrow up icon
GO TO TOP
ServiceNow IT Operations Management

You're reading from   ServiceNow IT Operations Management Demystifying IT Operations Management

Arrow left icon
Product type Paperback
Published in Apr 2017
Publisher Packt
ISBN-13 9781785889080
Length 266 pages
Edition 1st Edition
Arrow right icon
Author (1):
Arrow left icon
Ajaykumar Guggilla Ajaykumar Guggilla
Author Profile Icon Ajaykumar Guggilla
Ajaykumar Guggilla
Arrow right icon
View More author details
Toc

Understanding ServiceNow IT Operations Management components

Now that we have covered what ITOM is about and focused on ServiceNow ITOM capabilities, let's deep dive and explore more about each capability.

Dependency views

In this section, we will near about the importance of dependency views.

Maps like the preceding one are becoming so important in everyday life; imagine a world without GPS devices or electronic maps.

There are also hard copies of the maps that were available everywhere for us to get from place to place. There are also special maps to the utilities and other public service agencies to be able to identify the impact of digging a tunnel or a water pipe or an underground electric cable. These maps help them to identify the impact of making a change to the ground.

Maps also helps us to understand the relationships between states, countries, cities, and streets with different set of information in real time that includes real-time traffic information showing accident information, any constructions, and so on.

Dependency views is similar to real life navigation maps; they provide a map of relationships between the IT Infrastructure components and the business services that are defined under the scope. Unlike the real-time traffic updates on the maps the dependency views show real-time active incidents, change, and problems reported on an individual configuration item or an infrastructure component.

Changes frequently happen in the environment. Some of the changes are handled with a legacy knowledge of how the individual components are connected to the business services through the service mapping plugin down to the individual component level. Making a change without understanding the relationships between each IT infrastructure component might adversely affect the service levels and impact the business service.

ServiceNow dependency views provide a snapshot of how the underlying business service is connected to individual Configuration Item (CI) elements. A configuration item is referred to as tangible or intangible infrastructure component or an element that might include Infrastructure components, process, procedures etc. Drilling down to the individual CI elements provides a view of associated service operations and service transition data that includes incidents logged against a given CI, any underlying problem reported against the given CI, and also changes associated with the given CI.

Dependency views provides a graphical view of configuration items and their relationships. The dependency views provide a view of the CI and their relationships; in order to get a perspective from a business stand point you will need to enable the service mapping plugin.

Having a detailed view of how the individual CI components are connected from the Business service to the CI components compliments change management, making it possible to perform effective impact analysis before any changes are made to the respective CI:

Image source: wiki.ServiceNow.com

A dependency map starts with a root node, which is usually termed as a root CI that is grayed out with a gray frame. Relationships start building up and they map from the upstream and downstream dependencies of the infrastructure components that are scoped to discover by the ServiceNow auto discovery. Administrators have control of the number of levels displayed the dependency maps.

It is also easy to manage maps that allow creating or modifying existing relationships right from the map that posts the respective changes to the CMDB automatically.

Each of the CI component of the dependency maps has an indicator that shows any active and pending issues against a CI; this includes any incidents, problems, changes, and any events associated with the respective configuration item.

Dependency maps can also be created manually by creating CI and creating relationships between them to create dependency maps.

Cloud management

In the earlier versions prior to ServiceNow, there was no direct way to manage cloud instances, people had to create orchestration scripts to manage the cloud instances and also create custom roles.

Managing and provisioning has become easy with the ServiceNow cloud management application. The cloud management application seamlessly integrates with the ServiceNow service catalog. A Service Catalog provides a catalogs of services offered by an organization which has workflows built in with automation capability using orchestration workflows. The cloud management application fully integrates the life cycle management of virtual resources into standard ServiceNow data collection, management, analytics, and reporting capabilities.

The ServiceNow cloud management application provides easy and quick options to key private cloud providers, which include:

  • AWS Cloud: Manages Amazon Web Services (AWS) using AWS Cloud
  • Microsoft Azure Cloud: The Microsoft Azure Cloud application integrates with Azure through the service catalog and provides the ability to manage virtual resources easily
  • VMware Cloud: The VMware Cloud application integrates with VMware vCenter to manage virtual resources by integrating with the service catalog

The following figure describes a high-level architecture of the cloud management application:

Key features with the cloud management applications include the following:

  • A single pane of glass to manage the virtual services in public and private cloud environment including approvals, notifications, security, asset management, and so on
  • The ability to repurpose configurations through resource templates that help to reuse the capability sets
  • Seamless integration with the service catalog, with a defined workflow and approvals integration, can be done end to end right from the user request to the cloud provisioning
  • The ability to control the leased resources through date controls and role-based security access
  • The ability to use the ServiceNow discovery application to discover the infrastructure components or the standalone capability to discover virtual resources and their relationships in their environments
  • The ability to control and manage virtual resources effectively with a controlled termination shutdown date
  • The ability to perform a price calculation and integration of managed virtual machines with asset management
  • The ability to automatically or manually provision the required cloud environment with zero click options

There are different roles within the cloud management applications, here are some of them:

  • Virtual provisioning cloud administrator: The administrator owns the cloud admin portal and end-to-end management including configuration of the cloud providers. They have access to be able to configure the service catalog items that will be used by the requesters and the approvals required to provision the cloud environment.
  • Virtual provisioning cloud approver: Who either approves or rejects requests for virtual resources.
  • Virtual provisioning cloud operator: The operator fulfills the requests to manage the virtual resources and the respective cloud management providers. Cloud operators are mostly involved when a manual human intervention is required to manage or provision the virtual resources.
  • Virtual provisioning cloud user: Users have access to the my virtual assets portal that helps them to manage the virtual resources they own, have requested, or are responsible for.

How clouds are provisioned

  • The cloud administrator creates a service catalog item for users to be able to request for cloud resources
  • The cloud user requests for a virtual machine through the service catalog
  • The request goes to the approver who either approves or rejects it
  • The cloud operator provisions the requests manually or virtual resources are auto provisioned

Discovery

Imagine how an atlas is mapped and how places have been discovered using exploration devices including manually, by satellite, by survey maps, or by street maps collector devices.

These devices crawl through all the streets to collect different data points that include information about the streets, houses, and much more.

This information is used by consumers for various purposes, including GPS devices, finding and exploring different areas, finding the address of a location, checking for any incidents, constructions, or road closures on the way, and so on.

ServiceNow discovery works in the same way, ServiceNow discovery explores the enterprise network, identifying the devices in scope. ServiceNow discovery probes and sensors perform the collection of infrastructure devices connected to a given enterprise network. Discovery uses probes to determine which TCP ports are opened and to see if it responds to the SNMP queries and sensors to explore any given computer or device, starting first with basic probes and then using more specific probes as it learns more.

Discovery explores to check on the type of device, for each type of device, discovery uses different kinds of probes to extract more information about the computer or device, and the software that is running on it.

CMDB is populated through ServiceNow discovery. ServiceNow discovery searches for devices on the network, when ServiceNow discovery finds a device match within the CMDB; either CMDB gets updated with an existing CI or a new CI is created within the CMDB. Discovery can be scheduled to perform the scan at certain intervals; configuration management keeps the up-to-date status of the CI through discovery.

During discovery, the MID Server looks back on the probes to run from the ServiceNow instance and executes probes to retrieves the results to the CMDB with in the ServiceNow instance. No data is retained on the MID Server. The data collected by these probes is processed by sensors.

Discovery architecture

ServiceNow is hosted in ServiceNow data centers spanned across the globe. ServiceNow as an application does not have the ability to communicate with any given enterprise network. Traditionally, there are two different types of discovery tool on the market:

  • Agent based: An agent is a piece of software installed on the servers or individual systems that sends all information about the system to the CMDB.
  • Agentless: Agentless discovery doesn't require any individual installations on the systems or components. They utilize a single system or piece of software to probe and sense the network by scanning and federating the CMDB.

ServiceNow is an agentless discovery that does not require any individual software to be installed, but it does require MID Server to be installed on the network where discovery has to be run. Discovery is available as a separate subscription from the rest of the ServiceNow platform and requires the discovery plugin.

MID Server is Java software that runs on any windows or UNIX or Linux system that resides within the enterprise network that needs to be discovered. MID Server is the bridge and communicator between the ServiceNow instance that is sitting somewhere on the cloud and the enterprise network that is secured and controlled.

MID Server uses several techniques to probe devices without using agents. Depending on the type of infrastructure components, MID Server uses the appropriate protocol to gather information from the infrastructure component. For example, to gather information from network devices MID Server will use Simple Network Management Protocol (SNMP), to connect to the Unix systems MID Server will use SSH.

The following table shows different ServiceNow discovery probe types:

Device Probe type
Windows computers and servers Remote WMI queries, shell commands
UNIX and Linux servers Shell command (via SSH protocol)
Storage CIM/WBEM queries
Printers SNMP queries
Network gear (switches, routers, and so on) SNMP queries
Web servers HTTP header examination
Uninterruptible Power Supplies (UPS) SNMP queries

Credentials

ServiceNow discovery and orchestration features require credentials to be able to access the enterprise network; these credentials vary depending on network and device. Credentials such as usernames, passwords, and certificates need a secure place to store these credentials.

ServiceNow credentials applications store credentials in an encrypted format on a specific table within the credentials table.

Credential tagging allows workflow creators to assign individual credentials to any activity in an orchestration workflow or assign different credentials to each occurrence of the same activity type in an orchestration workflow. Credential tagging also works with credential affinities. Credentials can be assigned an order value that forces the discovery and orchestration to try all the credentials when orchestration attempts to run a command or discovery tries to query.

Credentials tables contain many credentials, based on pattern of usage the credential applications knows which credential to use for a faster logon to the device next time.

Credentials are encrypted automatically with a fixed instance key when they are submitted or updated in the credentials (discovery_credentials) table. When credentials are requested by the MID Server, the platform decrypts the credentials using the following process:

  1. The credentials are decrypted on the instance with the fixed key.
  2. The credentials are re-encrypted on the instance with the MID Server's public key.
  3. The credentials are encrypted on the load balancer with SSL.
  4. The credentials are decrypted on the MID Server with SSL.
  5. The credentials are decrypted on the MID Server with the MID Server's private key.

A ServiceNow instance can store credentials used by discovery, orchestration, and service mapping in an external credential repository rather than directly in a ServiceNow credentials record.

Currently, the ServiceNow platform supports the use of the CyberArk vault for external credential storage

The ServiceNow credential application integrates with the CyberArk credential storage. The MID Server integration with CyberArk vault enables orchestration and discovery to run without storing any credentials on the ServiceNow instance.

The instance maintains a unique identifier for each credential, the credential type (such as SSH, SNMP, or Windows), and any credential affinities. The MID Server obtains the credential identifier and IP address from the instance, and then uses the CyberArk vault to resolve these elements into a usable credential.

The CyberArk integration requires the external credential storage plugin, which is available by request.

The CyberArk integration supports these ServiceNow credential types:

  • CIM
  • JMS
  • SNMP community
  • SSH
  • SSH private key (with key only)
  • VMware
  • Windows

Orchestration activities that use these network protocols support the use of credentials stored on a CyberArk vault:

  • SSH
  • PowerShell
  • JMS
  • SFTP

MID Server

The Internet has become a prime utility for our day-to-day survival. The availability of Wi-Fi or hard cable network is provided by Internet service providers, these cables run through several miles across different cities, states, and countries. To subscribe to Internet services, our provider places a modem in our home. This modem allows the service provider to enable the Internet capabilities in your home and to link to their network and control them.

Similarly, ServiceNow is a cloud-based application and there are many customers who subscribe and use ServiceNow. ServiceNow is like the Internet service provider, instead of a modem there is something called MID Server that needs to be configured for ServiceNow to be able to communicate with the enterprise network. A piece of software needs to run on the enterprise network and be configured for ServiceNow to be able to communicate with the MID Server and be able to talk to the infrastructure components.

The MID Server facilitates communication and movement of data between the ServiceNow platform and external applications, data sources, and services. MID Server is a simple Java application that can run on Windows, Linux, or Unix environments; it facilitates the data exchange between the enterprise network and ServiceNow instance. As MID Server communications are initiated inside the enterprise firewall, they do not require any special firewall rules.

MID Server is not only used by discovery, but it is used by various other components within ServiceNow, which include:

  • Discovery
  • Orchestration
  • Import sets
  • Altiris
  • Microsoft SMS/SCCM
  • Avocent LANDesk
  • HP OpenView Operations
  • Microsoft System Center Operations Manager (SCOM)
  • Borland Starteam Integration
  • Microsoft MIIS
  • Service assurance

The following figure shows the high level architecture of the MID Server and interaction points:

The ECC queue is a connection point between an instance and other systems.

The MID Server subscribes to messages published by the Asynchronous Message Bus (AMB), which notifies the MID Server about waiting jobs assigned to it. The MID Server opens a persistent connection to the instance through the AMB and listens on the /mid/server/<mid_sys_id> AMB channel. When an output record is inserted into the queue (ecc_queue) table, an AMB message is sent to the MID Server's channel.
The MID Server receives this message and immediately polls the ecc_queue table for work:

  • If a job exists in the ECC queue for that MID Server , the MID Server sets the status to I'm working on it
  • It then does the work that is requested
  • Then it reports the findings of the job back to the ECC queue

Depending on infrastructure factors that include the size of infrastructure there might be a need to place multiple MID Servers in the enterprise network. Placing multiple MID Servers will reduce the load and distribute the functionality between the MID Servers and what they are intended for. For example, there might be five MID Servers that are being used for only SSO integration and there might be an MID Server used for orchestration.

MID Server can be installed on a single machine or multiple MID Servers on a single machine.

There are several factors that need to be considered to determine if multiple MID Servers are required:

  • Network: In a WAN deployment, deploying and having one MID Server to probe the WAN network might be a huge load and might impact the performance of the MID Server, the best way is to deploy MID Server into a different LAN network
  • Security: Security policy controlled network devices with Access Control List (ACL) might require additional MID Servers on a machine in the network that is already on the ACL
  • Capacity and response time: When the volume of configuration items to be discovered are high, multiple MID Servers need to be installed for it to be able to return responses quickly
  • Probes: Depending on the type of probe there might be a need for separate MID Servers for each type of probe

MID Servers are placed at the lowest domain level in a domain separated environment.

Orchestration

Imagine a world where a data center is situated several miles away from a corporate office, even rebooting the server requires a big commute to the data center. Imagine desktop technicians going through each desktop and installing software on each system. Imagine several manual steps in provisioning an AD or a virtual resource. Things have changed and people expect a speedy service and a more automated way of removing manual steps.

Orchestration is the automated arrangement, coordination, and management of complex computer systems, middleware, and services. Thanks to the automation tools available, it makes things much simpler. ServiceNow orchestration capabilities, unlike any other tools, provide orchestration or automation capabilities. Orchestration automates simple or complex multi-system tasks on remote services, servers, applications, and hardware. Orchestration is available as a separate subscription from the rest of the ServiceNow platform.

Orchestration provides the ability to make calls outside of a ServiceNow instance, directly to SOAP and REST web services, or to systems within an enterprise's corporate firewall through the MID Server. ServiceNow has workflow editor to create and define workflows across the different applications. The Orchestration extends the workflow editor by providing these features:

Activity packs containing ready-to-use activities:

  • An activity designer that allows developers to create custom activities without having to rely on scripting
  • The ability to create activity packs using scoped applications
  • A databus for reusable data

When an orchestration activity starts within a workflow, orchestration launches a probe and writes a probe record to the ECC queue. The workflow pauses as the MID Server picks up the request and executes the probe. When the probe reports back, the workflow resumes as the results are analyzed. The workflow can exit or continue at this point.

Orchestration extends the ServiceNow workflow to interact with systems outside the ServiceNow instance. Orchestration provides custom activity packs you can use to automate tasks such as employee onboarding, user access rights, server management, and managed file transfers.

MID Server plays an important role in providing orchestration capability. MID Servers are associated with IP address ranges, enabling orchestration to select the correct MID Server to use for an orchestration activity based on the IP address of the target machine.

This functionality ensures that an MID Server with proper privileges is available wherever orchestration probes need to operate in a network. Auto finder also enables administrators to define specific capabilities for each MID Server within an IP address range.

Some of the automation that ServiceNow orchestration can perform includes the following VMware (through vCenter):

  • Amazon EC2 instances
  • Any system presenting web services
  • Windows Active Directory (AD)
  • Microsoft Exchange mail servers
  • Puppet labs Puppet (with configuration automation)
  • Chef (with configuration automation)
  • Any system accessible from the command line

The AD activity pack enables an administrator to create, delete, and manage objects in Windows AD, such as users, groups, and computers, using a ServiceNow orchestration workflow.

For example, you can reset a password automatically from a user request. You can manage any user account in AD with these activities, whether or not it was created by an orchestration workflow. Orchestration workflow can perform the following in relation to the Activity directory:

  • Add a user to group AD activity
  • Change an AD user password
  • Create an AD object
  • Disable an AD user account
  • Enable an AD user account
  • Check if an AD account is locked
  • Query AD
  • Remove an AD object
  • Remove a user from group AD activity
  • Reset an AD user password
  • Unlock an AD account
  • Update an AD object

Orchestration provides several applications with your subscription:

  • Orchestration ROI: The orchestration ROI application computes savings resulting from automated tasks in your instance, based on the hourly rate selected for performing tasks manually and the time period of the evaluation. Orchestration ROI estimates your savings by multiplying the cost of performing repetitive tasks manually by the estimated number of times the system performs those tasks automatically during a specific date/time range. The system also calculates the actual savings of your automations. Orchestration ROI is included with the base orchestration subscription. Orchestration ROI reports offer a number of views of the comparative data and allow you to access the associated records directly from the reports.
  • Client software distribution: The Client Software Distribution (CSD) application allows administrators to distribute software from the service catalog using third-party management systems. CSD allows an administrator to create all the records necessary to deploy software from service catalog requests, including software models and catalog items. CSD also integrates with software asset management to track license counts for deployed software. Deployment is accomplished using orchestration activities and workflows.
  • Configuration automation: Configuration automation allows you to use ServiceNow orchestration, Puppet, and Chef to provision and configure individual servers or groups of servers in your network. Chef is a server management application that can use ServiceNow CI data to bring Linux or Windows computers into a desired state by managing files, services, or packages installed on physical or virtual machines. Puppet is a server management application that can use CMDB data to bring computers into a desired state by managing files, services, or packages installed on physical or virtual machines. The ServiceNow application can interact with Puppet systems that run on Linux.
  • Password reset and password change: The password reset application allows end users to use a self-service process to reset their own passwords on the local ServiceNow instance. Alternatively, your organization can implement a process that requires service-desk personnel to reset passwords for end users. The password change application extends the password reset application by letting admins define how users change their passwords.
  • Self-service process: Users reset their password over the Internet using a browser on all supported interfaces, including mobile devices.
  • Service-desk password reset process: Users reset their passwords with the assistance of a service-desk employee, over the phone or in person.

Service mapping

The organization provides services to its customers. IT plays a critical role in providing services to the business community who actually deliver the services to the end users or sell the products. Each line of a separate product line or type of service provided is called a business service. Some examples of business services include:

  • Financial institutions such as a bank might have business services such as loans, credit cards, banking accounts, and so on
  • In a health care pharmacy business, services might include research, development, and manufacturing
  • In an oil and gas business, services might be downstream, upstream, manufacturing, research and development, and shipping

Each organization has exclusive types of business services to offer, some of the business services might overlap, which are pertinent to the same type of domain. A business service view to IT is most important to understand how IT is impacting the business or supporting a business service. Service mapping helps to bridge the gap to understand how IT is connected to the business. Service mapping helps to build a detailed map of all the configuration items, including all the hardware and software related configuration items used in a business service.

In some of the organizations people usually take an inventory of the list of configuration items that are isolated individually. These do not have any view of how configuration items are connected to a given business service, these types of mapping are called horizontal mapping, which just has relation to how CI's are connected to individual configuration item components, but no relation to each component of the configuration item. In a service mapping there is a holistic view of how different CI's components are mapped to other individual components of a business service.

Service mapping collects data about devices and applications used in business services in the organization. It then creates a map of business services and writes the collected data into the CMDB. Service mapping uses patterns to discover and map CIs. A typical service mapping pattern consists of two types of algorithms--one for CI identification and one for finding CI connections.

Business service maps show the snapshot of the interconnection between the infrastructure and the business service, service mapping helps to regenerate the maps with up-to-date information.

Service mapping creates maps of the business services by working together with other ServiceNow components. Service mapping uses the ECC queue and MID Servers for discovery and it writes discovered information into CMDB.

Mapping of devices is dependent on how the MID Server is set up and how discovery is configured. There might be a need of multiple MID Servers based on several factors, including configuration items sitting on a dematerialized zone and also secured network, multiple MID Servers are placed to discover data from multiple sources, and doing the service mapping.

The following figure describes how MID Server is set up in a domain separation environment:

How service mapping works

In this section, lets explore and see how Service Mapping works.

  1. For every discovery request, service mapping selects MID Server, by default service mapping selects the MID Server whose IP ranges matches the IP in the discovery request. If there is not a match service mapping selects the default MID Server.
  2. Service mapping creates a discovery request for the IP address of the entry point. It then writes the request in the (ECCExternal Communication Channel (ECC) queue and assigns an MID Server to the request.
  3. The MID Server passes information on the discovered CI, its attributes, and connections to the ECC queue.
  4. The MID Server checks the ECC queue and retrieves the discovery request assigned to it.
  5. The MID Server starts running identification sections of the pattern to find the match for the entry point. When the identification section matches the entry point, the pattern discovers a CI.
  1. The MID Server starts running connectivity sections of the pattern to find outgoing connections of the newly discovered CI.
  2. Service mapping checks the ECC queue and receives information on the newly discovered CI.
  3. Service mapping writes the information into the CMDB and adds this CI to the business service map.

Event management

Incidents occur in the IT Infrastructure that impacts a business service. These incidents originate from various sources, such as events and alerts. The IT infrastructure is monitored by various different sets of monitoring tools at different organizations. These monitoring tools collect data from the individual infrastructure components about their activity and signs of abnormality, these might be log messages, warnings, errors, failure messages, security messages, and so on. These messages are called events. ServiceNow event management helps to identify issues across the infrastructure in a single pane of glass or management console by providing event and alert analysis to ensure service availability with the ability to:

  • Configure rules for triggering incidents and remediation actions
  • Configure alert binding to CIs, services, and hosts for root cause analysis
  • Track events from various systems on a single console
  • Monitor the alerts console for real-time event processing
  • Review the color-coded service maps to see high priority alerts and events
  • Use dashboards for monitoring, analysis, and remediation of alerts
  • Get a history of previous alerts and events
  • Review impact relationships between parent and child CIs
  • Review impact and severity calculations based on alerts to prioritize work
  • Remediate alerts by integrating with orchestration

An alert is a notification generated by event management for selected events that are considered to be important and require attention. As part of the alert life cycle, you can manage alerts in the following ways:

  • Acknowledge alerts
  • Create a task such as an incident, problem, or change
  • If automatic remediation tasks apply to the alert, begin automatic remediation to start a workflow
  • Complete all tasks or remediation activities
  • Close alerts for resolved issues
  • Add additional information, such as a knowledge article for future reference

The generation of alerts is based on event rules. Event management processes events, generates alerts, and manages alert and incident resolution. Event management either pulls events from supported external event sources using an MID Server.

Event management leverages service mapping data and also data from service analytics to resolve an alert that is raised from the IT infrastructure component. Events are related to the configuration items in the CMDB; when an event is generated, event management locates the associated CI for generating an alert.

Source: wiki.servicenow.com

Event rules can be configured in ServiceNow with the ability to perform and take certain actions as required. Detailed event information associated with individual events or a group of eventent information associated with individual events or a group of events with individual rules set can be viewed within ServiceNow.

If an event rule or event field mapping used the event or group of events to generate an alert, the event information appears in the Activity section of the alert. Event management within ServiceNow has the ability to manage external events and also configure alerts for discovered business services.

Event management workflow

High-level workflow of event management in ServiceNow is described in the following list:

  • Events from other monitoring tools that are integrated and fed into ServiceNow are stored in the event table, which is the em_event table first.
  • Events are then processed for appropriate escalation by referring to the CMDB. For example, some of the events raised by critical business service and associated infrastructure might be resolved as a critical event and they follow the appropriate escalation rules that are configured.
  • Unintended events are filtered out at the next state.
  • Alert tables are referenced next for taking appropriate actions against the raised and processed events.
  • During events processing the correlation is done this point by either overwriting or preventing recursion alerts.
  • Appropriate remediation tasks are created at the next state. At places where automated self-healing solutions are in place, orchestration tasks kick in according to the configured parameters.
  • Tasks and remediation related activities utilize the task and the remediation table.
Source : wiki.servicenow.com
lock icon The rest of the chapter is locked
Register for a free Packt account to unlock a world of extra content!
A free Packt account unlocks extra newsletters, articles, discounted offers, and much more. Start advancing your knowledge today.
Unlock this book and the full library FREE for 7 days
Get unlimited access to 7000+ expert-authored eBooks and videos courses covering every tech area you can think of
Renews at $19.99/month. Cancel anytime