Update set and plugins section-4 last video

Ldap (docs )
basic config. Settings are not getting changed
Events, notifications
https://chatgpt.com/share/670cfd3e-e2fc-8001-a776-06256057cc73
docs.servicenow.com
community.servicenow.com :- any doubt to ask from community
developer.servicenow.com

https://developer.servicenow.com/dev.do#!/learn/learning-plans/washingtondc/
new_to_servicenow/
app_store_learnv2_buildmyfirstapp_washingtondc_servicenow_basics_objectives

This is where deleteMultiple() comes into play. This GlideRecord method is a powerful
tool for deleting all records that match a specified query.
Servicenow is an American based company was founded in 2004 by fred luddy (previous CTO
of software companies like peregrine systems and remedy corporation). serviceNow gives
automatice upgrades, purely a web based platform, custom subscriptions, native mobile
interface. Aspen was the first version of servicenow. It is ITIL based.
The servicenow data centers consists of thousands of servers that take on the role of load
balancer, web servers, application servers, database servers and much much more.
The general flow of servicenow :- when a client request and incident record, there request will
go over the internet and will go to the load balancer, the load balancer will then determine
which server has extra resources to allocate to process the request, the request will then go to
web server and then to application server.
The application server will perform the actual logic and will then send the query to the database
server. The database server will then send the respond to the application server, the application
server sends the response to web server and from web server to client through internet.
Server has access to :- server side api’s, script include, database
Client has access to :- client side api, UI elements(DOM), form, fileds
Other competetors of servicenow are, hp service manager, bmc remedy, ca technologies.
These 3 certifications are available in serviceNow
Upgrades in SeviceNow
Release
Purpose Scope Frequency Example
Type
Feature New workflows in a
Adds new functionality Larger Quarterly/yearly
Release module
Patch Fixes minor bugs, Performance
Moderate Monthly
Release enhances stability improvements
Fixes urgent, critical Very Emergency security
Hotfix On-demand
issues narrow vulnerability fix
These are the technologies used to develop serviceNow.
Careers in ServiceNow
 serviceNow business analyst
 serviceNow quality analyst
 serviceNow administrator
 serviceNow developer
 serviceNow architect
 serviceNow manager

ServiceNow is built using Java and Tomcat web server running on Linux. Although to develop
new modules and applications in ServiceNow the JavaScript knowledge is sufficient.
Currently ServiceNow Chairman & CEO, Bill McDermott
Major customers – Netflix, facebook, dell, vitas, Barclays, Capgemini, healthpartners, NHS,
twitter
ServiceNow is primarily considered a Platform as a Service (PaaS). It provides a cloud-based
platform that allows organizations to develop, manage, and deploy applications. Here are some
key points about ServiceNow as a PaaS:
1. Development Environment: ServiceNow offers a robust development environment
where developers can create custom applications and workflows tailored to specific
business needs.
2. Integration Capabilities: It supports integration with various third-party applications
and services, enabling seamless data exchange and collaboration across platforms.
3. Workflow Automation: ServiceNow allows users to automate workflows and processes,
enhancing efficiency and reducing manual effort.
4. Scalability: As a cloud-based platform, ServiceNow provides scalability to accommodate
the growing needs of organizations.
5. Security: It includes built-in security features to ensure data protection and compliance
with industry standards.
6. User-Friendly Interface: The platform has an intuitive interface that simplifies
application development and management for users, even those with limited technical
expertise.
ServiceNow offers a wide range of applications that cater to various aspects of IT service
management (ITSM), IT operations management (ITOM), IT business management (ITBM),
HR management and more. Here are some of the key applications provided by ServiceNow:
 IT service management
 IT operations management
 Software asset management
 IT business management
 Customer service management
 Performance analytics
 Hr service delivery
 Security operations
 Governance, risk and compliance

1. IT Service Management (ITSM)

 Incident Management: Tracks and manages incidents to restore normal service
operations as quickly as possible.
 Problem Management: Identifies and manages the root causes of incidents to prevent
future occurrences.
 Change Management: Controls the lifecycle of changes to minimize risks and impacts
on IT services.
 Service Catalog: Provides a user-friendly interface for users to request services and
products from IT.
 Knowledge Management: Stores and shares knowledge articles to help users resolve
issues independently.
2. IT Operations Management (ITOM)
Think of IT Operations Management (ITOM) as the behind-the-scenes team that ensures all
your IT systems (servers, networks, cloud services, etc.) are running smoothly, efficiently,
and without disruptions.
📌 ITOM Implementation in ServiceNow
ITOM is divided into three major capabilities that help in managing IT infrastructure
efficiently:
1️⃣ Visibility – (Discover & Map IT Assets)
This step identifies and maps all IT components (servers, networks, databases, cloud
services).
✔ Key Modules:
 Discovery ‍♂️→ Finds all IT assets in your environment
 Service Mapping 🗺 → Shows relationships between IT components
🔹 Example:
A new server is added to the network. Discovery automatically detects it and updates the
CMDB (Configuration Management Database).

2️⃣ Health Monitoring – (Detect & Respond to Issues)

This step monitors IT systems and detects problems before they impact users.
✔ Key Modules:
 Event Management 🚨 → Monitors system events and alerts IT teams
 Operational Intelligence (AIOps) 🤖 → Uses AI to predict failures
🔹 Example:
If a server CPU usage is too high, Event Management detects it and sends an alert. AI-
powered analysis suggests a solution before a failure happens.

3️⃣ Optimization – (Improve Performance & Reduce Costs)

This step automates IT processes, optimizes cloud usage, and reduces manual work.
✔ Key Modules:
 Cloud Management ☁️ → Automates and optimizes cloud resources (AWS, Azure,
GCP)
 Orchestration 🤖 → Automates repetitive IT tasks
🔹 Example:
If a virtual machine in AWS is underutilized, Cloud Management automatically scales it
down to save costs.

 Event Management: Monitors IT infrastructure for events and alerts to help resolve
issues before they impact users.
 Discovery: Automatically identifies and maps IT assets and their relationships within the
infrastructure.
 Service Mapping: Visualizes application dependencies and configurations for better
understanding and management.
3. IT Business Management (ITBM)
 Project Portfolio Management (PPM): Manages project portfolios, resources, and
financials to align projects with business objectives.
 Application Portfolio Management: Evaluates and manages the application portfolio to
ensure optimal performance and cost-effectiveness.
4. Security Operations
 Security Incident Response: Automates the process of responding to security incidents
and threats.
 Vulnerability Response: Manages and prioritizes vulnerabilities to ensure timely
remediation.
 Threat Intelligence: Integrates threat intelligence feeds to improve security posture.
5. Customer Service Management (CSM)
 Case Management: Manages customer inquiries, complaints, and support requests.
 Knowledge Management: Helps customers find answers to their questions through a
self-service portal.
6. HR Service Delivery
 Employee Service Center: Provides a centralized portal for employees to access HR
services and information.
 Case Management: Manages HR-related cases and inquiries efficiently.
7. Governance, Risk, and Compliance (GRC)
 Policy and Compliance Management: Ensures policies are followed and compliance
requirements are met.
 Risk Management: Identifies and manages risks within the organization.
8. DevOps
 DevOps Management: Integrates development and operations processes to improve
collaboration and accelerate software delivery.
9. Performance Analytics
 Dashboards and Reporting: Provides real-time insights into key performance indicators
(KPIs) and metrics.
10. Field Service Management
 Work Order Management: Manages and tracks field service requests and tasks for
efficient service delivery.
Change Management
Change Management in ServiceNow is a structured process used to control the lifecycle of
changes to IT systems, services, and infrastructure. The main goal of change management is to
minimize the risk and impact of change-related activities on the business while improving the
effectiveness of IT services. This process ensures that changes are introduced in a controlled
and coordinated manner to avoid unintended disruptions or downtime.
Key Concepts in Change Management:
1. Change Request (CR): A formal request to modify an IT service, system, or component.
It documents the details of the change, including why it’s needed, how it will be
implemented, and what risks are involved.
2. Types of Changes:
o Standard Change: A low-risk, pre-authorized change that follows a well-
established procedure (e.g., regular software updates).
o Normal Change: A non-emergency change that follows the complete change
management process, including approval, risk assessment, and implementation.
o Emergency Change: A change that must be implemented quickly due to a critical
issue or incident. It bypasses some parts of the standard change process due to its
urgency but still requires post-change review.
3. Change Workflow: The steps involved in processing a change request, which typically
includes:
o Submission: A change request is created, providing all necessary details about the
proposed change.
o Assessment: The change is evaluated for risks, potential impacts, and resource
requirements.
o Approval: The change must be approved by appropriate stakeholders (e.g.,
Change Advisory Board) before implementation.
o Implementation: The approved change is deployed in a planned and controlled
manner.
o Review: After the change is implemented, a post-change review is conducted to
evaluate its success and identify any issues.
4. Change Advisory Board (CAB): A group of stakeholders responsible for reviewing,
approving, or rejecting change requests. CAB meetings are held to discuss high-risk or
significant changes and ensure that all potential risks have been considered before
proceeding.
Change Management Process in ServiceNow:
1. Change Request Creation:
 o A Change Request (CR) is created in ServiceNow by a user or technician,
detailing the nature of the change, the affected systems, and the justification for the
change.
o Each change request is associated with relevant fields, such as change type,
priority, risk, schedule, and implementation plan.
2. Risk and Impact Assessment:
o The system or a designated person assesses the risk and potential business impact
of the change.
o Risk is evaluated based on various factors like the complexity of the change, the
criticality of the affected system, and potential downtime.
3. Approval Workflow:
o Depending on the type of change, different approval workflows are triggered. For
example, a normal change may require approval from the CAB, while a standard
change may bypass approval if it's pre-authorized.
o ServiceNow uses workflows to route the change request through the approval
process based on predefined conditions.
4. Planning and Scheduling:
o The change is scheduled to minimize disruption to business operations, often
planned during maintenance windows or low-activity periods.
o ServiceNow allows setting a change calendar and planning windows to schedule
changes efficiently.
5. Implementation:
o Once the change is approved, it is implemented according to the defined plan. The
system tracks the change implementation process, ensuring that everything is
recorded for future reference.
o Technicians or teams assigned to the change can update the status and progress
during implementation.
6. Post-Implementation Review:
o After implementation, a post-change review is conducted to assess whether the
change achieved its objectives and to identify any issues.
o The review ensures that any problems caused by the change are addressed, and
lessons learned are recorded for future reference.
7. Closure:
o Once the change is successfully reviewed and all related tasks are completed, the
change request is closed.
Key Features of Change Management in ServiceNow:
  Change Templates: Predefined templates for common change types to streamline the
process for repetitive tasks (e.g., standard changes like system patching).
 Change Risk Assessment: Automated risk calculation based on factors such as the
criticality of the service, the scope of the change, and the history of previous changes.
 Change Calendar: A visual calendar view of scheduled changes, allowing IT teams to
plan changes effectively without causing conflicts.
 Change Approval Workflows: Configurable workflows that route change requests to
the appropriate approvers based on change type, risk, or affected service.
 Integration with Incident and Problem Management: Change management is tightly
integrated with incident and problem management. For example, changes can be created
as a result of problems, and incidents can be linked to change requests.
 Automated Notifications: Automated alerts and notifications keep stakeholders
informed throughout the change process, from submission to closure.
Types of Change Requests:
1. Standard Change:
o Low-risk and pre-approved changes that follow a documented procedure.
o Example: Routine software patching or adding a new user to the system.
2. Normal Change:
o Changes that require a full review and approval process. These can be higher-risk
or more complex changes.
o Example: Upgrading a critical business application.
3. Emergency Change:
o High-urgency changes that are made to address an ongoing incident or critical
situation. These may be fast-tracked but still need post-change approval.
o Example: Fixing a critical security vulnerability.
Change Management Integration:
 Incident Management: When an incident is resolved with a workaround or a temporary
fix, a change request can be created to implement a permanent solution.
 Problem Management: Problems identified from recurring incidents may require
changes to fix the root cause, linking change requests with problem records.
 Configuration Management Database (CMDB): The CMDB is used to track the
configuration items (CIs) impacted by the change. This helps assess the potential impact
of the change and ensures that all related services are considered during planning.
Example Change Request Workflow:
1. A user submits a change request to upgrade a server’s operating system.
 2. The change request is evaluated for risk and business impact.
3. The request is reviewed and approved by the Change Advisory Board (CAB).
4. The change is scheduled during a maintenance window to minimize business disruption.
5. The IT team implements the upgrade during the scheduled time.
6. After the upgrade, a post-change review is conducted to ensure the success of the change.
7. The change request is closed, and the CMDB is updated with the new server information.
Benefits of Change Management:
 Reduced Risk: By following a structured change process, organizations can reduce the
risk of service outages, disruptions, or security breaches.
 Better Planning: With a well-defined change calendar and approval process, changes
can be planned and scheduled effectively, reducing the likelihood of conflicts.
 Improved Communication: The change management process involves communication
with all stakeholders, ensuring that everyone is aware of the change’s impact, schedule,
and status.
 Increased Efficiency: Standardized change processes and workflows streamline the
change lifecycle, making it easier for IT teams to manage changes.
In summary, Change Management in ServiceNow helps organizations manage changes to IT
services in a controlled, systematic manner. It reduces risk, ensures proper planning, and
facilitates collaboration between stakeholders to maintain service quality during change
implementation.

ITIL
The ITIL (Information Technology Infrastructure Library) framework is a set of best practices
for delivering IT services effectively and efficiently. It provides guidelines for managing and
delivering IT services, focusing on aligning IT services with the needs of the business. ITIL is
widely used in organizations to ensure that IT services meet the expectations of customers and
provide value.
Key Concepts of ITIL:
1. Service Strategy: Understanding customer needs, market conditions, and offering the
right services.
2. Service Design: Designing IT services that meet business goals, including processes,
technology, and tools.
3. Service Transition: Managing changes, releases, and transitioning new services into the
live environment.
4. Service Operation: Managing day-to-day operations of IT services, ensuring smooth
service delivery and handling incidents and problems.
 5. Continual Service Improvement (CSI): Constantly improving IT services based on
feedback, monitoring, and evaluation.
ITIL has undergone several revisions, with the latest version being ITIL 4, released in 2019.
ITIL 4 introduces a more flexible approach to service management, incorporating modern
concepts such as Agile, DevOps, and Lean.

Example of entire ITIL process Let us take an example of a startup BookWorm ltd., which sells
books online through their website. The company is planning to launch a book rental service in
selected cities. This service provides facility for doorstep delivery and return of the rented
books. The company has adopted an ITIL framework, since its establishment and since, this is a
new service, it should undergo various stages of ITIL. Service strategy The service proposal is
first presented to the stakeholders. The discussions on customer base, return on investment
(ROI), prices, market research, competitors and business model takes place in this phase.
Service design The blueprint of the service is prepared by the experts in the respective fields.
The technology that will be used to deliver the service to the customer, subscription plans,
payment method, online portal design, delivery and return model and charges are finalised in
this stage. Service transition At this point of time, scope and design of the service is already
defined. In service transition, the preparation to implement the service starts. The change
request is raised for the new service and activities like software development, budgeting,
approval, acquisitions, inventory management is undertaken by the respective teams. The
roadmap for the service is finalised and milestone dates are set for the service to go live.
Service operation The service is now in production and each and every issue (whether one time
or recurring) reported during the service delivery by the customers, users or internal team is
tracked and managed by the Service operation. Continual Service Improvement In this
continuous process, the opportunities are identified to make service better, for example, internal
IT team suggests a new CMS (content management system) tool for their website, which
provides improved metrics, easy access and enhanced features. in this example what i have
figured out is that servicenow will come into picture during the service operation phase
ITIL in ServiceNow
 Incident Management
 Problem Management
 Change Management
 Request Fulfillment
 Service Level Management
 Asset and Configuration Management (CMDB)
 Knowledge Management
 Continual Service Improvement
Incident management –
an employee is getting issue to start the computer or browser not connecting to internet. There
are 2 ways to solve
1. By doing a temp fix
2. Analying the root cause and solving that root cause which is called problem management.
Steps in Incident Management
1. Detect and record (manually or automatically)
2. Classify and prioritise
Classifying the category of the problem software, hardware or network. Prioritizing
them as urgent or not so urgent issue. Impact (amount of users getting impacted) +
Urgency = Priority
Impact – measures the effect of incident on business processes
Criteria:-
 No of users affected.
 No of services affected.
 Reputation.
Urgency :- The extent to which an incident resolution can bear delay.
Priority :- depends upon urgency and criteria.

3. Investigate and Diagnose

This phase depends upon the info collected in the first 2 phases.
 4. Resolution and restore
Now resolution can be temporary also.
5. Incident closure
Here the customer can review.
Key Roles in Incident Management
1.
2.

3.
The records(row) in servicenow are stored in the database table, in databse there are many
tables(incident, changes, problem, user etc etc) each record has a unique key sys_id generated
by servicenow platform to uniquely identify each record.
Context Menu – It is the menu that appears when we click on the hamburger icon. Context
Menus are analogous to the application menus of a program on your computer
Personalization list/form – any user can do personalizations in their instance.
Configurations list/form – can only be done by admin and will get applied to every user’s
interface.
1. Service now request/response – Client (Browser) Request: When a user interacts with
ServiceNow (e.g., submitting a form or loading a page), a request is made from the
browser (client) to the ServiceNow application server.
2. Application Server: The ServiceNow application server processes this request. It
determines what data or actions are required and sends the appropriate request to the
data center where ServiceNow's databases are stored.
3. ServiceNow Data Centers: The ServiceNow data centers host all the customer data and
backend infrastructure. When the application server requests specific data (e.g., an
incident or change request), the data center fetches the required data from the databases
and sends it back to the application server.
4. Application Server Response: The application server then processes the data received
from the data center and prepares it in a format (usually HTML, JSON, etc.) that can be
sent back to the browser.
5. Browser (Client) Response: The formatted data is sent back to the user's browser, where
it's displayed as part of the webpage.

Roundtrip Time
The roundtrip time refers to the total time it takes for a request to travel from the client
(browser) to the data center and for the response to be returned to the client.
 Latency: Even if a user has a fast internet connection, there is inherent latency in this
process because the request must:
o Travel from the user's browser to the application server.
o Be processed by the application server, which then queries the data center.
o The data center retrieves the data and sends it back to the application server.
o The application server then sends the response back to the browser.
This entire process takes time, especially if the data center is located far from the user or if
the data processing involves complex queries. This latency is often not related to the user's
internet speed, but rather to the time it takes for the ServiceNow infrastructure to process the
request.

Data Dictionary Table

The Dictionary Entries [sys_dictionary] table, also called the System Dictionary, defines every
table and field in the system. It contains information about data type, character limit, default
value, dependency, and other attributes of a field.
Access the system dictionary in one of these ways:
 To see the system dictionary list view, navigate to System Definition > Dictionary.
 To view particular dictionary definition, right-click the list header, form header, or field
label, and select Configure Dictionary.
The following image shows a filtered list of dictionary entries for the Incident table and the
Task table, which it extends.
What is dictionary override in ServiceNow?
Dictionary overrides allow for overriding various field properties in an extended table. Consider
an example of a changing table that is extended from the task table. There is a status field in the
task table which is set as read-only. If you use this field in change form, it will be in read-only
mode. By using the dictionary override, we can alter this to non-read only

Field Labels
The Field Labels [sys_documentation] table, also called the Language File, contains
information about the labels and hints for each table and column in the system.
Access the language file in one of these ways:
 To see the list view, navigate to System Definition > Language File.
 To see the field label for a particular field, right-click the field label on the form.
The following image shows the language file filtered to display only labels on the Incident
table.
System dictionary
View a list of all tables in columns in your instance from the system dictionary.
Each row in the system dictionary represents either a table or a column in one of the tables. The
system dictionary provides options for administrators to modify tables and fields, which in turn
define lists and forms.
Use caution when changing system dictionary records because changes can have a high impact
on functionality. In particular, changes to dictionary entries for system tables, which are tables
that begin with sys_, can create system-wide issues such as the inability to use update sets.
Dictionary changes are difficult to reverse. Also, dictionary changes automatically apply to all
extended tables unless a dictionary override is defined

Table relationships
You can create relationships between tables by extending tables, referencing records in another
table, creating many-to-many relationships, and joining tables in a database view.
Tables can be related to each other in several ways.
Extensions
A table can extend another table. The table doing the extending (child class) includes all of the
fields of the other table (parent class) and adds its own fields. For instance, the Incident
[incident] table has all of the Task [task] table fields (because an incident is a special form of
task) and has its own incident-specific tasks.
One-to-many
Within a table, a field can hold a reference to a record on another table. There are three types of
one-to-many relationship fields.
Reference fields
Allow a user to select a record on a table defined by the reference field. For instance,
the Caller field on the Incident table allows the user to select any record on the User table.
Glide lists
Allow a user to select multiple records on a table defined by the glide list. For instance,
the Watch list field on the Incident [incident] table allows the user to select records on the User
[sys_user] table.
Document ID fields
Allow a user to select a record on any table in the instance. These fields are much less common,
but one example is the Document field on the Translated Text [sys_translated_text] table.
Many-to-many
Two tables can have a bi-directional relationship, so that the related records are visible from
both tables in a related list.
Database views
Two tables can be joined virtually in a database view to enable reporting on data that might be
stored over more than one table.
Table extension and classes

Administrators and application developers typically extend tables to create a set of related
records that share information. For example, in the base system, the Task and the Configuration
Item tables have multiple extensions:

A table that extends another table is called a child class, and the table it extends is the parent
class. A table can be both a parent and child class both extending and providing extensions for
other tables. A parent class that is not an extension of another table is called a base class.
Administrators can use these tools to see the relationships between classes.
 Schema map
 System dictionary
 Tables module
Extension models
The Now Platform offers these extension models.
 Table per class
 Table per hierarchy
 Table per partition

How Table per Class Works

1. Tables Created:
o A separate database table is created for the parent class and each child class.
o Example: If there’s a parent table Asset, and child tables Contract, Lease, and
Warranty, each will have its own corresponding database table.
2. Fields Derived from Parent Class:
o Child classes inherit fields from the parent class.
o For example, if the parent table Asset has fields like Name and Serial Number,
all child tables will inherit these fields.
3. Dictionary Records for Parent Class:
o The Dictionary defines the structure of a table and its fields.
o For a parent class (e.g., Contract), Dictionary records are created for:
 The table definition itself.
 Each field defined in the parent class that can be inherited.
 o Example: The Contract table has 59 Dictionary records, which means:
 One record defines the table.
 The other 58 records define the fields in the table.
4. Dictionary Records for Child Classes:
o Child classes only have Dictionary records for fields unique to the child class.
o Fields inherited from the parent table do not get separate entries in the child class's
Dictionary.
o Example:
 The Lease table inherits fields from Contract but adds a unique field like
Lease Duration.
 The Dictionary for Lease will include only its unique fields (e.g., Lease
Duration), not the inherited fields.
5. Records Replicated:
o The parent class replicates records stored in its child classes:
 If a record exists in a child table, a corresponding record is automatically
created in the parent table.
 These replicated records have the same sys_id in both parent and child
tables.
o Example:
 If a record is created in the Lease table, the Contract table automatically
has a corresponding record.
 Any change made to the child record (e.g., in Lease) is reflected in the
parent record (e.g., in Contract).
How Table Per Hierarchy Works
1. Tables Created:
o Only one database table is created for the parent class.
o All records, including those for child classes, are stored in this single parent table.
o Child classes do not have separate database tables.
o Example:
 For the parent table Task, records for child tables like Incident, Problem,
and Change are stored in the Task table.

2. Fields Derived from Parent Class:

 o Child classes inherit fields from the parent class.
o These inherited fields are stored in the single parent table.
o Example:
 The Incident table (child) inherits fields like Short Description and
Created Date from the Task table (parent).

3. Dictionary Records for Parent Class:

o The Dictionary contains entries for:
 The parent table definition.
 Each field that can be derived from the parent table.
o Example:
 The Task table has 66 Dictionary records:
 One defines the table structure.
 The remaining define the fields (e.g., Short Description, State, etc.).
o A special column called sys_class_name is used to identify which child class
each record belongs to:
 For Incident records: sys_class_name = incident.
 For Change records: sys_class_name = change.

4. Dictionary Records for Child Classes:

o Each child class has Dictionary entries only for fields unique to the child class.
o Fields inherited from the parent table are not redefined for child classes.
o Example:
 The Incident table has 22 Dictionary records, defining its unique fields like
Impact or Urgency.
 Inherited fields like Short Description are not listed separately in the child
Dictionary.

5. Records Replicated:
o No record replication is needed.
o All records for the parent and child tables are stored in the single parent table.
o Example:
  The Task table contains all records from child classes like Incident,
Problem, and Change.
 This avoids duplication and ensures a unified storage system.
How Table Per Partition Works
1. Tables Created:
o One primary database table is created for the parent class.
o This table stores all records, including those for child classes.
o When the database table reaches a storage limit, the system dynamically creates
additional storage tables (partitions) to store new records.
Example:
o The Base Configuration Item (cmdb) table serves as the parent table for child
classes like:
 Configuration Item (cmdb_ci)
 Hardware (cmdb_ci_hardware)

2. Fields Derived from Parent Class:

o Child classes do not derive fields from the parent class.
o Instead, each child class maintains its own list of fields, independently defined.
Example:
o The Base Configuration Item (cmdb) table may have fields like:
 Name, Location.
o The Hardware (cmdb_ci_hardware) table may add:
 Model, Serial Number.

3. Dictionary Records for Parent Class:

o The parent class has:
 A Dictionary record defining the table.
 A Dictionary record for each field relevant to the parent class.
o Changes to parent class Dictionary entries are replicated to corresponding child
classes.
Example:
 o If you update the Name field in the Base Configuration Item (cmdb) table, the
change is propagated to all child classes, like Configuration Item (cmdb_ci) and
Hardware (cmdb_ci_hardware).
o Special Dictionary Columns:
 sys_class_name: Indicates the child class a record belongs to (e.g.,
cmdb_ci_hardware).
 sys_class_path: Indicates the hierarchy or path for the child class.

4. Storage Table Management:

o When the parent class's main table reaches its storage limit:
 The system creates additional storage tables (partitions).
 New records are stored in these storage tables.
 Dictionary updates include new columns like:
 sys_storage_alias
 storage_table_name
These additions allow administrators to manage the parent class and its storage partitions as a
single logical unit.

5. Dictionary Records for Child Classes:

o Each child class has a Dictionary record for the table and for each field unique to
it.
o Some Dictionary records duplicate columns in the parent class for compatibility.
Example:
o The Hardware (cmdb_ci_hardware) table has its own fields like Model, in
addition to fields replicated from the Base Configuration Item (cmdb) table.

6. Records Replicated:
o No record replication is needed.
o All records are stored in the parent table and managed across partitions as needed.
Example:
o The Base Configuration Item (cmdb) table contains all records for its child
classes:
 Application (cmdb_ci_appl)
  Computer (cmdb_ci_computer)
 Hardware (cmdb_ci_hardware)

No, you don't explicitly choose one of these models when extending a table in ServiceNow.
The platform inherently uses one of the models based on the type of table being extended and
its architecture. Here’s how it works:

How the Extension Models Are Determined

1. Table Per Class:
o Used for most tables by default in ServiceNow.
o When you create a custom table that extends another table (e.g., extending the
Task table), the system automatically creates separate tables for both the parent
and child classes.
o This is the most common model used in ServiceNow.
2. Table Per Hierarchy:
o Primarily used for tables like Task and its child tables (Incident, Change, Problem,
etc.).
o The parent table stores all records, and child classes only define their unique fields.
o You cannot manually choose this; it's preconfigured for tables designed to use this
model (e.g., Task).
3. Table Per Partition:
o Used specifically for the CMDB tables, such as cmdb, cmdb_ci, and
cmdb_ci_hardware.
o Automatically used when creating CMDB tables because it’s optimized for
managing large-scale datasets with partitions.
o You don’t manually select this; the system determines it based on the CMDB
hierarchy.
This explanation dives into how storage aliases function within ServiceNow's database
architecture. These concepts are primarily relevant for tables using the Table per hierarchy
model, such as the Task table and its child tables (Incident, Change Request, etc.). Let's break it
down step by step.

Key Concepts Explained

Storage Alias
 A storage alias is a representation of a physical database column used by ServiceNow
to manage logical elements (fields) across parent and child tables in the Table per
hierarchy model.
 It maps a logical field from a table to a physical column in the backend database.
Query Breakdown
sql
Copy code
SELECT a_ref_2
FROM task
WHERE sys_class_name = 'change_request'
AND a_ref_2 IS NOT NULL
 a_ref_2: This is the physical column in the Task table where the data for the field
cab_delegate is stored.
 sys_class_name = 'change_request': This ensures the query only retrieves records
specific to the Change Request child table.
 a_ref_2 IS NOT NULL: Filters the query to only fetch rows where a_ref_2 has a value.
This query retrieves the data stored in the physical column a_ref_2 for the logical field
cab_delegate in the Change Request table.

Key Features of Storage Aliases

1. Mapping:
o Logical elements (fields) map to physical columns in the backend database.
o Example:
 Field cab_delegate (logical element) maps to a_ref_2 (physical column) in
the Task table.
2. Glomming:
 o Multiple sibling elements across child tables can share a single physical column.
o Example:
 A reference field in Change Request and a reference field in Incident can
share the same physical column (e.g., a_ref_2).
3. Label Mapping:
o Aliases are used to link fields with labels for better visibility in forms, reports, and
lists.

Rules and Restrictions

1. Unique Columns in the Same Class:
o Two fields in the same table (e.g., Incident) cannot share the same physical
column.
2. Parent-Child Element Restrictions:
o A field in a parent table (e.g., Task) cannot share a column with a field in a child
table (e.g., Incident).
3. Sibling Sharing:
o Fields in sibling tables (e.g., Change Request and Incident) can share the same
physical column.
4. Task-Level Restrictions:
o Fields directly created in the Task table (parent table) cannot be glommed (i.e.,
they always have dedicated physical columns).

Functionality of the Query

The provided query is:
1. Efficient: It uses the sys_class_name column to filter records specific to the Change
Request table within the Task table.
2. Accurate: It retrieves data stored in a physical column (a_ref_2) while mapping it to the
logical field (cab_delegate) based on the child table's context.

Why Glomming?
 Space Optimization: By allowing sibling elements to share columns, it reduces the need
for excessive physical columns in the database.
 Logical Separation: Each child table appears to have its own fields, but they are stored
more efficiently in the parent table.
Practical Takeaways
 When working with Table per hierarchy, storage aliases and glomming ensure optimal
storage and seamless logical representation.
 The sys_class_name column is critical for differentiating child table records within a
single parent table.
Glomming in ServiceNow refers to a mechanism used in a Table per Hierarchy extension
model where multiple logical fields (from child tables) share a single physical column in the
parent table's database schema.
It is a way of optimizing database storage and improving performance by reducing the number
of physical columns in the parent table.

How Does Glomming Work?

1. Logical Fields and Physical Columns:
o Logical fields are the fields defined in the dictionary for the child classes (e.g.,
Incident, Change Request).
o Instead of creating a unique physical column for every logical field, glomming
maps multiple logical fields to a shared physical column in the parent table (e.g.,
task).
2. Storage Alias:
o Each logical field is associated with a storage alias, which links the logical field to
the shared physical column in the parent table.
o For example:
 Logical field incident_field1 in the Incident table.
 Logical field change_field1 in the Change Request table.
 Both may map to the same physical column in the task table, say a_ref_1.
3. sys_class_name:
o The sys_class_name field in the parent table acts as a discriminator to identify
which child class a record belongs to.
o During queries, the system uses this value to distinguish records and interpret the
shared column correctly.
 Field-Specific Interpretation:
 When querying or using data, ServiceNow checks the sys_class_name and interprets the
shared physical column based on the context of the child table.
 For instance:
 o If sys_class_name='incident', task.a_ref_1 represents incident_field1.
o If sys_class_name='change_request', task.a_ref_1 represents change_field1.
 No Overlap of Field Usage:
 The fields from different tables that map to the same physical column are typically
unique to their respective tables. This ensures there is no conflict or data corruption
because records from incident and change_request do not overlap.

GUID (Globally Unique Identifier)

In ServiceNow, a GUID (Globally Unique Identifier) is used to uniquely identify records or
objects across the platform, ensuring that each record has a unique identifier that distinguishes
it from all others. GUIDs are typically used within ServiceNow to avoid conflicts or
duplications, particularly in environments with extensive data operations, integrations, or
imports.
GUID in ServiceNow contexts includes:
1. Sys ID: Each record in ServiceNow tables has a unique 32-character GUID called a Sys
ID. This identifier is automatically generated by ServiceNow when the record is created
and remains constant throughout the record's lifetime. It’s primarily used for linking
records, tracking changes, and maintaining relationships between records across tables.
2. Import Sets: When importing data into ServiceNow, GUIDs can be critical in identifying
unique records, especially if data comes from multiple sources. These identifiers help in
accurately mapping records without data loss or duplication.
3. Reference Fields: ServiceNow uses GUIDs as values in reference fields to relate records
across tables. For instance, in the Incident table, the "Assigned to" field may refer to a
user's GUID in the User table, establishing a link between the two tables.
4. External Integrations: When integrating with other systems, GUIDs ensure that records
remain consistent and uniquely identifiable, regardless of where they’re accessed from.
So, for example:
 Each User record in the User table (e.g., sys_user) has its own unique Sys ID.
 Each Incident record in the Incident table also has a unique Sys ID.
When an Incident references a User (for instance, in the Assigned to field), it doesn’t directly
copy the User’s Sys ID. Instead, it stores a reference to the User’s Sys ID in the Assigned to
field. This reference lets ServiceNow know which specific User the Incident is related to
without duplicating any user data.
UI policies
UI Policies in ServiceNow are client-side logic that enable administrators to dynamically
change form fields' behavior and appearance based on conditions. They provide a way to
control how fields behave on a form (e.g., making fields read-only, mandatory, hidden, or
visible) without needing to write any JavaScript.
Key Features of UI Policies:
1. Field Visibility: You can hide or show fields based on conditions.
2. Field Read-Only: You can make fields read-only based on the value of another field or
condition.
3. Field Mandatory: You can dynamically set fields as mandatory (required) or optional.
4. Form-Level Changes: UI Policies can be used to alter multiple fields across the form,
enhancing user experience and enforcing business rules.
Components of a UI Policy:
 Conditions: These define when the policy should be applied. You can specify field
values that must be met for the policy to take effect.
 Actions: These define what happens when the conditions are met. For example, you can
set a field to be read-only or mandatory.
Example Use Case:
 Suppose you're working with an Incident form, and you want the "Resolution
Information" section to only appear when the incident is in the "Resolved" state. You
could set up a UI Policy that checks if the state is "Resolved" and then shows the
resolution fields.
UI Policy vs. Business Rule:
 UI Policies are client-side and affect how fields behave on forms.
 Business Rules are server-side and enforce business logic at the database level (e.g., data
validations or automation actions).
UI policies change fields on a form based on a set of conditions. Use UI policies to show or
hide fields, or to make fields mandatory or read-only based on these conditions. A UI policy
specifies one or more actions to take when the policy is triggered. First, create the policy. Then
add as many actions as necessary. UI policy actions are applied only if all of the following
conditions are met:
 The UI Policy is Active
 The items in the Conditions field evaluate to true
 The field specified in the UI policy action is present on the specified form
UI policy actions specify exactly what actions to take on a specified field. The conditions
specified in the UI policy determine when these actions are triggered
In ServiceNow, when defining a UI Policy, the Order field specifies the sequence in which
multiple UI Policies will be evaluated and applied. This is particularly important when you
have more than one UI Policy that could potentially affect the same field or set of fields on a
form.
Conflict Resolution: If two UI Policies conflict (e.g., one policy makes a field mandatory and
another does not), the one with the higher order number (executed later) will have the final
effect on the form. The Order field helps control the sequence of UI Policies, ensuring the
correct logic is applied when multiple policies might affect the same fields.
UI Policy Actions and UI Actions are different in ServiceNow, and they serve different
purposes, even though both deal with form manipulation and user interface behavior.
UI Actions:
 Purpose: UI Actions are buttons, links, or context menu items that appear in the UI and
allow users to perform specific tasks. UI Actions can be used to execute both client-side
and server-side scripts when clicked.
 Scope: UI Actions can perform operations on the server or the client, such as saving
records, submitting forms, or triggering a custom action.
 Types of UI Actions:
o Form Buttons: Buttons that users click to trigger a specific action (e.g., "Submit",
"Save", "Cancel").
o Context Menu Items: Additional options in right-click context menus or list
actions.
 Trigger: UI Actions are triggered by user interaction, like clicking a button or selecting
an option from a context menu.
 Example:
 You create a UI Action that adds a "Send Email" button to the Incident form. When the
user clicks this button, a script runs to send an email to the assigned user.

IMPORTANT
Related Links
 gsftSubmit() is mostly used in UI actions that have a client side and a server side script.
 At the end of the client side script, gsftSubmit(null, g_form.getFormElement(), "Action
name") triggers the UI Action again which is specified in the 3rd parameter, this time
only the server side code gets executed.
 In general, when we need to execute both client-side and server-side scripts from a UI
Action in ServiceNow, we often use the gsftSubmit() method within the client script of the UI
Action. However, this method involves DOM manipulation, which is not recommended in
ServiceNow. The reason is that DOM manipulation requires referencing elements in the DOM
by their IDs or CSS selectors. When dealing with out-of-box DOM elements, there’s a risk that
their IDs or positions within the DOM structure may change, potentially causing the code to fail
or generate errors.

 To avoid these types of issues, it’s better to explore alternative approaches to execute server-
side scripts in a UI Action while still incorporating client-side logic. One such approach is
using GlideAjax. Below is an example use case demonstrating this approach:

 I created a UI Action named "Create Task" on the Incident form, which is displayed when the
incident is in the New state. Upon clicking the button, a confirmation prompt (handled on the
client side) is displayed. If the user confirms, the UI Action invokes a Script Include via
GlideAjax to create an Incident Task for the current incident.

The Resolved, Update, Submit, and similar buttons in ServiceNow are all examples of UI
Actions. Each of these buttons triggers a specific task or action either on the client side or the
server side when clicked.
Here's a breakdown of common UI Actions:
1. Update Button:
o Action: When the Update button is clicked, it usually saves the current form data
and updates the record in the database.
o Server-side: This is a server-side UI Action because it sends data to the server to
update the record in the database.
2. Resolved Button:
o Action: When the Resolved button is clicked (typically in an Incident form), it can
trigger a series of actions, such as setting the Incident state to "Resolved," updating
the resolution fields, and notifying the user.
 o Client or Server-side: This can be client-side (e.g., changing some fields) or
server-side (e.g., saving data, sending notifications).
3. Submit Button:
o Action: When you click the Submit button, it usually creates a new record in the
database and submits the form.
o Server-side: This sends the data to the server to create a new record.
4. Cancel Button:
o Action: When clicked, this usually cancels the action and redirects the user
without saving any changes.
o Client-side: Often handled on the client side by just redirecting the user to another
page without submitting any form data.

Example
As part of a UI action script, you can redirect a user to a URL. For example, you might add
links to a form or open a new record after it is created from a UI action. To redirect a user to a
URL from a UI action, use this syntax in the Script field to define the redirect link:

action.setRedirectURL ( 'http://www.mysite.com/mypage.htm' );

To direct a user to a record, use this syntax, where new_record is the variable name for
the GlideRecord:
action.setRedirectURL (new_record );
GlideRecord is a powerful class used in server-side scripts to interact with tables in the
platform's database. With GlideRecord, you can query, create, update, and delete records in any
table.GlideRecord provides a programmatic way to interact with ServiceNow tables. It allows
you to define queries, retrieve data, and perform operations on records. It’s especially useful in
Business Rules, Script Includes, and UI Actions for implementing custom logic.
Here's a breakdown of what GlideRecord does:
 Querying Records: Retrieve records from a table based on specific conditions.
 Creating New Records: Insert new records into a table.
 Updating Existing Records: Modify records in a table.
 Deleting Records: Remove records from a table.
Example of Using GlideRecord to Retrieve a Record
Suppose you want to retrieve an Incident record with a specific sys_id:
var gr = new GlideRecord('incident'); // Specifies the table to query
gr.get('sys_id_value_here'); // Retrieves the record by sys_id
In this example:
 new GlideRecord('incident') creates a GlideRecord instance for the Incident table.
 gr.get('sys_id_value_here') fetches the record with the specified sys_id if it exists.
Explanation of action.setRedirectURL(new_record)
This code is often used in UI Actions to redirect the user to a specific record after an action
is performed.
 action: Refers to the UI Action itself, allowing you to control what happens after the
action completes.
 setRedirectURL(): A method used to specify where the user should be redirected after
the action finishes.
 new_record: This variable is typically a GlideRecord object pointing to the specific
record you want to redirect the user to.

In ServiceNow, creating a server-side UI Action allows you to perform server-side operations

(like querying or modifying records) and run complex logic when a user interacts with a button
or link. Here’s a step-by-step guide on how to create and use a UI Action for server-side
operations:
Steps to Create a Server-Side UI Action
1. Navigate to the UI Action Module:
o In the Application Navigator, go to System Definition > UI
Fill out the necessary fields to define where and how the UI Action will appear and function.
o Name: Provide a name for the UI Action (e.g., "Close Incident").
o Table: Choose the table where this UI Action will be available (e.g., Incident for
an action on Incident records).
o Action Name: Specify an action name, a unique identifier for this UI Action.
o Active: Check this box to make the UI Action active and available.
o Show Insert / Show Update: Select whether the action should appear on new
records (insert) or only on existing records (update).
o Form Button / List Context Menu / List Choice: Choose where this UI Action
should appear (e.g., as a button on the form, in the list’s context menu, etc.).
o Condition: Write a condition script to define when this UI Action should be
visible.
2. Write the Server-Side Script in the Script Field:
 o In the Script field, write the server-side code to define the actions that should be
taken when the button is clicked. The script will use the GlideRecord API and
other server-side APIs to perform the desired operations.

📌 UI Page in ServiceNow
A UI Page in ServiceNow is a custom web page that allows you to create and display dynamic
content using HTML, Jelly (ServiceNow’s UI scripting language), and server-side scripts
(Glide APIs). It is commonly used for:
✅ Modals & Dialogs (Custom pop-ups for confirmations)
✅ Custom Forms (When the default form view isn’t enough)
✅ Dashboards & Custom Pages (For advanced UI designs)
✅ Custom Actions (Such as invoking scripts, running processes, or displaying external content)

📌 GlideModalForm API in ServiceNow

The GlideModalForm API in ServiceNow is used to create a modal (pop-up) form
dynamically, allowing users to interact with records or enter data without leaving the current
page.
It's an alternative to GlideModal, specifically designed for form-based interactions.

🚀 Features of GlideModalForm
✅ Displays a form inside a modal
✅ Used for record creation or updates
✅ Supports UI actions (Submit, Cancel, etc.)
✅ Works with GlideRecord to interact with database tables

Business Rules
Business Rules in ServiceNow are server-side scripts that run whenever a record is
inserted, updated, deleted, or queried from a database table. They allow you to apply
business logic to data being processed in the system. Business rules are a powerful tool in
ServiceNow for enforcing rules, automating processes, and controlling data integrity.
Key Features of Business Rules:

5. Server-Side Execution: Business rules are executed on the server, not the client-side
(browser).
6. Triggered by Database Operations: They are triggered by insert, update, delete, or
query operations on records in the database.
7. Flexible Timing: You can set the timing of a business rule to run before or after the
database action, or asynchronously.

1. Operation to Perform:
You need to define what type of database operation will trigger the business rule. These
operations are:
 Insert: The rule is triggered when a new record is created in the table.
 Update: The rule is triggered when an existing record is updated.
 Delete: The rule is triggered when a record is deleted.
 Query: The rule is triggered when a record or records are queried (i.e., retrieved from the
database).
You can choose one or more operations depending on when you want your business rule to
execute.
2. When to Apply (Timing):
You also need to specify when the business rule should run relative to the database operation.
The timing options are:
 Before: The rule is applied before the database action (insert, update, delete) occurs. This
is typically used to modify data before it's saved to the database.
 After: The rule is applied after the database action. This is useful for actions like sending
notifications or logging information.
 Async: The rule is applied after the action but is executed asynchronously (in the
background). This is used for operations that don’t need to occur immediately, which
helps improve performance.
 Display: The rule is applied before the data is sent to the client (when the form is
loaded). This can be used to prepare data for display on the form.
Abort action button in business rules
the Abort Action option in a Business Rule is used to stop the execution of the current
database operation. It prevents the record from being inserted, updated, deleted, or queried
based on the logic in the Business Rule.
Where is Abort Action Used?
The Abort Action checkbox is available in Before Business Rules because it needs to stop the
operation before it is committed to the database.
How It Works
When Abort Action is enabled:
 The database operation being performed (e.g., insert, update, delete) is terminated.
 Any further processing of the record is stopped.
 The record changes are not saved to the database.
OR

You can used setAbortAction() function in advanced section(script) to do the same.

Query Business Rules

In the context of Business Rules in ServiceNow, the Query option refers to Query Business
Rules. These rules are executed when a query is made to retrieve data from the database for a
specific table. They allow you to modify or filter the query dynamically before the data is
fetched and presented to the user or processed by the system.

What Does the "Query" Option Do?

When the Query checkbox is selected in a business rule:
 It ensures that the rule is triggered before data is fetched from the database.
 The rule can dynamically modify the query by adding conditions, filtering results, or
restricting access to specific records.
 It applies only to data retrieval actions (e.g., listing records in a table or fetching records
via API).

Key Features of Query Business Rules

1. Runs Before Data Retrieval:
o It does not execute for record inserts, updates, or deletions—only for queries.
2. Query Modification:
o You can manipulate the query dynamically using methods like addQuery(),
addEncodedQuery(), and addOrCondition().
3. Restricts Data Visibility:
o Useful for implementing data security by limiting which records a user or role can
see.
Use Case Scenarios
1. Restricting Records for Non-Admin Users:
o Example: Non-admin users should only see incidents assigned to their department.
if (!gs.hasRole('admin')) {
current.addQuery('department', gs.getUser().getDepartmentID());
}
2. Excluding Records Marked as Inactive:
o Example: Show only active incidents.
current.addQuery('active', true);
OR
Current.addActiveQuery();

Data policies
 Use Data Policies when you need to ensure that certain data integrity rules apply
universally, regardless of how the data is entered. For instance, if you want to ensure that a field
is always mandatory whenever a record is created or updated, regardless of whether it's done
via the UI, script or an API call.
 Use UI Policies when you want to control the visibility and interactivity of fields on a form
based on user input. For example, you might want to hide or show certain fields based on the
selection in a dropdown menu to improve the user experience.
These are all the checkboxes that you can tick, and handle to apply data policies when data is
coming form them
 Apply to import sets
 Apply to SOAP
 Use as UI Policy on client

Key Differences Between Data Policies and UI Policies:

Aspect Data Policies UI Policies
Primarily affects the user interface
Enforces data integrity at the field level,
Scope of and is triggered by user
regardless of how the data is submitted
Enforcement interactions. Applies when the
(client-side, server-side, or API).
form is displayed or updated.
Validation Can validate and enforce rules for Focuses on UI behavior, such as
Aspect Data Policies UI Policies
making fields read-only,
mandatory fields and data formats on both
mandatory, or hidden based on
client and server sides.
user input.
Evaluated when records are created or Evaluated at the client level
Execution
updated, ensuring data quality across all during user interaction with the
Timing
methods of input. form.
Used for enforcing business rules that must Used for controlling the visibility
be applied universally, such as mandatory and behavior of fields on forms
Use Cases
fields or data format validation for records based on user actions, enhancing
regardless of the submission method. user experience.
Does not enforce rules when data
Applies to all data submissions, including
Integration is submitted via APIs or scripts
through web services and APIs, ensuring
with APIs unless those operations trigger the
data integrity at all levels.
UI logic.

Schedules Jobs
Scheduled jobs are used to schedule
 Report
 Scripts
 Charts
 Incident, change, ci requests
 etc
In ServiceNow, Scheduled Jobs (also known as Scheduled Scripts or Scheduled Jobs under
"Scheduled Script Executions") are automated tasks that run scripts at predefined intervals or
specific times. They are ideal for performing regular maintenance tasks, data processing, or
other background tasks without manual intervention.
Key Concepts of Scheduled Jobs
1. Definition:
o Scheduled Jobs are server-side scripts that run based on a schedule defined by the
user. They can perform various tasks, such as data cleanup, record updates,
notifications, or external integrations.
2. Accessing Scheduled Jobs:
o You can create and manage Scheduled Jobs by navigating to System Definition >
Scheduled Jobs in ServiceNow. Here, you can define the scripts and set their
schedules.
 3. Components of a Scheduled Job:
o Name: A descriptive name to identify the job.
o Active: A checkbox to enable or disable the job. Only active jobs will run
according to their schedule.
o Run As: Specifies the user whose permissions will be applied when the job
executes. This setting controls the access rights of the script.
o Run: Defines the schedule frequency, such as Daily, Weekly, Monthly, or Once.
Custom cron expressions are also available for more specific timing.
o Time: Sets the exact time of execution. For example, if the schedule is Daily, you
can choose the time of day it will run.
o Condition: Defines any additional conditions for the job to run. This can be a filter
or a specific criteria that must be met for the job to execute.
o Script: The actual script logic that the job will execute. This is where you add the
code for the actions you want to automate, such as querying records, updating
fields, or sending notifications.
1️⃣ Scheduled Script Execution
🔹 What is it?
 A server-side script that runs at a specific time or interval without requiring user
interaction.
 Uses GlideScheduleManager, GlideRecord, and script logic to perform background
tasks.
 Commonly used for custom automation that isn't tied to ServiceNow's job framework.
🔹 Where is it stored?
 It is stored in the sysauto_script table.
🔹 How is it executed?
 Runs automatically at a scheduled time.
 Can be manually triggered using:
javascript
CopyEdit
SncTriggerSynchronizer.executeNow(rec);
 Executes independently of the Scheduled Job engine.
🔹 Use Cases: ✅ Custom business logic automation
✅ Deleting or updating records at a specific time
✅ Performing database maintenance tasks
✅ Automating external API calls or integrations
2️⃣ Scheduled Jobs
🔹 What is it?
 A predefined ServiceNow job that can execute different types of tasks (script execution,
data cleanup, email notifications, etc.).
 Configurable through the Scheduled Jobs module (sys_trigger table).
🔹 Where is it stored?
 It is stored in the sys_trigger table.
🔹 How is it executed?
 Can be configured through System Definition → Scheduled Jobs.
 Some jobs execute built-in ServiceNow actions (e.g., SLA processing, event handling).
 Can be triggered manually or on a set schedule.
🔹 Use Cases:
✅ Running cleanup scripts at scheduled intervals
✅ Automating email notifications or system maintenance
✅ Processing workflows and business rules
✅ Managing background processes

Update Set
In ServiceNow, an Update Set is a mechanism used to capture and transfer customizations and
configurations between ServiceNow instances. Update Sets are essential for managing changes
in a structured way, making it easier to move changes from development to testing and
production environments. Here’s a detailed overview of what Update Sets are, their purpose,
how they work, and best practices for using them.
Key Features of Update Sets:
1. Change Management: Update Sets allow you to bundle changes (like scripts, forms,
tables, etc.) into a single package, which can be moved and applied to other instances.
This is particularly useful for managing and deploying changes in a controlled manner.
2. Version Control: By using Update Sets, you can keep track of different versions of
customizations and revert to previous versions if necessary.
3. Incremental Changes: Update Sets can be created incrementally, meaning you can add
new changes to an existing Update Set rather than creating a new one every time.
4. Cross-instance Migration: Update Sets facilitate the transfer of changes across different
ServiceNow instances, such as from a development instance to a test or production
instance.
How Update Sets Work:
 1. Creating an Update Set:
o Navigate to System Update Sets > Local Update Sets in the application
navigator.
o Click on the New button to create a new Update Set.
o Provide a name and description for the Update Set and set its status to In
Progress.
2. Capturing Changes:
o As you make changes (like modifying a form, adding a business rule, etc.),
ServiceNow automatically captures these changes into the active Update Set.
o You can also manually add existing records to an Update Set by right-clicking on
the record and selecting Add to Update Set.
3. Completing an Update Set:
o Once you have captured all desired changes, you can mark the Update Set as
Complete.
o This prevents any further changes from being added to the Update Set.
4. Exporting an Update Set:
o To move an Update Set to another instance, you need to export it. This creates an
XML file containing all the changes.
o Navigate to the Update Set record and click on Export > XML.
5. Importing an Update Set:
o On the target instance, navigate to System Update Sets > Retrieved Update Sets.
o Click on Import Update Set from XML and upload the exported XML file.
o After importing, you can preview the Update Set to see which changes will be
applied.
6. Applying an Update Set:
o After reviewing the Update Set, you can commit it to apply the changes to the
instance.
Best Practices for Using Update Sets:
1. Limit the Scope: Keep your Update Sets focused on specific changes related to a
particular project or enhancement to make tracking easier.
2. Avoid Conflicts: Be cautious when working with multiple developers or teams; ensure
that they are not modifying the same elements simultaneously, which can lead to
conflicts.
3. Test Before Applying: Always test Update Sets in a sub-production instance before
applying them to production. This helps identify any potential issues.
 4. Document Changes: Use the description field to document what changes are included in
the Update Set. This can help during the review process.
5. Regularly Cleanup: Regularly review and clean up Update Sets that are no longer
needed to keep your environment organized.
Changes Tracked by Update Sets
1. Forms and Fields:
o Modifications to existing forms (e.g., adding/removing fields, changing field
types).
o Changes to field properties (e.g., labels, help text, default values).
2. Tables:
o Creation and modification of tables.
o Changes to table relationships (e.g., creating or modifying reference fields).
3. Business Rules:
o Creation and modifications of business rules, including script changes.
4. Client Scripts:
o Changes to client scripts that run on the client side to manipulate form fields.
5. UI Policies:
o Modifications to UI policies, including conditions and actions.
6. Access Control Rules:
Changes Not Tracked by Update Sets
1. Data Records:
o Individual data records (e.g., incidents, problems, changes) are not tracked. Only
schema changes (like new fields or changes to tables) are captured.
2. System Properties:
o Changes made to system properties are not captured by Update Sets. You need to
manually document and transfer those if necessary.
3. Out-of-the-box (OOB) Changes:
o Changes made to out-of-the-box elements in ServiceNow may not be tracked
effectively, especially if they involve modifications that conflict with future
updates.
4. User Roles and Groups:
o Changes to user roles, groups, or permissions are not tracked. These need to be
managed separately.
 5. Some Configuration Changes:
o Certain configuration changes, especially those made directly to the platform
settings or configurations that do not have an associated record in the system (like
some UI settings), may not be tracked.
6. Non-Catalog Items:
o Changes made to non-catalog items or custom applications may not be captured in
Update Sets.
7. Attachments and Comments:
o Attachments and comments associated with records are not tracked.
8. Knowledge Base Articles:
o Changes to knowledge base articles and their metadata are not tracked.
Summary
Update Sets are a powerful feature for tracking and transferring specific configuration changes
within ServiceNow, focusing primarily on customizations to tables, forms, scripts, workflows,
and similar elements. However, they do not capture data records, system properties, and various
configuration changes that are essential for the complete migration and management of an
instance. Therefore, it is crucial for administrators to have a clear understanding of what is
tracked and what is not to ensure a smooth development and deployment process.
Backout update set
backout refers to the process of reverting or undoing changes applied through an update
set. It’s a way to roll back an update set's changes if something goes wrong or the changes are
no longer needed.

Why is Backout Needed?

1. Error in Changes:
o If the update set introduces bugs, errors, or breaks functionality after deployment.
2. Incorrect Deployment:
o If the wrong update set is deployed to an environment.
3. Incomplete Testing:
o If the changes haven't been fully tested or validated but were prematurely
deployed.
4. Conflict with Existing Configuration:
o If the update set conflicts with already-existing configurations in the environment.

 Backout Process:
  A backout can be performed on an update set that is imported but not yet
committed in the target instance.
 For example:
o If you import an update set into the test environment and decide not to
commit it, you can back it out there, and the changes will not apply.
o However, once the update set is committed, the backout option is no longer
available.
 Environment Independence:
 After an update set is committed in a target instance (e.g., Test or Production), it is
treated as a separate process from its source instance (e.g., Development).
 Backing out the update set in Development will not roll back changes in Test or
Production because these instances are independent of each other.
 Why Backout is Important:
 The reasons listed earlier—errors, incorrect deployments, incomplete testing, and
conflicts—are all valid for backing out an update set before committing it in the
target environment. If you realize an issue after committing, you will need to
manually revert the changes or deploy a new update set to undo them.
You are absolutely right that backout refers to reverting or undoing changes made by an update
set. However, my earlier statement that backing out an update set in one instance (e.g.,
Development) does not affect another instance (e.g., Test or Production) still holds true.
Here's the Clarification:
1. Backout Process:
o A backout can be performed on an update set that is imported but not yet
committed in the target instance.
o For example:
 If you import an update set into the test environment and decide not to
commit it, you can back it out there, and the changes will not apply.
 However, once the update set is committed, the backout option is no longer
available.
2. Environment Independence:
o After an update set is committed in a target instance (e.g., Test or Production), it is
treated as a separate process from its source instance (e.g., Development).
o Backing out the update set in Development will not roll back changes in Test or
Production because these instances are independent of each other.
3. Why Backout is Important:
 o The reasons listed earlier—errors, incorrect deployments, incomplete testing, and
conflicts—are all valid for backing out an update set before committing it in the
target environment. If you realize an issue after committing, you will need to
manually revert the changes or deploy a new update set to undo them.

Example to Clarify:
Scenario:
 You create an update set in Development and push it to the Test environment.
 The update set introduces bugs in the Test environment.
Options in Test Environment:
1. Backout (if not committed yet):
o You can back out the update set before committing, and the changes won't be
applied.
2. Manual Reversion (if committed):
o If you've already committed the update set, backout is no longer an option. You
must either:
 Create a new update set to undo the changes.
 Manually remove or revert the changes.
Impact on Development Environment:
 Backing out or modifying the update set in Development does not undo changes in Test
or Production because they are independent environments.
Plugins
In ServiceNow, plugins are add-on modules that provide additional functionalities, features, or
integrations to enhance the core capabilities of the platform. They are pre-built applications or
components created by ServiceNow that allow you to enable specific functions without
extensive custom development.
Key Aspects of Plugins
1. Purpose: Plugins extend the core functionality of ServiceNow to meet various business
requirements, such as IT Service Management (ITSM), IT Operations Management
(ITOM), IT Asset Management (ITAM), and more.
2. Activation: Most plugins can be enabled directly in the instance, but some may require
specific permissions, licensing, or requests to ServiceNow support. Admin users can
activate plugins from System Definition > Plugins.
3. Scoped Applications: Some plugins are scoped applications, meaning they are contained
in a defined namespace to separate them from the global scope and protect them from
unintentional changes.
4. Dependencies: Certain plugins may have dependencies on other plugins, meaning they
require other plugins to be activated first to function properly.
In ServiceNow, applications like Incident Management, Change Management, Problem
Management, and other ITSM-related modules are often provided as plugins. They are typically
pre-installed in the platform but may require activation, especially if they aren't enabled by
default in your ServiceNow instance.
Key Points about Plugins in ServiceNow
1. Default Plugins: Some plugins come pre-activated, depending on the ServiceNow
edition or version (like Incident Management, change management, problem
management, discovery, orchestration, event management, and Service Catalog in most
ITSM-focused instances).
2. Optional Plugins: Many other applications or advanced features are available as plugins
but need to be activated manually. For instance, if you see a module in the Application
Navigator but can't access it, it's likely because the plugin hasn't been activated.
3. Plugin Activation: You can activate plugins as an admin:
o Navigate to System Definition > Plugins.
o Search for the desired plugin by name (like "Incident Management" or "Change
Management").
o Click on the plugin, and then click Activate/Upgrade.
4. Dependent Plugins: Some plugins have dependencies, meaning activating one might
automatically enable another.
Access Control List
https://www.servicenow.com/docs/bundle/xanadu-platform-security/page/administer/
contextual-security/concept/acl-rule-types.html

Any table > hamburger menu > security rules :- you can see the acls attacted to that table
In ServiceNow, an Access Control List (ACL) is a set of rules that defines what data users can
access and what operations they can perform on that data. The ACL governs security by
controlling user access to tables, fields, and records based on conditions, roles, or scripts.
In ServiceNow, Access Controls (ACLs) can be created or customized by users with the
security_admin role. While users with the admin role have broad access to the system, they
cannot modify or create ACL rules without elevating their privileges to security_admin.
Key Aspects of ACL in ServiceNow:

Security Rules:

ACL rules specify the permissions required to access a resource, such as a table,
record, or field in ServiceNow.

Each ACL rule specifies:

Object: The table or field the rule applies to.

Operation: The type of access (e.g., read, write, delete).

Condition: The criteria that must be met for the rule to apply.

Roles: The user roles required for access.

Script: Optional JavaScript that can provide additional logic to control access.

Types of Operations in ACL:

Read: Grants a user permission to view data.

Write: Grants permission to modify or create data.

Create: Grants permission to create new records.

Delete: Grants permission to delete records.

Execute: Grants permission to execute UI actions or scripts.

“ACL with operation execute doesn't restrict the user from running business rules or
UI policies or client scripts. It is mainly used for client callable script includes and
Rest endpoint executions”
 list_edit : access to update data from list view

report_on : grants access to create report

Order of Execution:

Record ACL rules are processed in the following order:

 Match the object against table ACL rules.

 Match the object against field ACL rules.

This processing order ensures that users gain access to more specific objects before gaining
access to more general objects. A user must pass both table and field ACL rules to access a
record object.
 If a user fails a table ACL rule, the user is denied access to all fields in the table, even if
the user passes a field ACL rule.
 If a user passes a table ACL rule, but fails a field ACL rule, the user cannot access the
field described by the field ACL rule.

Table-level vs Field-level ACLs:

Table-level ACL: Controls access to the entire table.

Field-level ACL: Controls access to specific fields within a table. For example, a user
may be able to read a record but not be able to see or edit certain sensitive fields.

Example of ACL Rule: Suppose you want only users with the "admin" role to delete
incidents. You would create a rule for the incident table with the operation delete and specify
that only the admin role can perform this operation.

7.
o Changes to access control lists (ACLs) that control record access.
o Access control is a record in the sys_security_acl
o Access control are assigned to roles
o Roles are assigned to groups
o Groups are assigned to users
o Roles can directly be assigned to users but it’s a best practice to assign roles to
groups.
8. Email Notifications:
o Modifications to email notifications, including template changes.
9. Workflows:
o Changes to workflows and associated activities.
 10.Script Includes:
o Creation and changes to script includes used for server-side scripting.
11.Scheduled Jobs:
o Modifications to scheduled jobs that automate processes.
12.Business Services:
o Changes related to IT service management, including changes to business services.
Tables
A table is a collection of records in the database. Each record corresponds to a row in a table,
and each field on a record corresponds to a column on that table. Applications use tables and
records to manage data and processes
The table name can only be lowercase and contains underscore.
Tables created by user are prefixed with u (for eg :- u_my_custome_table)
We can also provide roles to a new table that will provide ACL to the created table.
For deleting a table first delete all records of the table. Deleting a table delete all the related
links, acls, references of that table.
Out of box tables cant be deleted like (problem, incident, user, group). Only user created tables
can be deleted
Extended tables :- we can also inherit table in servicenow, there can be a parent table and a
child table (inherited from parent table) , like incident table is inherited (extended ) from task
table.
We can view the schema map of the table to see a map that shows which table is extended or
referenced from the selected table.
In ServiceNow, when a table like the Incident table is extended from a parent table like the
Task table, it inherits all fields from the parent table (Task) but shows only a subset of those
fields by default on the Incident form view. This means:
1. Inherited Fields Are Available: All fields from the Task table are still available in the
Incident table, so you can use or reference these fields in forms, workflows, and scripts.
2. Limited Fields Displayed on the Form by Default: The Incident form shows only the
fields configured specifically for it by default. Fields inherited from the Task table won’t
automatically appear on the Incident form unless you add them manually.
3. Adding Task Fields to Incident Forms:
o You can customize the form view for Incident to include additional fields from the
Task table if needed.
o To do this, go to Form Layout (right-click on the form header and choose
Configure > Form Layout) and add the required fields from the Task table to the
Incident form.
4. Usage in Business Rules, UI Actions, etc.: Even if these fields aren’t visible on the
Incident form, they can still be referenced and used in scripts, business rules, UI actions,
or other parts of ServiceNow for Incident records.
Application studio :-
Only works for scope application not for global application
Delegate Users
In ServiceNow, delegate in a user record refers to assigning another user the ability to act on
behalf of the original user for certain tasks or actions. This is often done when the original user
is unavailable (e.g., on vacation or leave) and someone else needs to manage their
responsibilities temporarily.
When a user delegates their role, the delegate can:
 Approve or reject requests.
 Receive notifications on their behalf.
 Perform tasks like managing incidents, change requests, or service catalog tasks,
depending on the specific permissions given.

LDAP
LDAP is used to authenticate and manage user credentials by connecting to a central directory
service like Active Directory (AD).
 Purpose: LDAP integration helps ServiceNow sync users, groups, and roles from
external directory services (such as Microsoft AD) to manage authentication and user
provisioning centrally.
 How it works:
o ServiceNow does not store user passwords directly but communicates with the
LDAP server to verify user credentials.
o Users enter their credentials in ServiceNow, which forwards them to the LDAP
server for validation

Key benefits:
 Centralized user management: Manage user access from a single directory.
 Sync groups and roles: ServiceNow can import groups and roles directly from LDAP
directories.

In an enterprise environment, user data (like usernames, passwords, roles, and other details) is
typically stored in a centralized database or directory service, such as Active Directory (AD)
or another LDAP-compliant directory. Here's how LDAP fits into this process:
 1. Data Storage: User information (such as usernames, passwords, departments, roles, etc.)
is stored in an LDAP directory, like Active Directory or other directory services. This
directory serves as a central repository for managing users across the organization.
2. Authentication with LDAP: When a user tries to log in to an application (like
ServiceNow or other enterprise systems), the application uses LDAP to verify the user's
credentials.
o The application sends the username and password to the LDAP server.
o The LDAP server checks the provided credentials against the stored information.
o If the credentials match, the user is authenticated and allowed access to the
application.
3. Authorization: After authentication (i.e., confirming the identity of the user), the
application can also check additional attributes, such as the user’s role, to determine what
resources or actions the user is authorized to access.
4. Enterprise Database for Other Data: While LDAP is primarily used for authentication
and storing user profiles and credentials, other business data (such as records,
transactions, etc.) is typically stored in separate databases or systems (e.g., SQL
databases, NoSQL databases). LDAP handles the user management part.

LOOKUP
Data Lookup in ServiceNow is a feature used to automatically set field values in a record
based on specific conditions. It simplifies the process of populating fields by matching criteria
from one or more fields and using predefined mappings to determine the appropriate value for
another field.
How Data Lookup Works:
Data Lookup rules allow administrators to define which fields should be automatically
populated based on certain conditions. It works by comparing the current record’s data with
predefined rules and then setting the matching values in target fields.
Key Components of Data Lookup:
1. Data Lookup Rule: A rule that defines which field(s) should be evaluated and how the
matching field(s) should be populated.
2. Data Lookup Table: A table that contains mappings between the source fields and target
fields. It stores the reference data used to make decisions about what values should be
populated. This table ends to be extended from Data lookup matcher rule table
3. Condition Fields: The fields that trigger the data lookup action. When conditions on
these fields are met, the rule will apply.
 4. Target Fields: The fields that will be automatically populated based on the result of the
data lookup.
1️⃣ Create a Data Lookup Table (or Matcher Table)
 This table stores the mapping of conditions and values that will be used to automatically
populate fields.
2️⃣ Create a Data Lookup Definition
 Defines the relationship between the source table (where the data comes from) and the
lookup table (where predefined values are stored). Set the matcher field and setter field.
 Specifies which fields should be auto-populated when certain conditions are met.
3️⃣ Create Data Lookup Rules
 Defines the conditions for when the lookup should be applied.
 Maps the input field (triggering field) to the output field (auto-filled field).

No, Data Lookup in ServiceNow cannot be used directly to filter the options available in a
dependent field (like filtering Subcategory based on Category).
Why?
 Data Lookup is used to auto-populate fields, not dynamically filter choices.
 It can set a single value in a field but cannot dynamically update dropdown options
based on another field's selection.

Solution: Using a Reference Qualifier ✅

To achieve dynamic filtering of the Subcategory field based on the Category, you should use a
Reference Qualifier (dynamic filtering with GlideAjax or Script Include).
Step 1: Create the Category and Subcategory Fields
1. Go to System Definition → Tables → Open Incident Table (incident)
2. Check if the following fields exist:
o category (Type: Choice) ✅
o subcategory (Type: Choice) ✅
If not, create them.

Step 2: Add Choices to the Category Field

 Open the category field in incident table.
 Add the following choices:
Value Label
A A
B B
C C

Step 3: Add Choices to the Subcategory Field

 Open the subcategory field in incident table.
 Add the following choices:
Value Label Dependent Value (Category)
1 1 A
2 2 A
3 3 A
4 4 A
5 5 B
6 6 B
7 7 B
8 8 B
9 9 C
10 10 C
11 11 C
12 12 C
Step 4: Set the Dependent Field
1. Open the subcategory field.
2. Check the Use Dependent Field option.
3. Set Category as the dependent field.

what to do if category and subcategory both are variables ?

If both Category and Subcategory are variables in a Service Catalog item, you cannot use the
"Use Dependent Field" option (since that only works for choice fields in tables). Instead, you
must use a Lookup Select Box or Client Script to dynamically filter the Subcategory based on
the selected Category.
Lookup Select Box Method in ServiceNow
The Lookup Select Box is used in Service Catalog to dynamically filter options based on
another field’s selection. It is helpful when dealing with dependent fields, such as Category and
Subcategory, where the subcategories depend on the selected category.

Steps to Implement Lookup Select Box for Dependent Dropdowns

1️⃣ Create a Table for Category-Subcategory Mapping
Since the Lookup Select Box pulls data from a table, you need to store category-subcategory
pairs in a custom table.
1. Navigate to System Definition → Tables.
2. Click New to create a new table:
o Name: u_category_subcategory
o Columns:
 u_category (Type: String or Reference to the Category table)
 u_subcategory (Type: String)
3. Populate this table with the following values:
Category (u_category) Subcategory (u_subcategory)
A 1
A 2
A 3
A 4
B 5
B 6
B 7
B 8
C 9
C 10
C 11
 Category (u_category) Subcategory (u_subcategory)
C 12

2️⃣ Create a Category Variable

1. Go to Maintain Items → Select your Catalog Item.
2. Add a new variable:
o Type: Single Choice or Select Box
o Question: Category
o Name: category
o Choices:
 A
 B
 C

3️⃣ Create a Subcategory Variable (Lookup Select Box)

1. Add another variable:
o Type: Lookup Select Box
o Question: Subcategory
o Name: subcategory
o Table: u_category_subcategory
o Reference Qualifier: u_category=javascript:getCategory()

4️⃣ Add a Reference Qualifier (Dynamic Filtering)

A Reference Qualifier ensures that only subcategories related to the selected category appear.
1. Navigate to the Subcategory variable.
2. Find the Reference Qualifier field.
3. Set it to:
ini
CopyEdit
u_category=javascript:getCategory()
4. Create a Client Script (Type: OnChange) for the Category variable:
javascript
CopyEdit
function getCategory() {
return g_form.getValue('category');
}

SLA
SLAs in ServiceNow:
In ServiceNow, SLAs can be attached to records (like Incidents, Problems, Requests, etc.) to
track and enforce timelines. Here's how they work:
1. SLA Definitions: In ServiceNow, you define an SLA through the SLA Definition
module. This includes:
o The type of SLA (SLA, OLA, UC).
o The task table it applies to (e.g., Incident, Request).
o There are 2 targets – response, resolution
o The conditions for when it should start, pause, reset or stop.
o The timeline for response and resolution.
2. SLA Workflow: ServiceNow uses workflows to track SLAs:
o If an incident is created, the SLA clock starts.
o The system monitors the SLA progress.
o If the SLA is breached (not met within the specified time), notifications can be
sent, and escalations can happen.
3. SLA Breach and Escalation: If the service provider fails to meet the SLA, it can trigger
escalations, notifications, or additional actions (such as flagging the issue, reassigning to
higher-priority support teams, or sending reminders).
4. SLA Indicators:
o Breached: Indicates that the SLA commitment has been violated (e.g., the ticket
wasn’t resolved within the given timeframe).
o In Progress: Shows that the SLA is still active and has not been breached yet.
o Met: Shows that the SLA has been successfully completed.
Example in ServiceNow:
  An Incident is created for a user’s request, and based on the priority of the incident (like
High Priority), an SLA gets applied to ensure that it will be responded to in 1 hour and
resolved within 4 hours.
 The SLA timer starts when the incident is opened.
 If the incident isn't resolved within the defined time, the SLA is breached, and an alert is
sent to the manager.
Benefits of SLAs:
 Accountability: Ensures service providers are responsible for meeting performance
standards.
 Customer Satisfaction: Helps maintain and improve customer trust by ensuring timely
resolution of issues.
 Performance Tracking: Provides metrics for monitoring service performance, which
can help in future improvements.
Note :- SLA’s are set to pause when resolved and to stop when closed, because an incident (or
problem or change etc) can go from resolved state to new state again if not resolved properly.
OLA (operational level agreement)
an Operational Level Agreement (OLA) is a type of agreement that defines the internal
service support agreements between different teams or departments within an organization.
These agreements are critical to ensuring that teams collaborate effectively to meet overall
Service Level Agreements (SLAs) committed to end users or customers.
Key Concepts of OLA in ServiceNow
1. Definition:
o An OLA is a documented agreement between internal support teams to ensure they
fulfill their respective responsibilities to achieve SLA compliance.
o Example: A network team agrees to resolve connectivity issues within 2 hours to
support the SLA for incident resolution.
2. Purpose:
o To align internal operations and ensure seamless collaboration between teams.
o To track and measure performance at the team level, enabling accountability.
3. Relation to SLA:
o While SLAs focus on commitments to customers, OLAs focus on commitments
between internal teams to support those SLAs.
o OLAs act as a building block to meet SLA goals.

How OLAs Work in ServiceNow

 1. Creation of OLAs:
o OLAs are configured similarly to SLAs in ServiceNow, using the Service Level
Management (SLM) module.
o They are applied to specific internal tasks or workflows (e.g., incident tasks,
change tasks).
2. Application:
o When a task or record matches the conditions for an OLA, a timer is started to
track whether the internal team meets the agreed-upon timeline.
o Example: An incident assigned to the "Database Team" might have an OLA
requiring resolution within 4 hours.
3. Tracking:
o ServiceNow tracks OLA compliance using timers and provides insights into
whether internal teams are meeting their obligations.
4. Escalation:
o Alerts or notifications can be triggered if an OLA is at risk of being breached,
ensuring proactive management.
An Underpinning Contract (UC) in ServiceNow (and IT Service Management in general) is
an agreement between an internal service provider or organization and an external vendor
(third-party supplier). This contract supports the service provider's ability to meet the Service
Level Agreements (SLAs) made with customers.
In other words, UCs ensure that external vendors fulfill their commitments to help the service
provider achieve the required service levels for customers.

Key Features of Underpinning Contracts

1. Purpose:
o To define the obligations, deliverables, and service levels that the vendor must
meet.
o Ensures external support aligns with the internal SLAs and OLAs.
2. Parties Involved:
o Internal Service Provider: The organization providing services to customers.
o Vendor/Third-Party Supplier: The external entity contracted to deliver specific
services or support.
3. Alignment with SLA:
o UCs are designed to support the SLAs and may include similar performance
metrics (e.g., response time, resolution time).
 o Example: If the SLA with the customer requires a 4-hour resolution time, the UC
with the vendor may stipulate a 2-hour delivery time for parts or services.
Example of Underpinning Contract
Scenario:
 Customer SLA: A customer-facing SLA for IT support promises critical hardware
replacements within 4 hours.
 UC Details:
o Vendor: Third-party hardware supplier.
o UC Requirement: Vendor must deliver the replacement hardware within 2 hours
of receiving the request.
Alignment:
 The 2-hour delivery time in the UC ensures the service provider has enough time to
install and test the replacement hardware to meet the 4-hour SLA.
Use Case in ServiceNow
In ServiceNow, UCs are not directly tracked like SLAs or OLAs, but their effects are evident in
the performance of SLAs. Vendors' adherence to UCs can be monitored through:
 Vendor Management: Using vendor management modules.
 SLA Breach Analysis: Identifying breaches caused by external dependencies.
 Custom Workflows: Implementing workflows that track vendor performance

Comparison of Focus Areas

Agreement Type Primary Focus
SLA Response time, resolution time, availability, performance, penalties.
OLA Internal team collaboration to meet SLA (response and resolution times).
UC Vendor obligations to support SLA (response time, delivery, dependencies).

System properties & Basic Configuration

Yes, in ServiceNow, basic configuration settings are stored in the sys_properties table. This
table holds system properties that control various aspects of the platform's behavior. These
properties can be configured to modify the functionality, performance, and appearance of the
ServiceNow instance.
Each property in the sys_properties table includes:
 Name: The unique identifier for the property.
  Value: The value assigned to the property (e.g., true/false, a number, or a string).
 Description: A brief explanation of what the property controls.
System properties can be accessed and updated by navigating to System Properties under the
System Definition module or by directly modifying the records in the sys_properties table.
DASHBOARD
In ServiceNow, dashboards serve as a powerful tool for visualizing data, monitoring key
metrics, and tracking performance across various processes. Dashboards provide users with
real-time, customizable views of important information, offering insights that help teams
manage and optimize workflows. Here's a detailed overview of the purpose and functions of
dashboards in ServiceNow:
Purpose of Dashboards in ServiceNow:
1. Real-Time Data Monitoring:
o Dashboards provide real-time updates on key metrics and data from various
modules within ServiceNow, such as incident management, problem management,
change management, and service requests. This allows users to track performance,
spot trends, and take immediate action when necessary.
2. Customizable Views:
o Users can create customized dashboards that focus on specific KPIs or areas of
interest. For example, a service desk manager might build a dashboard to track
incident resolution times, open tickets, and agent performance, all in one view.
3. Centralized Information Hub:
o Dashboards aggregate information from different areas of ServiceNow (e.g.,
incidents, problems, requests, and changes) into a single, easy-to-read interface.
This helps teams and managers get a comprehensive overview of operations
without having to access multiple modules or reports individually.
4. Data-Driven Decision Making:
o The visual representation of data on dashboards helps users make informed, data-
driven decisions. By reviewing charts, graphs, and widgets that reflect real-time
performance, teams can identify bottlenecks, efficiency improvements, and
potential issues before they escalate.
5. Performance Tracking and Reporting:
o Dashboards allow managers and team members to track the performance of
services, teams, or individual agents. You can monitor metrics like incident
response time, change success rate, SLA compliance, and more, using widgets
that display the data in graphs, lists, or gauges.
6. Collaboration and Sharing:
 o Dashboards can be shared across teams or with specific users, enabling
collaboration and transparency. For example, senior leadership can share a
dashboard showing high-level performance metrics with stakeholders, while
individual teams can create detailed dashboards to track daily tasks and
performance.
7. Enhanced Visibility for SLAs:
o Dashboards can also display Service Level Agreement (SLA) compliance,
helping users keep track of deadlines, performance against targets, and areas where
improvement is needed. This is especially useful for ensuring that the IT service
management (ITSM) processes are meeting predefined business goals.
8. Automation and Workflow Efficiency:
o By integrating dashboards with automated workflows, teams can monitor process
efficiency and performance. For instance, if a dashboard shows that incidents are
not being resolved within the SLA time frame, automatic escalations or alerts can
be triggered to ensure timely resolutions.
Common Components of Dashboards:
1. Widgets:
o Widgets are the building blocks of dashboards and can display various types of
data such as charts, graphs, lists, gauges, and scorecards. ServiceNow offers many
pre-built widgets, but users can also create custom widgets to display specific data.
2. Filters:
o Dashboards can include filters that allow users to drill down into specific datasets,
such as filtering incidents by state (open, resolved) or time range. Filters enhance
the usability and relevance of dashboards for different user roles.
3. KPIs (Key Performance Indicators):
o Dashboards often feature KPIs that track critical metrics and objectives, helping
users keep an eye on performance benchmarks and areas that need attention.
4. Reports:
o Dashboards can integrate reports that display detailed analytics and data trends.
These reports can be visual (charts, graphs) or data tables, offering a clear
breakdown of performance and activities.
5. Interactive Elements:
o ServiceNow dashboards can include interactive elements, such as click-throughs,
which allow users to drill down into specific reports or tasks directly from the
dashboard.
Use Cases for Dashboards in ServiceNow:
  Incident Management: Monitoring the number of open incidents, average resolution
times, and incident trends.
 Change Management: Tracking the number of open changes, approval status, and
success rates of changes implemented.
 SLA Tracking: Displaying SLA compliance, overdue tasks, and upcoming deadlines.
 Executive Reporting: Creating high-level dashboards for management that show service
performance, cost savings, and business impact.
 Problem Management: Monitoring root cause analysis and resolution efforts across
multiple problems.
In summary, dashboards in ServiceNow provide a unified and customizable platform for data
visualization, helping teams to stay informed, act quickly, and make better business decisions
by leveraging real-time data and insights.

 Service now has a mobile app(native) :- android and ios

 Service now also has a mobile web app
 You can also open your instance on the mobile app.
 To see current version of your instance search stats.do on navigator
 We can on the javasvript log from preferences (settings gear), and we can also watch a
filed and actions being performed on that filed by clicking on the filed and clicking on
watch, so we can see the info in javascript logs.
 We can also whitelist or blacklist IP addresses in System security > IP address control
EVENTS
In ServiceNow, events are actions or occurrences that are triggered by scripts, workflows, or
user activities. Events are primarily used to communicate that something significant has
happened within the platform, allowing for the execution of subsequent actions like sending
notifications, running scripts, or updating records. These events are part of the platform’s event-
driven architecture.
Key Components of Events in ServiceNow:
1. Event Generation:
o Events are generated by Business Rules, Workflow activities, or other server-side
logic. For example, an event might be triggered when an incident is resolved or a
record is updated.
2. Event Queue:
o When an event is triggered, it gets placed in the Event Queue (sysevent table).
The queue holds pending events until they are processed.
o The event queue ensures that the events are executed at the appropriate time
without overloading the system.
 3. Event Processing:
o ServiceNow processes events from the queue and takes the defined action, such as
sending an email, running a script, or updating a field.
4. Event Registry:
o The Event Registry (sysevent_register table) is where all possible events are
registered in ServiceNow. Only registered events can be used and triggered.
o Events can be pre-defined (such as incident.assigned) or custom events that
developers create for specific actions.
5. Notifications:
o Events are commonly used to trigger notifications. For example, you can
configure the platform to send an email when a specific event, like incident.closed,
occurs.
6. Scripting with Events:
o You can use server-side scripting to create and trigger custom events using the
gs.eventQueue() function in Business Rules, Script Includes, or other scripts.
o

gs.eventQueue(eventName, current, parm1, parm2);

Parameters:
1. eventName (String) – The name of the event to trigger (must be registered in the Event
Registry).
2. current (GlideRecord) – The record from which the event is triggered.
3. parm1 (String) – Optional parameter; can store additional data like an email address.
4. parm2 (String) – Optional parameter; can store additional data.

ServiceNow HI (HealthScan Instance) is a support platform provided by ServiceNow to

manage, monitor, and ensure the health of your ServiceNow instances. HI provides tools and
dashboards for tracking the overall performance, availability, and best practices compliance of
your ServiceNow instances.
Key Features and Purpose of ServiceNow HI:
1. Instance Health Monitoring:
o HI monitors the performance and availability of your ServiceNow instance,
including CPU usage, memory, disk space, and transaction times.
o It provides real-time insights and alerts in case of performance degradation,
helping administrators take quick actions to maintain the stability of the system.
2. Automated Health Scans:
 o HI performs periodic health checks, called HealthScans, to ensure that the
instance is configured according to best practices. It checks for areas like
customization, security settings, and upgrade readiness.
o The scan provides recommendations on fixing issues, optimizing performance, and
maintaining system health.
3. Upgrade and Patch Management:
o ServiceNow HI helps in managing instance upgrades by giving visibility into the
current version, upgrade schedules, and upgrade status.
o It helps you plan upgrades by showing which updates are available and tracking
the progress of upgrade tasks.
4. Proactive Issue Detection:
o HI continuously checks the instance for issues related to performance, errors, or
security vulnerabilities. It proactively alerts administrators if any issues are
detected.
o It helps in minimizing downtime and improving the overall reliability of the
platform.
5. Compliance and Best Practices:
o HI checks your instance for compliance with ServiceNow best practices. It reviews
configurations, customizations, integrations, and security settings to ensure the
instance remains efficient and secure.
o It provides a Health Dashboard that gives administrators a summary of
compliance status and areas for improvement.
6. Incident and Case Management:
o If an issue arises, you can open a case through HI to get assistance from
ServiceNow support. The HI portal provides direct access to the ServiceNow
support team and allows you to track and manage open support cases.
o You can also view historical cases and resolutions for better tracking.
7. Audit and Log Reports:
o HI provides tools for tracking audit logs, ensuring that changes made to the
instance are properly recorded and monitored.
o It helps you meet compliance and audit requirements by maintaining transparency
and traceability for all modifications.
8. Communication with ServiceNow Support:
o The HI portal serves as a communication hub for interaction with the ServiceNow
support team, including managing service requests, incidents, and upgrades.
9. Performance Analytics:
 o The HI portal offers detailed analytics and reports that provide insights into how
the instance is performing, helping administrators identify performance
bottlenecks and optimize system performance.
Purpose of ServiceNow HI:
 Ensuring System Stability: HI helps monitor the instance for performance, availability,
and potential issues, ensuring that the ServiceNow platform remains stable and efficient.
 Proactive Maintenance: By running health scans and audits, HI helps administrators
identify potential issues before they become problems, enabling proactive system
maintenance.
 Facilitating Upgrades: HI manages and tracks instance upgrades, ensuring that upgrades
are applied smoothly and the instance remains up-to-date.
 Compliance and Security: HI ensures that the instance follows best practices, helping
maintain compliance with ServiceNow's guidelines and security standards.
 Faster Resolution: When issues occur, HI enables easy communication with
ServiceNow support to resolve them quickly and efficiently.
The Script Debugger in ServiceNow is a tool used by developers to troubleshoot and debug
server-side scripts, such as Business Rules, Script Includes, and other server-side scripts. It
helps you identify and fix issues by allowing you to step through code, inspect variables, and
understand the flow of the script execution.
Key Features and Uses of the Script Debugger:
1. Step-by-Step Execution:
o The Script Debugger allows you to execute your code one step at a time, pausing
at specific points (breakpoints) to inspect the code and see how it's behaving at
runtime. This helps in identifying logical errors or unexpected behavior in the
script.
2. Breakpoints:
o You can place breakpoints in your script, which will pause the script execution at
those specific points. This is useful for observing how the script behaves at key
stages and for debugging code logic at precise locations.
3. Variable Inspection:
o While the script is paused at a breakpoint, you can inspect the values of variables
in the current scope. This lets you see the state of the data at each point in the
script execution, helping to understand where things might be going wrong.
4. Call Stack:
o The debugger shows the call stack, which helps you understand the sequence of
function calls leading up to the breakpoint. This is useful for tracking the flow of
execution in complex scripts and identifying where errors might originate.
5. Conditional Breakpoints:
o You can set conditional breakpoints, which will pause the script execution only
when certain conditions are met. For example, you might want to pause execution
only when a particular variable has a specific value.
6. Real-time Debugging:
o The Script Debugger operates in real-time, allowing you to view and interact with
the script as it runs. This enables you to understand how the script is behaving on
the server at runtime, which is particularly helpful for debugging dynamic and
unpredictable issues.
Import Sets
Import Sets in ServiceNow is a feature used to import data from external sources (like files,
databases, or other systems) into ServiceNow tables. It provides a way to map the incoming
data to the appropriate ServiceNow tables and fields, making it a powerful tool for data
migration, integration, or bulk updates.
Key Concepts of Import Sets:
1. Data Source:
o Defines where the data is coming from (e.g., Excel, CSV, JSON, JDBC
connection).
o You set this up to identify the external source.
2. Import Set Table:
o A temporary table created to hold the imported data.
o It allows you to stage the data before transforming it to the target table.
3. Transform Map:
o Defines the mapping of fields between the import set table and the target table in
ServiceNow (e.g., map "user name" in an Excel sheet to the "Name" field in the
sys_user table).
o It may involve data transformations (like combining two columns or changing data
formats).
4. Target Table:
o The actual table in ServiceNow where the data is stored after transformation (e.g.,
Incident, Problem, Change, etc.).
5. Transform Process:
o Once the data is staged in the import set table, the transform process uses the
transform map to move the data into the ServiceNow target tables.
o Business rules and field validations can be triggered during this process.
6. Import Log:
o Provides detailed logs of the import process, including records that were
successfully transformed and any errors that occurred.
Steps to Perform an Import:
1. Load Data into an Import Set Table:
o Use the "Load Data" module to import data from the data source into the import
set table.
2. Create a Transform Map:
 o Define how fields from the import set map to fields in the target table.
3. Run the Transform:
o Run the transform process to move data from the import set table to the target
table.
4. Check for Errors:
o Review logs to ensure data was successfully imported and transformed.
Example Use Cases:
 Importing user data from an HR system.
 Migrating incident records from another ITSM tool.
 Updating asset records in bulk using a CSV file.
Import Sets simplify the task of bringing external data into ServiceNow, ensuring that the data
is clean and properly formatted before integrating it with core applications.
Coalesce in ServiceNow is a key feature used during the data import process to identify and
update existing records. When you set a field to "coalesce" during a transform map, it
essentially acts as a unique identifier for that record. If a match is found based on the coalesced
field(s), the system updates the existing record. If no match is found, a new record is created.
How Coalesce Works:
 If Coalesce is True (for one or more fields):
o The system searches for existing records in the target table based on the values of
the coalesced field(s).
o If a matching record is found, the system updates that record with the new data
from the import set.
o If no matching record is found, a new record is created.
 If Coalesce is False (for all fields):
o The system always inserts new records, regardless of whether a matching record
exists in the target table.
Transform MAP
https://developer.servicenow.com/dev.do#!/learn/learning-plans/xanadu/new_to_servicenow/
app_store_learnv2_importingdata_xanadu_transform_event_scripts
must read
Configuration Management
the core function of a Configuration Management Database (CMDB). A CMDB primarily
serves as a centralized repository for managing Configuration Items (CIs), which indeed
include IT assets such as software, hardware, network devices, and more. These CIs are
essential for understanding relationships and dependencies between IT resources, which helps
ensure better visibility and management across the IT environment.
Here’s a deeper look at the benefits you highlighted and the role a CMDB plays:
1. Centralized Data and Visibility: The CMDB consolidates siloed data from different
systems, making it accessible in a single location. This centralization allows IT
Operations to see the complete landscape of the IT environment, reducing the chances of
data being isolated.
2. Outage Prevention and Reduction: By understanding the dependencies and
relationships between various CIs, IT teams can quickly identify potential points of
failure or impacted services, which helps prevent outages. Additionally, in the event of an
outage, the CMDB provides critical insights to speed up remediation.
3. Compliance and Audit Support: CMDBs store detailed records of IT assets,
configurations, and their histories, which is invaluable for compliance and audit
requirements. This helps organizations avoid penalties for non-compliance and stay in
line with regulatory standards.
4. Informed Decision-Making: With insights into how CIs impact services and business
processes, the CMDB supports better risk assessment and reporting, enhancing decision-
making.
5. Cost Management: By tracking software licenses and cloud resources, the CMDB aids
in optimizing usage and controlling costs, preventing unnecessary expenditure on
underutilized assets.
all the CI classes have their own module ?
Yes, in a well-organized CMDB (Configuration Management Database), Configuration
Items (CIs) are typically categorized into different classes, and each CI class often has its own
module. These modules are structured to store, manage, and provide insights for each type of
CI, making the CMDB more organized and easy to navigate.
CI Classes and Their Modules:
1. Hardware: Includes physical devices like servers, routers, computers, and other
infrastructure. This module typically stores details such as specifications, serial numbers,
purchase date, location, and status.
2. Software: Contains applications, licenses, and operating systems. The software module
stores information on version numbers, licenses, installation date, associated contracts,
and compliance data.
3. Network Devices: Covers switches, routers, firewalls, and other network equipment.
This module may include details on IP addresses, configuration settings, vendor
information, and maintenance schedules.
4. Virtual Machines (VMs): Tracks VMs and associated resources, storing data like VM
instances, configurations, host servers, and resource allocations.
 5. Databases: Stores information on database instances, schemas, permissions, backups,
and associated applications.
6. Services and Applications: Includes major applications or services (like email, CRM
systems, etc.), with details on dependencies, uptime requirements, and related service
agreements.
7. Documentation and Knowledge: A module for supporting information, guides,
troubleshooting tips, and documentation for each class.
Benefits of Modular CI Classes in CMDB:
 Easier Management: Each module provides specialized fields and views suited to the
type of CI, making management more straightforward.
 Enhanced Organization and Searchability: Modules enable IT teams to locate specific
CI information quickly.
 Compliance and Reporting: Modular data structure makes it easier to generate reports,
track changes, and demonstrate compliance across different CI types.
So, each CI class having its own module allows for clear segmentation of data, making the
CMDB more efficient for IT operations, compliance, and auditing purposes.

Catalog Management
Catalog Management involves creating and maintaining a service catalog, which is a
comprehensive list of IT services offered by an organization. It provides users with information
about available services, including how to request them, their features, and associated service
levels.
Catalog Management in IT Service Management (ITSM) refers to the process of creating,
maintaining, and managing a Service Catalog—a centralized repository of all available IT
services offered to users or customers. It is a key component of IT service delivery that helps
streamline service requests, standardize service offerings, and improve user satisfaction.
Key Components of Catalog Management
1. Service Catalog: A structured list of all IT services that an organization offers, often
organized by categories (e.g., hardware, software, network, and support services). Each
service has a detailed description, availability, service level agreements (SLAs), pricing
(if applicable), and dependencies.
2. Service Offerings: Catalog management includes defining the specifics of each service.
This includes scope, description, target audience, fulfillment steps, cost, SLA, and any
dependencies on other services.
3. Approval and Request Processes: Catalog management streamlines how users can
request services, automates approvals, and provides guidance on fulfillment steps,
reducing delays.
 4. Service Level Agreements (SLAs): For each service in the catalog, defined SLAs
outline the time frames for request fulfillment and response, setting clear expectations for
service delivery.
5. Cost Management: Some catalogs track associated costs with services, allowing the
organization to charge back departments or understand IT expenses.
Benefits of Catalog Management
 Improves Efficiency: Catalog management automates and standardizes service request
processes, reducing manual intervention and speeding up fulfillment times.
 Increases Transparency: Provides a clear, accessible overview of all available services,
helping users understand their options.
 Enhances User Experience: A well-organized catalog with clear descriptions helps users
quickly find and request the services they need.
 Facilitates Self-Service: With an online service catalog, users can request services
directly, without needing to contact IT support.
Example of Catalog Management in Action
A company's IT Service Catalog might include offerings like:
 Hardware: Laptop procurement, desktop upgrades, printer setup
 Software: Software installation or license requests (e.g., Office 365, Adobe)
 Network: VPN setup, access requests for Wi-Fi, or firewall exceptions
 User Support: Password resets, troubleshooting, user training sessions
 Onboarding/Offboarding Services: Employee account setup or termination processes,
provisioning access to required applications, etc.
When an employee joins the company, they might request a new laptop and specific software
through the service catalog. Catalog management streamlines the request approval, tracks order
fulfillment, and ensures SLAs are met, making the process efficient and transparent for both IT
and the user.
Overall, catalog management simplifies the management and delivery of IT services by
centralizing, organizing, and automating service requests, which supports improved service
quality and customer satisfaction.

Operational Status of cI
Note: CIs that are not discovered for more than 60 days will be set to Retired state.

The meaning behind the values in the Operational Status can be explained as follows:

>> Operational = The CI is currently in use and functioning as expected. This status is used for
CIs that are active and performing their intended roles. Operational CIs may be actively
monitored and managed by ITOM and ITSM processes. Incidents and changes can be related to
these CIs. For example: A server that is currently hosting applications and services for the
organization.

>> Non-Operational = The CI is not currently in use or not functioning correctly. This status is
used for CIs that are either broken, in maintenance, or not required at the moment. These CIs
might be targeted for repair or maintenance work. Incidents and problems can be linked to these
CIs. For example: A server that is down for maintenance or experiencing a hardware failure.

>> Repair in Progress = The CI is currently undergoing repair. This status is used for CIs that
are being actively repaired due to malfunction or failure. During this status, incident
management processes might be involved. Change management might also track the repair
activities. Monitoring and alerting systems may suppress alerts for these CIs. For example: A
server that has experienced a hardware failure and is being repaired by the IT team.

>> DR Standby = The "DR Standby" (Disaster Recovery Standby) operational status for a
Configuration Item (CI) in ServiceNow indicates that the CI is part of a disaster recovery
(DR) plan and is in a standby state, ready to be activated in case of a disaster or failure of the
primary CI. This status is typically used for backup systems, redundant servers, or failover
infrastructure that is not actively in use but is prepared to take over if needed.

>> Ready = The CI is fully configured and ready for use but not yet put into operation. This
status is used for CIs that are fully set up and tested, waiting for deployment or activation. Asset
management might track this status to ensure that resources are available for deployment. ITSM
processes might involve change requests to move the CI to an operational state. For example: A
server that has been installed, configured, and tested but is waiting for a go-live date.

>> Retired = The CI is no longer in use but has not been disposed of. This status is used for CIs
that have been taken out of service but still exist in the inventory. Retired CIs may still have
historical records and data that are valuable for reporting and audits. For example: A server that
has been replaced by a new model but is still stored in a spare parts inventory.

>>Pipieline = The "Pipeline" operational status for a Configuration Item (CI) in ServiceNow
indicates that the CI is in the process of being deployed, configured, or provisioned, but it
is not yet ready for use. This status is typically used for CIs that are in the early stages of their
lifecycle, such as being ordered, built, or configured, but not yet operational.
1. Issues Related to the Deployment Process:
o If there is a problem with the deployment, configuration, or provisioning of the CI
(e.g., delays, errors, or failures), it is appropriate to create an incident to track and
resolve the issue.
o Example: A server in the pipeline is not being deployed on time due to a
configuration error.
Dependencies on the CI:
 If other systems, processes, or users are blocked or impacted because the CI in the
pipeline is not yet ready, an incident can be created to address the dependency issue.

Service catalog
There are many tables for service catalog
In ServiceNow (or similar ITSM platforms), the SC (Service Catalog) tables store various
aspects of service catalog requests and items. Here's an overview of what each of these tables
stores:
1. sc_request (Request Table):
o Purpose: Stores high-level information about a service request.
o Contents: Contains the overall details of the service request, such as requester
details, request date, status, and total cost. This is essentially a "parent" record for
multiple catalog items that may be included in a single request.
o Example: When a user submits a request for new hardware (e.g., a laptop and a
monitor), a single entry is created in the sc_request table to represent the request as
a whole.
2. sc_req_item (Requested Item Table):
o Purpose: Tracks each individual item within a service request.
o Contents: Contains detailed information about each catalog item requested,
including item name, cost, quantity, and status. Each request item (e.g., "Laptop"
or "Monitor") within a single sc_request will have its own record in sc_req_item.
o Example: If a user requests a laptop and a monitor, two separate entries are
created in the sc_req_item table—one for the laptop and one for the monitor.
3. sc_cart (Cart Table):
o Purpose: Represents a user's shopping cart before they finalize the request.
o Contents: Holds details of items that a user has added to their cart but has not yet
submitted. It temporarily saves the items and quantities until the user confirms and
submits the request.
o Example: When a user adds a laptop and a monitor to their cart but hasn’t yet
submitted the request, these items are stored in sc_cart.
4. sc_task (Catalog Task Table):
o Purpose: Stores individual tasks associated with fulfilling a service request.
 o Contents: Contains information about specific tasks needed to fulfill a request
item, including assigned group, task status, and task details.
o Example: For a "Laptop" request item, sc_task records could include "Procure
laptop," "Install operating system," and "Configure user settings." Each task is
assigned to different teams or users for completion.
5. sc_cat_item (Catalog Item Table):
o Purpose: Stores the definitions and configurations of catalog items that users can
request.
o Contents: Contains catalog item details like item name, description, pricing, and
associated workflows or approval processes. This table acts as the master list of all
available catalog items in the Service Catalog.
1. Order Guide
 Description: An Order Guide in ServiceNow allows users to order multiple catalog items
simultaneously as part of a single request.
 Purpose: It simplifies complex ordering processes by guiding users through a structured
sequence of questions or choices.
 Example: An "Employee Onboarding" order guide could include catalog items like
"Laptop," "Email Account Setup," and "Access Card" in a single guided ordering
process.
2. Record Producers
 Description: Record Producers are forms within the Service Catalog that create records
in any table of servicenow through more user friendly form view other than the default
service request tables. We can apply the script logic by taking details from variables to
fill the rest of the details of tha table
 Purpose: They help users submit specific types of requests, like incident reports or
service requests, without navigating directly to the target table.
 Example: A "New Hire Request" record producer could create a record in the HR case
table, automatically routing it to the appropriate HR team for processing.
3. User Criteria
 Description: User Criteria define the visibility and access permissions for Service
Catalog items, categories, and other resources.
 Purpose: They control which users can view or order catalog items based on attributes
like role, department, location, or other conditions.
 Example: You might create a User Criteria that only allows employees in the "IT"
department to request specific hardware upgrades.
4. Workflow
  Description: A Workflow in ServiceNow is an automated process that manages the
sequence of tasks or activities to fulfill a request.
 Purpose: Workflows streamline and automate the lifecycle of a service request, including
approvals, task assignments, notifications, and escalations.
 Example: A "Laptop Request" workflow could include tasks like manager approval,
inventory check, hardware configuration, and delivery notification.
5. Variable Sets
 Description: Variable Sets are collections of variables grouped together for reusability
across multiple catalog items.
 Purpose: They help organize related variables (form fields) for different catalog items
and reduce repetitive work by allowing common configurations.
 Example: A "Shipping Information" variable set could include variables for address,
contact number, and delivery instructions. This set could be reused across multiple
catalog items that require shipping details

Maintain Items –
has a list of all the catalog items in servicenow
Meta :- meta field in maintain item, can be used to put comma seperated keywords, so that if
the user search any of these keyword your CI will appear.
Annotations :- contains the description or hint that appears when we hover over an element.
Breakdown of Variables and Rule-Based Logic:
1. Variables:
o Purpose: Variables are the actual fields on the form where users enter information.
They can be different types, such as text fields, dropdowns, checkboxes, or date
pickers.
o Examples:
 For a "New Hire Request," variables could include fields like Employee
Name, Start Date, Department, and Role.
 Custom fields created specifically for catalog items or forms.
 They do not exist as columns directly in the main table (e.g., sc_req_item).
 Instead, they are stored in a separate table (sc_item_option and sc_item_option_mtom)
and are dynamically linked to the request.

2. Rule-Based Logic (Catalog Client Scripts, UI Policies, and Business Rules):

o Catalog Client Scripts:
  Function: Client-side scripts that run in the user’s browser to dynamically
show/hide fields, make fields mandatory, or change field values based on
user input.
 Example: If a user selects "Remote Work" as the employment type, a script
can display additional fields related to home office equipment.
o UI Policies:
 Function: Rules that control the visibility, mandatory status, or read-only
status of variables based on specific conditions. They help adjust the form
dynamically based on user responses.
 Example: A UI Policy can make the "Shipping Address" variable mandatory
if the user selects "Physical Goods" in a dropdown list.
o Business Rules:
 Function: Server-side rules that execute when records are created, updated,
deleted, or queried, often based on the values entered in variables.
 Example: After submission, a Business Rule could set the delivery location
or route the request to a specific team based on the selected department.
Knowledge Management / Knowledge Catalog
In ServiceNow, a Knowledge Base (KB) is a centralized repository of information that stores
articles, documents, and resources related to common issues, troubleshooting steps, and
solutions. It serves as a knowledge-sharing platform where both end-users and IT staff can
access solutions to problems, frequently asked questions, and other relevant information.
There are different knowledge bases and each knowledge base can have different categories.
Key Components of a Knowledge Catalog
1. Knowledge Articles:
o Individual pieces of content that provide information on specific topics.
o Articles can include text, images, links, and attachments.
2. Categories:
o Articles are organized into categories for easy navigation.
o Categories help users find relevant information quickly.
3. Search Functionality:
o Users can search for articles based on keywords, phrases, or topics.
o Effective search functionality enhances user experience by making information
easily accessible.
4. Approval Workflows:
 o Articles may go through an approval process before being published to ensure
accuracy and reliability.
o Workflows can include review by subject matter experts or knowledge managers.
5. Versioning and History:
o The Knowledge Catalog maintains a version history of articles, allowing users to
see changes over time.
o This feature is essential for compliance and tracking updates.
6. Feedback Mechanism:
o Users can provide feedback on articles (e.g., rating them or suggesting edits).
o Feedback helps improve the quality of knowledge content.
7. Integration with Service Catalog:
o Knowledge articles can be linked to service catalog items, providing additional
context or instructions for users.
Benefits of a Knowledge Catalog
1. Improved Efficiency:
o Reduces the time employees spend searching for information.
o Streamlines processes by providing easy access to documented procedures.
2. Consistency:
o Ensures that all users have access to the same information, promoting
standardization across the organization.
3. Empowerment:
o Enables users to find solutions independently, reducing the burden on support
teams.
o Increases user satisfaction by providing self-service options.
4. Knowledge Retention:
o Captures and preserves institutional knowledge, which can be particularly valuable
during staff turnover or transitions.
5. Enhanced Collaboration:
o Facilitates sharing of information across departments and teams, fostering a culture
of collaboration.

1. User Feedback on Knowledge Articles

 Users can provide feedback (comments, ratings, or suggestions) on knowledge articles.
  These feedback entries are stored as records in the "Knowledge Feedback" table
(kb_feedback).
 Feedback helps improve content quality by allowing admins to review and update
articles.
✅ Example:
A user reads an article on "Resetting Passwords" but finds it unclear. They submit feedback
suggesting a step-by-step guide with screenshots. The feedback is recorded, and the article is
improved accordingly.

2. Creating an Incident from a Knowledge Article

 If a knowledge article doesn’t resolve the issue, users can directly create an incident
from the article.
 This links the article to the incident, helping IT teams track which articles are ineffective.
 The incident includes article details for IT teams to reference.
✅ Example:
A user follows a troubleshooting article for VPN issues but still can’t connect. They click
"Create Incident", and a pre-filled incident form is generated with details of the article and
the user’s issue.

3. Knowledge Article Draft State Before Publishing

 When an article is created, it starts in the "Draft" state.
 Before being available for users, it goes through a review & approval process.
 Only after approval, the article moves to "Published" state and is visible to users.

I n ServiceNow, managing knowledge articles involves several processes and considerations,

including approval workflows, retirement of articles, incident creation from knowledge articles,
and user feedback. Here's a detailed overview of these components, along with information
about user criteria for reading knowledge articles:
1. Approval of Knowledge Articles
 Purpose: Ensures that knowledge articles are accurate, relevant, and meet organizational
standards before being published.
 Workflow: Typically involves a defined approval process where subject matter experts
(SMEs) or knowledge managers review and approve articles.
 Configuration: You can set up approval workflows in the Knowledge Management
module, where you specify who needs to approve articles based on categories or other
criteria.
2. Retirement of Knowledge Articles
 Purpose: To remove outdated or no longer relevant articles from the Knowledge Base.
 Process:
o Articles can be marked as Retired to indicate they are no longer current.
o Users can still see retired articles, but they are typically not accessible for new
incidents or requests.
 Configuration: In ServiceNow, you can retire an article by opening it and selecting the
Retire option, which might also involve a workflow for formal retirement.
3. User Criteria for Reading Knowledge Articles
 User Criteria: ServiceNow allows administrators to set user criteria to control who can
access specific knowledge articles based on various conditions.
 Factors:
o Role-based Access: Only users with certain roles (e.g., IT support, end-users) can
view specific articles.
o Group Membership: Access can be restricted to members of certain user groups
(e.g., department-specific knowledge).
o Conditions: You can set additional conditions based on attributes like location, job
title, or specific user attributes.
Configuration Steps for User Criteria:
1. Navigate to User Criteria: Go to Knowledge > User Criteria in the ServiceNow
application navigator.
2. Create or Edit User Criteria: Define new criteria based on roles, groups, or specific
conditions.
3. Assign User Criteria to Articles: When creating or editing a knowledge article,
associate the appropriate user criteria to control access.
approvers for knowledge articles are typically not set by default but can be configured based on
the organization's specific processes and requirements. The system provides flexibility in
defining approval workflows and assigning approvers.
Here’s how the approval process works:
1. Setting Up Approval Workflow:
 Knowledge Management Role Configuration: Administrators can define roles and
responsibilities for knowledge management, including who can approve articles. This can
include knowledge managers, subject matter experts (SMEs), team leads, or any other
designated personnel.
  Approval Rules: In ServiceNow, you can configure approval rules that automatically
assign specific users or groups as approvers when a new knowledge article is created or
updated. This can be based on factors such as:
o The category of the article
o The type of content (e.g., technical vs. non-technical)
o The knowledge base or department responsible for the article
 Approval Groups: You can create approval groups and specify that certain groups (e.g.,
IT, HR, Support, etc.) are responsible for approving knowledge articles related to their
domain.
2. Knowledge Article Workflow:
 Approval Tasks: When an article is created and saved, it can trigger an approval task
within ServiceNow. The article will be sent to the designated approvers for review and
approval. These approvers will receive notifications (either via email or in the
ServiceNow platform).
 Approval Process: Approvers can either approve or reject the article, and they may be
able to provide feedback for revisions. The approval process can include multiple stages
depending on the complexity and sensitivity of the content.
3. Customizing the Approval Process:
 Custom Approval Rules: If your organization has specific needs, you can create custom
approval workflows in ServiceNow using the Flow Designer or Workflow Editor.
These tools allow you to define more complex approval steps, such as:
o Conditional approvals based on specific criteria (e.g., approval required only for
articles that address critical issues).
o Multiple rounds of approval (e.g., review by a subject matter expert followed by a
higher-level manager).
 Notifications and Reminders: ServiceNow can send automatic notifications and
reminders to approvers to ensure that the approval process is not delayed.
4. Roles Involved in Approving Knowledge Articles:
 Knowledge Managers: Typically, knowledge managers oversee the knowledge base and
ensure that articles are accurate, relevant, and up-to-date. They are often the final
approvers before articles are published.
 Subject Matter Experts (SMEs): In technical or specialized areas, SMEs may need to
review and approve articles before they are published to ensure accuracy and
completeness.
 Team Leads/Managers: In some cases, team leads or department heads may be required
to approve articles that are relevant to their areas of expertise.
Wildcard syntax for search/filter
 *- contains
 !*-not contains
 _ - for a singl character
 %-any number of character
 =equals
Problem Management
Problem Management is a key component of the IT Service Management (ITSM)
framework and is primarily aimed at identifying, managing, and resolving the root causes of
incidents to prevent recurrence. Unlike Incident Management, which focuses on restoring
normal service as quickly as possible when something goes wrong, Problem Management
focuses on understanding and addressing the underlying causes of issues in order to prevent
them from happening in the future.
In ServiceNow, Problem Management is used to track and resolve problems efficiently,
ensuring that incidents are addressed not just reactively but proactively.
Key Objectives of Problem Management:
1. Identify and Resolve Root Causes: The main goal is to identify the root causes of
incidents and problems so that they can be fixed, preventing future occurrences.
2. Minimize the Impact of Incidents: By addressing underlying problems, the
organization reduces the impact of recurring incidents on users and operations.
3. Improve Service Quality: By solving problems at their root cause, Problem
Management contributes to improving the overall quality and stability of IT services.
4. Prevent Recurrence: A key goal is to prevent incidents from reoccurring by addressing
the root cause, which can be hardware failures, software bugs, misconfigurations, or
process inefficiencies.
Phases of Problem Management:
1. Problem Detection and Logging:
o Problem Detection: A problem is typically detected when an incident occurs
multiple times or when a single incident has a significant impact. The Problem
Management team may also look for patterns in incidents that suggest an
underlying problem.
o Logging the Problem: Once identified, a problem is logged in the system. Each
problem record in ServiceNow includes detailed information such as the
description of the problem, affected systems, and related incidents.
2. Problem Categorization and Prioritization:
o Problems are categorized based on the type of issue (e.g., hardware, software,
network) and prioritized according to their severity, business impact, or recurrence.
This helps to allocate resources and set deadlines for resolution.
3. Root Cause Analysis:
o Root Cause Investigation: This is the process of analyzing the problem to identify
the true underlying cause. Techniques like the Five Whys, Fishbone Diagram,
and Fault Tree Analysis are often used to systematically investigate the issue.
 o Impact Assessment: During root cause analysis, the team also assesses the
potential impact of the problem on the organization and identifies whether the
issue can be resolved permanently or temporarily.
4. Creating and Implementing Solutions (Known Error and Workarounds):
o Known Error: Once the root cause is identified, it is marked as a Known Error
in ServiceNow. A Known Error record stores information about the problem and
its root cause, as well as any existing workarounds or solutions.
o Workaround: If the issue cannot be fixed immediately, a workaround is created to
mitigate the impact while a permanent solution is being worked on.
o Permanent Resolution: Once the root cause is identified, a permanent solution or
corrective action is planned and implemented. This could involve changes to
hardware, software, or processes.
5. Problem Resolution and Closure:
o Once a permanent solution is implemented, the problem is resolved and closed.
The resolution process includes validating the solution and ensuring that it
effectively prevents the recurrence of the problem.
o Any changes or actions taken to resolve the problem are documented for future
reference.
6. Proactive Problem Management:
o Proactive Problem Management is about identifying potential problems before
they cause incidents. This involves analyzing incident trends, monitoring systems,
and engaging with teams to identify risks or inefficiencies that could lead to
problems in the future.
o It can involve activities such as:
 Reviewing historical incidents and looking for patterns.
 Implementing system monitoring to detect early signs of failure.
 Conducting regular risk assessments or audits.
Key Components in ServiceNow's Problem Management:
1. Problem Records: The primary record for tracking and managing problems in
ServiceNow. It stores information about the problem's nature, root cause analysis,
associated incidents, and resolution.
2. Known Error Records: A known error is a problem that has been analyzed and its root
cause has been identified, but the solution may not yet be fully implemented. Known
Error records are created to track the ongoing resolution process and provide guidance
for workarounds.
3. Workarounds: Temporary solutions or procedures that help to reduce the impact of a
problem until a permanent solution is found.
 4. Problem and Incident Linkage: Problems are often linked to related incidents. This
linkage helps track which incidents were caused by the problem and how the problem
resolution is affecting incident closure.
5. Change Requests: In some cases, resolving a problem may require changes to be made
to the infrastructure or processes. These changes are tracked using Change Management
and are typically associated with the problem to ensure coordinated resolution.
Problem Management Workflow in ServiceNow:
1. Problem Detection: Incident reports and trends are reviewed to identify recurring or
significant issues.
2. Problem Logging: A new problem record is created, and details are documented.
3. Investigation and Root Cause Analysis: The problem is analyzed, and the root cause is
determined.
4. Solution and Known Error Documentation: A solution or workaround is implemented
and documented in the Known Error record.
5. Resolution: Once a permanent solution is in place, the problem is resolved.
6. Closure: The problem is closed, and the resolution is documented in the system for
future reference.
7. Continuous Improvement: Proactive monitoring and periodic reviews are done to
prevent new problems from arising.
Benefits of Problem Management:
1. Reduced Incidents: By addressing root causes, recurring incidents can be minimized,
improving system stability.
2. Improved Service Availability: Problems are fixed before they affect users or
operations, ensuring higher service uptime.
3. Cost Reduction: Fewer incidents mean less time and resources spent on firefighting,
leading to cost savings.
4. Enhanced Customer Satisfaction: With fewer disruptions and quicker resolutions, end-
users are more likely to have a positive experience.
5. Proactive Risk Management: By identifying potential problems early, proactive
measures can be taken to prevent downtime or service disruptions.
Phases of Problem Management
 New
 Assess
 Root Cause analysis
 Fix in progress
 Resolved
 Closed
In Problem Management, an incident that occurs frequently or repeatedly can be identified
as a problem. This helps to move from a reactive approach (fixing the symptoms repeatedly) to
a proactive approach (addressing the root cause).
Here's how it works:
1. Incident Occurs: When an incident happens, it is usually logged and resolved quickly.
However, if the same incident occurs multiple times, it indicates a recurring issue that
needs further attention.
2. Identifying Recurring Incidents: ServiceNow or other ITSM tools might automatically
detect patterns of recurring incidents. For example, if users continuously report the same
issue (like network outages or software crashes), it signals that something is wrong and
requires investigation.
3. Converting to a Problem: Once a pattern of frequent incidents is identified, the
Incident Management team may raise a Problem Record. This signifies that there is an
underlying cause that needs to be addressed. The problem record helps track the root
cause investigation and resolution.
4. Root Cause Investigation: The Problem Management team then investigates the issue
further to identify the root cause. This involves analyzing incidents, performing root
cause analysis (such as using the Five Whys or Fishbone Diagram), and uncovering
what is causing the recurring incident.
5. Resolution and Prevention: Once the root cause is determined, the team works on
implementing a solution or workaround. The goal is to eliminate or mitigate the problem,
thus preventing future incidents of the same nature.
Service Now developer

Client side scripting

In ServiceNow's client-side scripting, the common events you use are:
1. onChange – Triggered when a value in a form field changes.
2. onLoad – Triggered when the form is loaded.
3. onSubmit – Triggered when a form is submitted.
4. onCellEdit – This event is triggered when a cell in a list is edited. It allows you to
execute scripts when users directly modify list cells without needing to open the form.
onLoad() — runs when the system first renders the form and before users can enter data.
Typically, onLoad() client scripts perform client-side-manipulation of the current form or set
default record values.
onSubmit() — runs when a form is submitted. Typically, onSubmit() scripts validate things on
the form and ensure that the submission makes sense. An onSubmit() client script can cancel
form submission by returning a value of false.
onChange() — runs when a particular field value changes on the form. The onChange() client
script must specify these parameters.
 control: the DHTML widget whose value changed.
Note: control is not accessible in mobile and service portal.
 oldValue: the value the widget had when the record was loaded.
Note: Old values aren't returned for the HTML field type.
 newValue: the value the widget has after the change.
 isLoading: identifies whether the change occurs as part of a form load.
 isTemplate: identifies whether the change occurs as part of a template load.
onCellEdit() — runs when the list editor changes a cell value. The onCellEdit() client script
must specify these parameters.
 sysIDs: an array of the sys_ids for all items being edited.
 table: the table of the items being edited.
 oldValues: the old values of the cells being edited.
 newValue: the new value for the cells being edited.
 callback: a callback that continues the execution of any other related cell edit scripts.
If true is passed as a parameter, the other scripts are executed or the change is committed
if there are no more scripts. If false is passed as a parameter, any further scripts are not
executed and the change is not committed.
1. Client-Side Scripting:
Client-side scripts run in the user’s browser and are typically used to interact with forms, fields,
and UI elements in real-time.
Types of Client-Side Scripts:
 Client Scripts: Used to execute scripts when specific events (onLoad, onChange,
onSubmit, onCellEdit) occur on forms.
 UI Policies: Used to dynamically show/hide, enable/disable, or set mandatory fields on
forms.
 UI Actions: Add buttons, links, or context menu options to forms or lists.
 Business Rules (Client callable): Although Business Rules are primarily server-side,
they can be set to be client-callable for certain tasks.
2. Server-Side Scripting:
Server-side scripts run on the ServiceNow server. They are mainly used to manipulate records,
execute business logic, and interact with the database.
Types of Server-Side Scripts:
 Business Rules: Execute scripts before or after database actions (insert, update, delete,
query).
 Script Includes: Reusable server-side scripts that can be called from other scripts.
 Scheduled Jobs: Automate tasks that run at specified intervals.
 Workflow Scripts: Server-side scripts within workflows to control process flows.
 Inbound Actions: Handle incoming email messages and create or update records based
on the content.
Workflows
workflow can be edited only by admin or workflow admin and till then not visible to other
users.
When the workflow is published it cannot be edited. Workflows are commonly used for change
management, service catalog and knowledge management applications but maybe used for any
record in the system.
To make modifications to a published workflow , we have to checkout it first
The activities in workflows are, condition, approval, notification, subflows, service catalog,
timers, utilities, tasks
 Checked-out workflows in ServiceNow refer to workflows that are currently being edited or
modified by a user and have not yet been published or made live in the system. When a
workflow is checked out, it means changes are being made to the workflow in a personal draft
version, preventing other users from making conflicting changes until the workflow is either
published or reverted.
Specify at least one Condition to trigger the workflow. Select one of the following options to determine what happens
when a record inserted on the selected table matches the condition:

 Run the workflow: Workflow(s) start in succession according to the Order column each time an inserted record
matches the condition.
 Run if no other workflows matched yet: The workflow starts when a record matches the condition, only if no
other workflows are running on the record.
 Run if no other workflows matched yet (Deprecated): The workflow only runs if no other workflows are
running on the execution thread that started this workflow. Avoid using.
 Run if no other workflows matched: The workflow only runs if no other workflows are running on a specific
record.
 None: The workflow does not start unless it is triggered by a subflow or script.

Inputs
The Inputs section lists all the activities in the current workflow that input data, the data type,
and the default value. The Inputs section is only available after a workflow has been created. To
create a variable, click New.

Field Description

Label Displayed column label. Localized depending on user locale.

Reference Input field from another table.

Type Data type. For example, integer or string.

Default value Value used if you do not provide a value.

The Input section in workflow properties in ServiceNow defines the data inputs required by
the workflow to execute. These inputs act as parameters that can be dynamically passed to the
workflow at runtime, allowing for customization and reuse across different scenarios.

Key Features of the Input Section

1. Defining Inputs:
o Inputs are variables or parameters that the workflow expects to receive when
triggered.
o These can include information like record IDs, user details, timestamps, or custom
data specific to the workflow's logic.
2. Input Data Types:
o Common types include:
 String: For text or alphanumeric data.
  Integer: For numerical data.
 Boolean: For true/false values.
 Date/Time: For timestamp-related inputs.
 Reference: For referencing records from specific tables in ServiceNow.
3. Default Values:
o You can specify default values for inputs, which will be used if no data is
explicitly provided during workflow execution.
4. Dynamic Inputs:
o Inputs can be dynamically populated based on conditions or context, such as data
from the record triggering the workflow.
5. Validation:
o Ensures that the data provided matches the expected type and format.

How Inputs Work in a Workflow

1. Configuration:
o Inputs are configured in the Workflow Properties panel, typically under the
"Input Variables" section.
o Define the input name, data type, and optionally, a default value.
2. Usage in Activities:
o The input values can be referenced throughout the workflow in activities,
conditions, and scripts.
o Example: If an input named taskId is defined, activities within the workflow can
use this ID to fetch, update, or act on a specific task record.
3. Passing Inputs:
o Inputs can be passed programmatically when the workflow is triggered via:
 A script.
 A subflow.
 A user action (e.g., clicking a button that starts the workflow).
You need to pass the inputs when you are calling the flow. The syntax will be like this where you
need to define the inputs in the var

4. var vars={ key1: value1, key2: value2,};

5.
6. vars.sd = ch;
7. var wf = new Workflow();
 8. var wf_ID = wf.getWorkflowFromName('TEST:WF Inputs');
9. wf.startFlow(wf_ID, glideRecord, operation(insert, update etc), vars);

Reading the Value of a Workflow Input Variable

The value of a Workflow input variable is accessible anywhere within the workflow that
accepts javascript by dot walking the current workflow object:
var readValue = workflow.inputs.variable_name;

10.Reusability:
o Inputs allow workflows to be reused across different contexts by simply passing
different data values during execution.

Example Use Case

Scenario:
You want to create a workflow to notify users about task updates.
Steps:
1. Define Inputs:
o taskId (String): The ID of the task.
o notifyUserId (String): The user ID of the person to notify.
2. Configure Activities:
o Use taskId to fetch task details.
o Use notifyUserId to determine the recipient of the notification.
3. Execution:
o When the workflow is triggered (e.g., via a business rule), the required taskId and
notifyUserId are passed as inputs.

NOTE:-
var readValue = workflow.inputs.variable_name;
workflow.inputs is used in sub-workflows when you call sub-workflow from main workflow
and send some values to sub-workflow.
The statement "The Stages section appears if you select a table with Type = Workflow"
means that the Stages section in the workflow properties will only be visible when you
configure a workflow that is associated with a table explicitly set up for workflow processing.
Here’s a detailed breakdown of what this means:

1. Table with Type = Workflow

 In ServiceNow, every workflow operates on a specific table.
 A table configured with Type = Workflow is designed to use ServiceNow's workflow
engine to manage processes and track progress through stages.
 Examples of such tables:
o Task table
o Incident table
o Change Request table
o Request Item (RITM) table

2. Purpose of Workflow Table Type

 Workflow-enabled tables are intended for:
o Tracking the progress of a process (like approvals, task assignments, or lifecycle
events).
o Allowing the workflow engine to interact with the table's records (e.g., updating
stage fields as the workflow progresses).
o Displaying stage progress in forms and lists for better visibility.

3. Why Stages Appear for Workflow Tables

 The Stages section is directly tied to tables that support workflow-based progress
tracking.
 When you select a table with Type = Workflow, the system assumes that:
o The table has a Stage field (or can use one).
o The workflow will manage progress updates for records in this table, which
justifies the need for stages.

4. Why Stages Might Not Appear for Other Tables

 For tables without Type = Workflow:
o The concept of stages may not be applicable.
 o For example, a static configuration table or a table storing raw data might not
require a visual representation of progress.
o Stages will not appear because the system doesn't expect workflows to manage or
track the progress of records in such tables.

How to Check/Set Table Type

1. Navigate to the table's configuration:
o Go to System Definition > Tables.
o Search for the table you are working with.
2. Check the Table Type field:
o If it’s set to Workflow, the Stages section will be available.
3. Change the table type to Workflow (if needed):
o Edit the table configuration and set the Type field to Workflow.
o Save the changes.

Example:
Scenario 1:
You are creating a workflow for the Incident table, which is configured as a Workflow table.
The Stages section appears in the workflow properties, allowing you to define stages like:
 New
 In Progress
 Resolved
 Closed
Scenario 2:
You are creating a workflow for a custom table that stores static data, not configured as a
Workflow table. The Stages section does not appear because the table is not expected to track
progress or use stages.

Key Concepts of Checked-out Workflows:

1. Draft Version:
o When a workflow is checked out, it creates a draft version for the user to work on
without affecting the live workflow. This allows changes to be tested and reviewed
before being deployed in production.
 2. Preventing Conflicts:
o The check-out mechanism ensures that multiple users don’t make conflicting edits
to the same workflow at the same time. While a workflow is checked out, other
users are prevented from modifying it.
3. Publishing:
o Once changes to the checked-out workflow are finalized, the user can "publish"
the workflow. Publishing will make the changes available to everyone, replacing
the current active version of the workflow with the updated one.
4. Reverting:
o If a user decides not to go through with the changes, they can "revert" the checked-
out workflow. This discards the changes and keeps the original workflow version
intact.
5. Visible Indicator:
o In the workflow editor, a checked-out workflow will be marked with a "Checked
Out" label, indicating that it is in draft mode. Only the user who checked it out or
an administrator can publish or revert it.
6. Use Case:
o You are making modifications to a workflow (e.g., incident handling). During the
check-out, you can test your changes in a non-production environment without
disrupting the active workflow. Once you’re satisfied with the changes, you can
publish the new workflow.
How to Check Out a Workflow:
1. Navigate to Workflow Editor.
2. Open the workflow you want to modify.
3. Click the Check Out button at the top. This action will lock the workflow for your
changes.
4. Make the necessary changes to the workflow.
5. After testing, click Publish to make the changes live or Revert to discard them.

No, when a workflow is checked out in ServiceNow, it cannot be used by the system. The
checked-out version is a draft that is only accessible to the user who checked it out. The
system continues to use the published (active) version of the workflow until the checked-
out workflow is published.

If the workflow table is Request Item [sc_req_item], then the stage field is automatically set to
the Stage column of that table and cannot be changed.

Note: If you are creating a workflow with a table other than Request Item [sc_req_item], you
must select a Stage field in the workflow properties for the workflow to have stages.
APPROVAL > GENERATE ACTIVITY
The Generate Workflow Activity in ServiceNow is used to pre-generate tasks or approvals in
a workflow, even though those tasks or approvals are not yet "active" or being executed. Here’s
what that means in simpler terms:

Key Concept: Pre-Generated Tasks/Approvals

 Normally in a workflow, tasks or approvals are created and become visible only when the
workflow reaches that step.
 The Generate activity creates these tasks or approvals ahead of time (pre-generates
them), so they already exist in the system before the workflow reaches them.
 However, the tasks/approvals remain inactive and do not start until the workflow reaches
the corresponding step.

Why Use the Generate Activity?

1. Preview of Workflow Progress:
o All tasks or approvals related to the workflow can be seen upfront, helping users or
administrators understand what will happen next.
2. Sequential Task Management:
o Even though tasks or approvals are pre-generated, they still execute in the order
defined in the workflow.
o For example, Task 2 will not start until Task 1 is completed, even if both are pre-
generated.

How It Works
1. Workflow Path:
o Place the Generate activity in the workflow path before task or approval
activities.
2. Execution:
o When the workflow reaches the Generate activity, it creates all the subsequent
task and approval records associated with the workflow.
o These tasks and approvals remain inactive but are visible in the system.
3. Activation:
o When the workflow progresses and reaches a task or approval activity, that
specific task or approval becomes active.
Example Use Case
Scenario:
You have a workflow for onboarding a new employee. The onboarding involves:
1. Task 1: Assign a desk (Desk Assignment).
2. Task 2: Set up a laptop (IT Equipment Setup).
3. Task 3: Provide training (Employee Orientation).
Without Generate Activity:
 Task 1 is created when the workflow reaches the Desk Assignment step.
 Task 2 is created only after Task 1 is completed.
 Task 3 is created only after Task 2 is completed.
With Generate Activity:
 All three tasks are created as soon as the workflow reaches the Generate activity.
 However, only Task 1 is active initially. Task 2 and Task 3 remain inactive.
 When Task 1 is completed, Task 2 becomes active. Then Task 3 becomes active after
Task 2 is completed.

Benefits of Using Generate Activity

1. Transparency:
o Users can see all the tasks or approvals associated with the workflow upfront, even
if they are not active yet.
2. Efficiency:
o Helps in planning and resource allocation since all tasks are visible early.
3. Order Enforcement:
o Ensures tasks and approvals are completed in the intended sequence, even if pre-
generated.

Conclusion
The Generate activity is used to create tasks or approvals in advance, but it doesn’t alter their
execution order. This makes workflows more transparent while maintaining control over the
sequence of tasks or approvals.
https://www.servicenow.com/docs/bundle/xanadu-build-workflows/page/administer/workflow-
activities/concept/wf-activity-overview.html
Ending workflows with multiple branches
A workflow is complete when it reaches the End activity, even if there are still active branches
of the workflow in progress. To ensure that both branches are completed, add a Join activity to
resolve the branches.
For example, the following figure shows a workflow with two branches that execute
independently. When Task 1 and Task 2 of Branch B are completed, the workflow is marked
complete even if the Branch A tasks are not completed.
For both branches to complete, add a Join activity to resolve the branches. When one branch
reaches the join, the workflow waits for the other branch. When both branches are complete, the
workflow reaches the end. The Incomplete condition of the a Join activity is met only if one of
the branches cannot be completed.
Week 1-2: Introduction to ServiceNow
1. Introduction to ServiceNow
o Overview of the platform
o ServiceNow interface, navigation, and modules
o Understanding ITIL and ITSM fundamentals
2. ServiceNow Overview & Core Features
o Tables and records
o Forms, lists, and UI actions
o ServiceNow Application Navigator
Resources:
 ServiceNow docs: "Getting Started"
 ITIL/ITSM basics on YouTube or Udemy
Week 3-4: Basic Configuration & Administration
1. User Administration
o Roles, groups, and users
o Access controls (ACLs)
2. Form and List Layouts
o Modifying forms and lists
o Dictionary entries, form designer, list layouts
3. ServiceNow Studio
o Installing and using ServiceNow Studio for app development
Resources:
 ServiceNow Admin Fundamentals training
 Community discussions and tutorials
Week 5-6: Scripting & Business Logic
1. Introduction to Scripting in ServiceNow
o Client-side vs. server-side scripting
o GlideForm, GlideRecord APIs
2. Client Scripts & UI Policies
o Writing basic client-side scripts (onChange, onLoad, onSubmit)
o UI policies, data policies
 3. Business Rules & Script Includes
o Writing business rules for server-side logic
o Understanding script includes for reusable code
Resources:
 ServiceNow scripting documentation
 ServiceNow Developer YouTube channel
Week 7-8: Workflow & Automation
1. Workflows & Flow Designer
o Understanding workflow editor
o Building workflows, stages, and activities
o Introduction to Flow Designer (codeless automation)
2. Notifications
o Email notifications and templates
o Triggers, conditions, and events
3. Service Catalog
o Creating catalog items, record producers, and variables
Resources:
 ServiceNow Developer training on workflows
 Flow Designer documentation
Week 9-10: Integration & REST APIs
1. Integration Basics
o IntegrationHub and REST API fundamentals
o Creating REST API connections
2. Inbound and Outbound REST APIs
o Working with REST API Explorer
o Scripted REST APIs, transforming data
3. ServiceNow Integration Best Practices
o Integrating with third-party systems
Resources:
 ServiceNow IntegrationHub documentation
 REST API tutorials
Week 11: Advanced Topics
1. Custom Applications Development
o Building custom applications using ServiceNow Studio
o Working with scoped applications
2. Service Portal Development
o Creating custom pages, widgets, and themes
o Portal best practices
Resources:
 Custom Application Development (CAD) documentation
 ServiceNow Portal training
Week 12: Practice & Certification Preparation
1. Real-World Projects
o Develop a mini project involving workflows, custom apps, and catalog items
o Automating business processes (use Flow Designer)
2. ServiceNow Certification
o ServiceNow Certified System Administrator (CSA) exam preparation
o Go through exam guides and sample questions
Resources:
 ServiceNow Developer Program (free resources)
 Certification blueprint
Metrics
Metric_definition :- contains the metric definition for the data.
Metric_instance :- Instance stores the actual result calculated by metric definition.
a Metric is a way to measure and track the performance, trends, or changes of records over
time. It provides valuable insights into how processes, incidents, tasks, or other records evolve,
enabling organizations to monitor and improve their workflows effectively.
A metric measures and evaluates the effectiveness of IT service management processes.
For example, a metric could measure the effectiveness of the incident resolution process by
calculating how long it takes to resolve an incident.
A metric can often be easily obtained from the data. To find the number of incidents created
today, a report counts the number of incidents in the incident table with a Created date of today.
However, metrics must be gathered as data is updated. For example, determining how long an
incident was assigned to a certain group requires collecting information about assignment
changes and calculating the duration of each assignment.
The Metric plugin provides an easy, declarative way of defining metrics. Once defined, the data
for the metric is gathered, and instances of the metric are calculated and stored. For example,
the "Assigned to Duration" metric measures the amount of time an incident is assigned to an
individual. To define this metric, you create a metric definition of the type "Field value
duration" and select the "Assigned to" field from the Incident table. A metric instance is created
for each incident assignment showing its duration. Reporting on the duration of incident
assignments becomes easy.
 Field value duration: This type of metric measures the duration of time from when the
value of the specified field is set until it’s changed. A Field value duration metric can
optionally specify a script. The script can either return a duration value or set the answer
variable to false to stop processing the metric. For example, the baseline incident metrics
stop calculating duration when the Active field of an incident is set to false. The script
can also carry out any other action such as closing the duration of other metrics defined
on the same record. For more information, see Sample field value duration script.
 Script calculation: This type of metric creates a metric instance using a script. The script
has access to the current row in the table (for example an incident) and the metric
definition. The script must perform metric calculations and insert data into the
metric_instance table. The calculation doesn’t have to result in a duration. It can calculate
any type of value and store it in the metric instance value.
Comparison Table

Aspect Reporting Metrics

Provide insights into data with Track trends, durations, and
Purpose
summaries or visuals. performance over time.
Measures specific changes or
Scope Focuses on current or historical data.
conditions over time.
Pulls data directly from ServiceNow Created based on predefined metric
Data Source
tables. definitions.
Focuses on historical and time-based
Time-Based Real-time or snapshot reporting.
measurements.
Customization Highly customizable visual reports. Requires metric definitions for setup.
Requires user interaction to generate
Automation Automatically tracks defined metrics.
reports.
Examples Incident count by priority. Time spent in "Pending" state.
Example:-
Metric definition : create to resolve duration
var s = current.incident_state;
if (s >= 6)
createMetric();

function createMetric() {
var mi = new MetricInstance(definition, current);
if (mi.metricExists())
return;

var gr = mi.getNewRecord();
gr.start = current.sys_created_on;
gr.end = current.sys_updated_on;
gr.duration = gs.dateDiff(gr.start.getDisplayValue(), gr.end.getDisplayValue());
gr.calculation_complete = true;
gr.insert();
}

Summary of Workflow:
1. Check if the incident_state meets the condition (>= 6).
2. Instantiate MetricInstance with the provided definition and current.
3. Avoid duplicate metrics by verifying with metricExists().
4. Create and populate a new metric record with start, end, and duration values.
5. Save the metric record for further analysis and reporting.
2. Code Explanation
Variables Available:
 current: A GlideRecord object representing the current incident record.
 definition: A GlideRecord object representing the metric definition.
Code Breakdown:
 1. Fetch Incident State:
var s = current.incident_state;
if (s >= 6)
createMetric();
o This retrieves the incident_state of the current record.
o If the incident_state is 6 or greater (typically indicating a resolved or closed state),
the createMetric() function is executed.
2. Function: createMetric:
function createMetric() {
o This function handles the creation of the metric instance based on the provided
definition and current record.
3. Instantiate MetricInstance:
var mi = new MetricInstance(definition, current);
o Creates an instance of the MetricInstance script include.
o Purpose: Manages metric calculations and records.
o Parameters:
 definition: Specifies the metric's configuration.
 current: Specifies the target record (in this case, an incident).
4. Check if Metric Exists:
if (mi.metricExists())
return;
o The metricExists() method checks if a metric has already been created for this
definition and record.
o If the metric exists, the function exits early.
5. Create a New Metric Record:
var gr = mi.getNewRecord();
o The getNewRecord() method generates a new metric instance record in the system.
6. Set Metric Details:
gr.start = current.sys_created_on;
gr.end = current.sys_updated_on;
gr.duration = gs.dateDiff(gr.start.getDisplayValue(), gr.end.getDisplayValue());
gr.calculation_complete = true;
 o gr.start: Set to the record's creation time (sys_created_on).
o gr.end: Set to the record's last updated time (sys_updated_on).
o gr.duration: Calculates the time difference between start and end using the
gs.dateDiff method, likely in seconds or minutes.
o gr.calculation_complete: Marks the metric as fully calculated.
7. Insert Metric Record:
gr.insert();
o Saves the new metric record to the database.
A related list in ServiceNow is a feature that displays a list of records from one table that are
related to the current record being viewed in another table. It provides a way to view and
manage relationships between different tables directly from the form view of a record.

Key Features of Related Lists:

1. Relationship Visualization:
o Related lists visually link records from one table to another, based on predefined
relationships (e.g., reference fields or many-to-many relationships).
2. Interactive Access:
o Users can view, create, edit, or delete related records without navigating to a
different table.
3. Dynamic Updates:
o Any updates to the related records are immediately reflected in the related list.
4. Customizable:
o Administrators can configure which related lists appear on a form and control the
columns displayed.

Examples of Related Lists:

1. Incident Form:
o Related lists might include:
 Tasks: Child tasks linked to the incident.
 Affected CIs: Configuration Items associated with the incident.
 Work Notes: Communication history for the incident.
2. Change Request Form:
o Related lists might include:
  Approvals: Approvers for the change request.
 Affected Services: Services impacted by the change.
3. Problem Record:
o Related lists might include:
 Incidents: Incidents associated with the problem.
 Change Requests: Changes created to resolve the problem.
Data Source
Data Sources
Data sources define what data should be imported. Only admin users can create data sources. In
this module, the data source is a Microsoft Excel spreadsheet. Other possible data sources are:
 CSV
 JDBC
 FTP
 HTTP
 XML
Create Data Sources for a scoped application in Studio. To see example Data Source
configurations, use the All menu to open System Import Sets > Administration > Data
Sources. The example JDBC data source for integrating to a MySQL database looks like this:
Data Source configuration fields vary depending on data source type. To connect to the MySQL
database with JDBC requires the Database name, Username, Password, Server, Database
port, Query, and Table name. If the Query field value is a SQL statement, a SQL field is
displayed and a valid SQL statement must be provided.
What is JDBC?
JDBC (Java Database Connectivity) is an API (Application Programming Interface) in Java
that enables Java applications to interact with relational databases. It provides a standard set of
interfaces and classes to connect to a database, send SQL queries, and retrieve results.
In ServiceNow, JDBC is used to import data from external relational databases into
ServiceNow tables.

Why Do We Need the Server Field?

The Server field specifies the hostname or IP address of the database server. It is crucial
because the ServiceNow instance (hosted in the cloud) must know where the external database
is located to establish a connection.
 The server acts as a network location for the database.
  Without specifying the server, the application cannot locate and connect to the database.

How Does JDBC Work in ServiceNow?

1. JDBC Connection Establishment:
o ServiceNow uses the provided details like Server, Database name, Username,
Password, and Port to establish a connection to the database using a JDBC driver.
2. Data Retrieval:
o The Query field in the data source specifies the SQL query to execute on the
external database. This query retrieves the desired data.
3. Import Set Table:
o The retrieved data is temporarily stored in a ServiceNow Import Set Table.
o This intermediate storage ensures that data can be validated, transformed, and
mapped before inserting it into the target table.
4. Transformation Process:
o A Transform Map is created to map fields from the import set table to the target
table.
o The imported data is transformed and inserted into the target table after the
transformation is complete.

Data Source Configuration Fields

When creating a JDBC Data Source in ServiceNow, these are the key fields:
1. Name:
o The name of the data source for identification.
2. Server:
o Hostname or IP address of the database server.
3. Database Name:
o The name of the database to connect to.
4. Username and Password:
o Credentials to authenticate the connection to the database.
5. Port:
o The port number where the database server is listening (default for MySQL is
3306).
6. Table Name:
 o The specific table in the database to import data from.
7. Query:
o The SQL query used to fetch data.
o For example: SELECT * FROM employees WHERE department = 'IT'.
8. SQL Statement Validation:
o The SQL field allows you to validate the query to ensure it's correct before
running it.

Example Workflow
Let’s consider an example where you need to import employee data from a MySQL database:
1. Setup the Data Source:
o Name: Employee Data Import
o Server: 192.168.1.100
o Database Name: company_db
o Username: admin_user
o Password: secure_password
o Port: 3306
o Query: SELECT id, name, email, department FROM employees
2. Test the Connection:
o ServiceNow attempts to connect to the database using the provided credentials and
server details.
o If the connection succeeds, the data source is ready for use.
3. Run the Data Import:
o Execute the import to fetch data from the external database and store it in an
Import Set Table in ServiceNow.
4. Map and Transform Data:
o Use a Transform Map to map fields like id, name, email, and department from the
Import Set Table to the target ServiceNow table (e.g., cmn_users).
5. Insert Data into the Target Table:
o After transformation, the data is inserted into the target table.

Why Use JDBC in ServiceNow?

  Integration: To seamlessly integrate data from external databases into ServiceNow.
 Automation: Automate data imports using scheduled jobs.
 Flexibility: Supports complex SQL queries for fetching specific subsets of data.
 Centralized Data Management: Consolidate data from multiple external systems into
ServiceNow for better visibility and control.

schedule imports
you can schedule imports in ServiceNow! This is a powerful feature that allows you to
automate the process of importing data from external sources at regular intervals, ensuring that
your data remains up-to-date.

How to Schedule an Import in ServiceNow

1. Create a Data Source
 First, define your data source (e.g., JDBC, CSV, HTTP, etc.) as described earlier.
 Ensure that the connection works and the import retrieves the desired data.
2. Create a Scheduled Data Import
 Navigate to System Import Sets > Scheduled Import.
 Click New to create a new scheduled import.
3. Configure the Scheduled Import
 Name: Provide a descriptive name for the scheduled import.
 Data Source: Select the data source you created earlier.
 Import Set Table: Choose the table where the data will be temporarily stored.
 Run: Set the frequency for the import. Options include:
o Daily
o Weekly
o Monthly
o On Demand (manual execution only)
 Time: Specify the exact time the import should run.
 Active: Ensure the schedule is active by checking this box.
Field Service Management Module
What is field service?
Field service describes situations in which authorized technicians perform essential tasks at
specific locations. Often, these technicians visit customer-owned properties to install, repair,
maintain, or remove systems or equipment.
Your field service personnel must be able to provide skilled, specialized, and often-proprietary
services to a range of clients.
What are field service activities?
While field service is an umbrella term that includes any and all work performed by trained
agents at various locations, most field service responsibilities fall into one of the following
categories.
 Installation
Vital field equipment often demands expert installation from trained technicians, capable
of making sure that the equipment is set up correctly, and functioning properly.
Installation may also include onboarding, answering questions, and training customers on
how to properly interact with the equipment.
 Maintenance
To ensure the longest-possible operational life of all offsite equipment, technicians often
perform maintenance tasks while in the field. Maintenance responsibilities consist of
corrective maintenance (repairing equipment), preventive maintenance (routine
inspections and recalibrations), and proactive maintenance (comparing current
functionality to established baselines to identify and resolve potential problems).
Maintenance tasks are scheduled proactively.
 Repair
In the event that equipment experiences unexpected failure, field-service personnel may
be dispatched to perform emergency repair work. Also called break fix, repairs occur
when a customer has an issue and contacts customer service, or books an appointment.
 Removal
Equipment that is no longer functioning properly, is being replaced by an upgraded
model, or that the customer no longer wants or needs must be removed. Field technicians
are responsible for safely disassembling said equipment, and transporting it away from
the customer’s property.
 Scheduled work
Not all field service is equipment-centric. Some work simply involves sending a person
with the right skills to a location to complete a task. For example, home healthcare visits
require sending a practitioner with the right skills and equipment to visit a patient at a
specific location and time
In Field Service Management (FSM) in ServiceNow, different roles are defined to streamline
the management of field service operations. These roles help in organizing and executing the
tasks efficiently. Here's an explanation of each role:
1. Administrator
The Administrator in FSM is responsible for the overall configuration and management of the
Field Service Management application. Their primary duties include:
 Configuring the System: Setting up field service management processes, including
defining work orders, tasks, and service level agreements (SLAs).
 Managing Users and Roles: Assigning roles to users, including technicians, agents, and
supervisors, and ensuring they have the necessary access rights to perform their
functions.
 Setting Up and Customizing: Customizing the FSM workflows, notifications, and
ensuring that the system integrates seamlessly with other ServiceNow modules (like
Incident Management or Change Management).
 Defining Service Locations and Assets: Configuring service locations, assets, and
customers, as well as ensuring they are correctly linked with relevant work orders.
 Reporting and Analytics: Admins are also responsible for setting up reports and
dashboards to track the performance of field service operations, including technician
efficiency, case resolution times, and customer satisfaction.
2. Initiator
The Initiator is typically the person or system that triggers the field service request. This role
could involve:
 Raising Service Requests or Work Orders: The initiator may be a customer, agent, or
system (e.g., automatic generation from a monitoring system) that identifies a service
need.
 Creating a Case: When a customer calls in or reports an issue, the initiator can create a
case or service request in the system, which then turns into a work order that is sent to a
technician for resolution.
 Assessing Service Needs: In some cases, the initiator may need to assess or approve
service requests before creating or escalating work orders.
The initiator’s role is generally to begin the process of addressing a service issue, whether that’s
through reporting an issue, creating a work order, or notifying a customer service agent.
3. Qualifier
The Qualifier is responsible for ensuring that the field service request or work order is properly
defined and categorized. This role involves:
 Validating the Work Order: Ensuring that the work order or service request contains all
necessary details such as customer information, issue description, priority, and scope.
  Assessing the Severity: The qualifier may assess the severity of the issue and categorize
it, helping to prioritize tasks based on urgency or impact.
 Ensuring Correct Information: This role also ensures that the work order includes
correct information (e.g., equipment details, customer location, and asset data) and that
the correct technician is assigned based on their skills and availability.
 Eligibility Check: The qualifier might ensure that the service request is eligible for
coverage under a warranty, service agreement, or SLA.
Essentially, the qualifier confirms that the request meets the criteria for a field service task and
that it can proceed to the next stages of processing.
4. Dispatcher
The Dispatcher is the key person who assigns work orders or service tasks to the appropriate
technicians or field agents. Their responsibilities include:
 Assigning Work Orders: Dispatchers are responsible for assigning work orders to the
appropriate technician based on factors like skills, availability, location, and priority.
 Scheduling Tasks: They schedule the appointments, ensuring that technicians are
available at the right time and the right place to carry out the service.
 Managing Work Order Priorities: Dispatchers also have to prioritize work orders,
especially during periods of high demand or emergency situations.
 Optimizing Routes: In some cases, dispatchers also optimize routes for field technicians
to minimize travel time and improve efficiency.
 Communicating with Technicians: Dispatchers often maintain communication with
field technicians to ensure they have the necessary information to complete the job and
can escalate issues if needed.
5. Agent
The Agent (or Field Service Technician) is the person responsible for carrying out the service
or repairs at the customer’s location. The technician’s duties include:
 Receiving Work Orders: Agents are assigned work orders by the dispatcher. They
receive the necessary details such as customer information, location, issue description,
and any service history or assets.
 Executing the Service: The agent performs the required field service work, which may
involve troubleshooting, repairs, installation, maintenance, or other service tasks.
 Updating Work Order Status: Throughout the service process, agents update the status
of the work order (e.g., in-progress, completed) and record any relevant information,
such as parts used or service issues encountered.
 Interacting with Customers: Technicians may interact directly with customers, keeping
them informed about progress and ensuring customer satisfaction.
  Closing Work Orders: Once the service is completed, the agent updates the work order
with a summary of the work performed, completes any necessary documentation, and
marks the work order as closed.
 Feedback and Reporting: After completing a job, technicians may provide feedback on
the service and offer suggestions for future improvements or process optimizations.
Work Order
Work orders in Field Service Management store information about requested work, including
customer names and addresses, locations where work is to be performed, and any associated
configuration items. Work orders can include one or more tasks that contain specific details
about the work to be performed, such as required agent skills or part requirements.
Work order templates automatically populate the work order with work instructions, tasks and
parts required for the field agent to complete the work order.
Integrating Field Service Management with other ServiceNow products enables you to create a
work order from within the other product's workspace.
You can create a work order from the following integrated record types:
Case
Use Field Service in CSM Agent Workspace to create work orders from cases while on a live
call or chat with the customer. For more information, see Work orders in CSM Agent
Workspace.
Incident
Use Field Service in Incident Management to create work orders from incidents. For more
information, see Integration with Incident Management.
Change
Use Field Service in Change Management to create work orders from change requests while on
a live call or chat with the customer. For more information, see Integration with Change
Management.
Project task
Use Field Service in Project Portfolio Management to create work orders from project tasks.
For more information, see Integration with Project Portfolio Management.
Service requests
Use Field Service in IT Service Management to create work orders from service requests.
Customer Experience in Field Service Management

The Customer Experience feature in Field Service Management provides customers with timely
updates about their reported issues, enabling them to track the location of agents and provide
agent feedback.
Key Concepts in FSM
1. Work Orders
o A work order represents a task or service that needs to be performed, often
initiated from customer issues, equipment failures, or scheduled maintenance.
o Work orders include details like:
 Customer information.
 Task description.
 Service location.
 Technician assignment.
 Priority level.
o Work orders are broken into Work Order Tasks (WOTs), which are smaller units
of work.
2. Work Order Lifecycle
o Created: A work order is generated, either manually or from a service request or
case.
o Assigned: The dispatcher assigns it to a technician based on skills, availability, and
location.
o Scheduled: The work is scheduled, and notifications are sent.
o In Progress: The technician is actively working on the task.
o Completed: The task is marked as complete, and reports are updated.
o Closed: The work order is closed after validation or customer feedback.
3. Service Locations
o Locations where the service will be performed. These can include customer sites,
warehouses, or offices.
4. Assets
o Assets represent the equipment or items that require servicing.
o Assets are linked to customers, locations, or both.
o Technicians use asset details to understand the history, configurations, and
previous issues.
5. SLA (Service Level Agreements)
o Defines the expected timeframes for resolving issues or completing tasks.
o Ensures compliance with service agreements between customers and the
organization.
FSM Workflow
1. Initiation
 A case is created through Customer Service Management (CSM), a service request, or
a direct input from a customer.
 For internal maintenance, requests can be initiated by employees or system alerts.
2. Qualification
 A Qualifier reviews the case:
o Checks service coverage (e.g., warranty or SLA).
o Ensures all necessary details are captured (e.g., location, customer, issue
description).
o Confirms that the issue is ready for escalation to field service.
3. Dispatching
 Dispatchers use tools like the Dispatcher Workspace to:
o Assign work orders to the most suitable technician.
o Optimize scheduling and routing to reduce travel time.
o Prioritize tasks based on urgency and SLA compliance.
4. Execution
 Technicians receive work orders via the Mobile App.
o Access task details, service history, and customer information.
o Use checklists or instructions for standard processes.
o Record work details, including parts used or issues encountered.
 Updates are sent in real-time to the FSM system.
5. Completion
 Technicians mark tasks as complete, providing detailed reports and obtaining customer
sign-off if needed.
6. Validation and Closure
 Supervisors or agents review completed work orders for accuracy and quality before
closing them.

FSM Key Features

1. Dispatcher Workspace
 o A centralized tool for dispatchers to:
 View work orders and tasks.
 Assign tasks to technicians.
 Monitor task progress and technician locations.
 Reschedule or reassign tasks when needed.
2. Mobile App for Technicians
o Technicians can:
 Access work orders and task details.
 Record their work (e.g., notes, images, parts used).
 Update task status in real-time.
 Communicate with dispatchers or supervisors.
3. Route Optimization
o Uses location-based data to optimize technician routes, reducing travel time and
operational costs.
4. Asset Management
o Tracks customer assets, including service history, configurations, and warranty
details.
5. Knowledge Base Integration
o Technicians can access articles or troubleshooting guides to assist in resolving
issues.
6. Parts Management
o Tracks spare parts and inventory.
o Ensures technicians have access to the parts needed for repairs.
7. Performance Analytics and Reporting
o Provides insights into:
 Technician efficiency.
 SLA compliance.
 Customer satisfaction.
8. Customer Communication
o Customers are updated via email, SMS, or portals about the status of their service
request or work order.
Field Service Management (FSM) in ServiceNow integrates with Customer Service
Management (CSM) and other modules to efficiently handle off-site work requests through
work orders (WOs) and work order tasks (WOTs). Here's a detailed explanation of the key
concepts and functionalities related to work orders:

What Are Work Orders?

Work orders are structured requests for off-site work. These are created when a customer issue
or internal request requires physical attention or on-site services. Work orders:
 Provide necessary details for the tasks to be executed.
 Track the progress of the request until its resolution.
 Can be created from other records like incident, problem, change, or case.

Creating Work Orders

Work orders can be created in multiple ways depending on the origin of the request. They
inherit relevant data fields from the parent record to streamline the process.
Sources for Work Orders
1. From Other Records:
o Incident: To address technical issues requiring physical attention.
o Problem: For deeper-rooted issues identified as problems.
o Change: For changes that require on-site action.
o Project Task: When part of an ongoing project.
2. From Another Work Order:
o Used if the scope of an existing work order changes significantly.
o Some fields like Location, Priority, and Caller are copied automatically.
Fields Inherited in Work Orders
Record Type Fields Inherited
Incident Caller, Location, Priority, Short Description, Description
Case Account, Contact, Location, Asset
Problem Priority, Short Description, Description
Change Priority, Short Description, Description
Project Task State, Scheduled Start, Estimated End
Managing Work Orders
1. Qualifying Work Orders:
o Ensures that work order tasks (WOTs) are created and assigned.
o Can be done manually or automatically.
o Tasks and parts can be added directly during qualification.
2. Creating Tasks Without Qualification:
o When work orders are in a draft state, tasks can still be added.
3. Filtering Work Orders:
o Based on attributes like location, qualification group, priority, etc., to organize and
group similar work orders.

Closing and Canceling Work Orders

1. Automatic Closure:
o Work orders are closed automatically when all associated tasks (WOTs) are
completed.
2. Cancellation:
o Used if the work is no longer required or is a duplicate.
o Canceled work orders are inactive and don't appear in lists.
3. Avoid Deleting Work Orders:
o Prefer canceling or closing instead of deletion to maintain tracking history.

Creating a Signed PDF Summary

1. After a work order is closed, customers can digitally sign to confirm the resolution.
2. A PDF summary of the signed work order is generated for records.

Work Orders in CSM Agent Workspace

The CSM Agent Workspace offers a seamless interface to create and manage work orders
directly while interacting with customers:
 Live Interactions: Create work orders during live calls or chats with customers.
 Templates: Use predefined templates to automatically generate tasks and part
requirements.

Example Use Case

 1. A customer calls to report a technical issue (recorded as a case in CSM).
2. The agent determines that the issue requires an on-site visit and creates a work order
from the case in the CSM Agent Workspace.
3. The work order is qualified, and tasks are created for the technician to resolve the issue.
4. Once resolved, the customer digitally signs the work order to confirm completion.
5. A signed PDF summary is generated for future reference.

ing
1. List Reports
 Description: Display records in a tabular format, similar to a grid view.
 Use Case: Ideal for simple data display, sorting, and exporting to Excel or PDF.
Commonly used for task tracking or user lists.
 How to Use:
1. Go to Reports > Create New > List.
2. Select the table and define the columns to display.
3. Apply filters to refine the data.
4. Save and share/export the report.

2. Bar Charts
 Description: Represent data using vertical or horizontal bars.
 Use Case: Useful for comparing data across categories, such as the number of incidents
by priority or department.
 How to Use:
1. Go to Reports > Create New > Bar Chart.
2. Choose the table and group data by a specific field.
3. Configure the X-axis and Y-axis to represent data appropriately.
4. Customize the chart appearance (e.g., colors, labels).

3. Pie Charts
 Description: Display data as slices of a pie, representing proportions.
 Use Case: Best for showing percentages or distributions, such as incident resolution
states.
  How to Use:
1. Go to Reports > Create New > Pie Chart.
2. Select the table and grouping field.
3. Define the conditions and labels.
4. Save the chart and add it to a dashboard if needed.

4. Line Charts
 Description: Use lines to show trends over time.
 Use Case: Great for tracking metrics like incident counts, SLA breaches, or system
performance over days, weeks, or months.
 How to Use:
1. Go to Reports > Create New > Line Chart.
2. Define the table and time-related grouping field (e.g., "Created on").
3. Customize the time intervals and data points.
4. Save and analyze the report for trend insights.

5. Column Charts
 Description: Similar to bar charts but display data in vertical columns.
 Use Case: Compare multiple categories or fields, such as open incidents per user group.
 How to Use:
1. Go to Reports > Create New > Column Chart.
2. Define the X-axis categories and Y-axis data points.
3. Configure grouping and color-coding options for better visualization.

6. Heatmaps
 Description: Visualize data density or frequency using color intensity.
 Use Case: Helpful for analyzing resource utilization, ticket distribution, or time-based
patterns.
 How to Use:
1. Go to Reports > Create New > Heatmap.
2. Select the data set and the criteria for the heatmap.
3. Configure color gradients to represent values.
7. Pivot Tables
 Description: Create matrix-style reports for multi-dimensional data analysis.
 Use Case: Useful for summarizing large datasets, such as incident counts by priority and
assignment group.
 How to Use:
1. Go to Reports > Create New > Pivot Table.
2. Define rows and columns based on fields to be analyzed.
3. Add aggregations (e.g., count, sum) to summarize data.

8. Maps
 Description: Plot geographic data on a map.
 Use Case: Useful for visualizing location-based data, such as incident hotspots or assets
by location.
 How to Use:
1. Go to Reports > Create New > Map.
2. Use location-related fields (e.g., city or latitude/longitude).
3. Configure map settings to display markers or regions.

9. Donut Charts
 Description: A circular chart similar to a pie chart but with a central hole.
 Use Case: Provides a visually distinct way to show proportions or distributions.
 How to Use:
1. Go to Reports > Create New > Donut Chart.
2. Define the data set and grouping field.
3. Save and use in dashboards for visual appeal.

10. Time Series Reports

 Description: Visualize changes over time, similar to line charts but with more detailed
time-based groupings.
 Use Case: Track metrics like incident resolution rates, SLA performance, or user activity
trends.
 How to Use:
 1. Go to Reports > Create New > Time Series Report.
2. Select time intervals (e.g., daily, weekly) and data fields.
3. Customize and analyze results.

11. Trend Reports

 Description: Analyze and predict trends based on historical data.
 Use Case: Used for forecasting workload, service demands, or system performance.
 How to Use:
1. Go to Reports > Create New > Trend.
2. Define the time range and key performance indicators (KPIs).
3. Adjust parameters for trend calculations.

12. Gauge Reports

 Description: Represent a single data point visually, like a speedometer.
 Use Case: Best for showing KPIs, such as ticket resolution percentage or system uptime.
 How to Use:
1. Go to Reports > Create New > Gauge.
2. Define thresholds for colors and performance markers.
3. Use gauges in dashboards for quick status updates.

Tips for Using Reports in ServiceNow:

 Custom Filters: Use conditions to focus reports on specific data.
 Scheduling: Schedule reports for automatic email delivery.
 Dashboards: Combine multiple reports in dashboards for holistic views.
 Interactive Filters: Enable interactive filters for end-user exploration.
 Drilldowns: Configure drilldowns to allow deeper data exploration.

Report on function fields

https://www.servicenow.com/docs/bundle/vancouver-now-intelligence/page/use/reporting/
concept/function-fields-reporting.html
 CMDB
CMDB is a repository that stores all the info about software and hardware of the organization
Use the ServiceNow® Configuration Management Database (CMDB) application to build
logical representations of assets, services, and the relationships between them that comprise the
infrastructure of your organization. Details about these components are stored in the CMDB as
configuration items (CIs) which you can use to monitor the infrastructure, helping ensure
integrity, stability, and continuous service operation.
Key CMDB tables
Key tables in the configuration management database (CMDB):
 The Base Configuration Item [cmdb] table, which is the core CMDB table for non IT CIs
(descending classes are non IT CIs).
 The core Configuration Item [cmdb_ci] table, which stores the basic attributes of all the
CIs. The admin, itil, or asset user role is required to access this table (descending classes
are IT CIs).
 The CI Relationship [cmdb_rel_ci] table, which defines all relationships between CIs.
A Configuration Item (CI) is a fundamental concept in IT Service Management (ITSM) and
Configuration Management, typically defined as any component that needs to be managed to
deliver an IT service. It is stored as a record in the Configuration Management Database
(CMDB) and represents physical or logical entities in your IT environment.

Examples of CIs:
1. Hardware:
 Physical devices used in IT infrastructure.
 o Servers, desktops, laptops.
o Network devices (routers, switches, firewalls).
o Storage devices (SAN, NAS).
o Mobile devices (smartphones, tablets).
2. Software:
 Applications or systems.
o Operating systems (e.g., Windows, Linux).
o Databases (e.g., MySQL, MongoDB).
o Middleware (e.g., Apache Tomcat).
o Business applications (e.g., CRM, ERP).
3. Services:
 Logical entities that deliver value to users or customers.
o IT services (e.g., email service, web hosting, database as a service).
o Business services (e.g., payroll, e-commerce platform).
o Cloud services (e.g., AWS Lambda, Azure Functions).
4. Other Components:
 Anything that needs to be tracked for IT management.
o Documentation (e.g., policies, SLAs).
o Virtual resources (e.g., VMs, containers).
o Licenses (e.g., software licenses).
o Network configurations (e.g., VPNs).

 cmdb Table
Purpose:
 The cmdb table is the base table in the CMDB hierarchy.
 It contains generic attributes shared across all records in the CMDB, including
Configuration Items (CIs) and other entities.
Attributes:
 Stores attributes common to all CMDB records, such as:
o sys_id (unique identifier).
o created_on (record creation timestamp).
 o updated_on (last update timestamp).
Scope:
 Broadest table in the CMDB structure.
 Includes all records, whether they are CIs or not.
Key Usage:
 Provides a foundation for extending specialized tables like cmdb_ci.
 Facilitates uniformity across all CMDB records.
 cmdb_ci Table
Purpose:
 The cmdb_ci table is a specialized child table of cmdb designed specifically for
Configuration Items (CIs).
 It acts as the parent table for all CI-related tables (e.g., servers, applications, network
devices).
Attributes:
 Stores attributes common to all CIs, such as:
o name
o manufacturer
o model
o operational_status
Scope:
 Focused only on Configuration Items (CIs).
 Further extended by tables like cmdb_ci_server and cmdb_ci_application for more
specialized CI types.
Key Usage:
 Defines common properties of CIs.
 Serves as the base for more specific CI types.

The ServiceNow CMDB Database Model is designed to efficiently manage Configuration

Items (CIs) and their relationships. Here's a summarized overview:

1. Hierarchical Table Structure

 Base Table (cmdb):
 o The root table that contains generic attributes shared across all Configuration
Items.
 CI Table (cmdb_ci):
o A specialized table for storing common CI-related attributes like name,
manufacturer, and operational status.
 Extended Tables:
o Specific CI types (e.g., servers, applications, network devices) extend the cmdb_ci
table and store attributes unique to those types.
o Examples: cmdb_ci_server, cmdb_ci_application.

2. Table Per Partition Model

 Data is logically partitioned into extended tables based on CI type.
 Common attributes are inherited from the parent (cmdb or cmdb_ci) table.
 CI-specific attributes are stored only in the extended tables, ensuring clarity and reducing
redundancy.

3. Relationships Between CIs

 Relationship Table (cmdb_rel_ci):
o Tracks relationships between CIs (e.g., "Server A hosts Application B").
 Relationship Type Table (cmdb_rel_type):
o Defines the types of relationships (e.g., "hosts," "depends on").

4. Key Advantages
 Scalability:
o Adding new CI types requires only extending the appropriate table.
 Efficiency:
o Common attributes are centralized, while specialized attributes are isolated.
 Flexibility:
o CIs and their relationships are easily extensible to fit unique organizational needs.

6. Logical Partitioning vs Physical Storage

 Logical Partitioning:
o Each CI type is logically isolated in its own table (e.g., servers in cmdb_ci_server).
  Physical Storage:
o All tables are part of a relational database, enabling efficient queries and
relationships.

Suggested Relationship Types

When you select a server as a Configuration Item (CI) and navigate to add a relationship, the
appearance of filters based on suggested relationship types is a part of the CMDB's
functionality to help you define relationships more accurately and efficiently. Here’s an
overview of how this process typically works and why you see those filters:
1. Selecting a Server as a CI
 When you choose a server as the CI in the relationship editor, the system recognizes it as
the base CI.
 This serves as the reference point for establishing a relationship with another CI.
2. Suggested Relationship Types
 After selecting the server, you can choose a relationship type from the suggested options
(e.g., "Runs on," "Hosts," "Provides Power for").
 These suggested relationship types are context-sensitive and depend on the class of the
base CI (in this case, the server) and its hierarchy.
3. Automatic Filters
 Once you select a relationship type, the system may automatically apply filters to guide
you in selecting the related CI that makes sense within the context of that relationship.
Here’s why you see these filters:
 Contextual Filtering: The filters narrow down the available CIs based on logical criteria
related to the selected relationship type. For example:
o If you selected "Runs on," the system might filter to show only eligible CIs that
can run on a server, such as applications or services.
o If you selected "Provides Power for," the filters might show power supply units or
racks that can provide power to the selected server.
 Data Integrity: The filters help maintain data integrity by ensuring that only relevant CIs
are presented, reducing the chance of selecting an inappropriate or illogical CI.
 User Guidance: The automatic filters serve as guidance for users, making it easier to
identify the correct CI to relate to the selected server without having to sift through
irrelevant options.
4. Example Scenario
  If you choose a Linux Server as the CI and select the suggested relationship type "Runs
on," the system might filter to show only application CIs that can be hosted on Linux
servers, such as:
o Web Applications
o Database Services
 If you were to select "Provides Power for," the system might filter to show related
hardware components like:
o Power Distribution Units (PDUs)
o Racks or UPS units
5. Conclusion
The automatic filters that appear when adding relationships in a CMDB are designed to
enhance usability and ensure that users can accurately define relationships between CIs. By
focusing on relevant options, these filters support users in creating a logical and meaningful
structure within the CMDB, ultimately leading to better management and understanding of the
IT environment.

Suggested Relationships Table

 The filters are often tied to the cmdb_rel_type_suggest table, which stores the suggested
relationship types based on CI classes.
 Each entry in this table can include criteria for filtering compatible CIs based on the
selected relationship type.
Query Builder
A query builder is a tool that helps you search for information in a database (like a CMDB)
without needing to know complicated programming languages or technical details. It provides a
drag-and-drop interface, which means you can easily pick and choose what you want to
search for by dragging items around instead of writing a lot of code. Think of it like creating a
shopping list where you select what you want from different categories instead of writing a long
essay about it.
1. Data Retrieval and Reporting
 Business Intelligence (BI): Users can generate reports on sales, customer behavior, or
operational performance by querying relevant data from databases.
 Data Analytics: Analysts can use query builders to pull specific datasets for analysis,
helping organizations make data-driven decisions
2. Configuration Management Databases (CMDB)
 Configuration Item (CI) Management: Query builders allow IT teams to easily find
and manage CIs and their attributes, such as status, relationships, and dependencies.
  Incident and Problem Management: Users can quickly search for CIs related to
incidents or problems to facilitate troubleshooting and resolution.
3.E-commerce Platforms
 Product Search: Customers can find products based on criteria like category, price
range, availability, or ratings.
 Order Management: Staff can query orders by status, customer, or date to track and
manage sales effectively

CMDB Health in ServiceNow

CMDB Health is a set of metrics and dashboards provided by ServiceNow to ensure that the
Configuration Management Database (CMDB) is accurate, reliable, and useful for IT
operations. A healthy CMDB is critical for enabling efficient processes like incident
management, problem management, change management, and service mapping.
The CMDB Health model focuses on three core dimensions: Completeness, Compliance, and
Correctness.

Core Dimensions of CMDB Health

1. Completeness
 Definition: Ensures that all required fields and relationships for CIs are populated in the
CMDB.
 Checks:
o Are all mandatory attributes (e.g., Name, Type, Serial Number) populated?
o Are all expected relationships between CIs defined?
 Examples of Issues:
o Missing serial numbers for hardware CIs.
o Incomplete dependency mappings between CIs.
 How to Improve:
 o Use Discovery and Service Mapping to gather data and fill in missing attributes
or relationships.

2. Compliance
 Definition: Ensures that the CIs meet governance and policy standards, such as naming
conventions, field formats, and supported versions.
 Checks:
o Are naming conventions followed (e.g., server names must follow a specific
pattern)?
o Are software versions compliant with organizational standards?
 Examples of Issues:
o CIs that don’t comply with naming standards.
o CIs with unsupported or outdated software versions.
 How to Improve:
o Implement CMDB Governance Policies to standardize CI data.
o Use Data Certification to ensure compliance with predefined rules.

3. Correctness
 Definition: Ensures the data in the CMDB is accurate and reflects the current state of the
IT environment.
 Checks:
o Are CI attributes (e.g., IP address, status) accurate?
o Are there duplicate or stale CIs?
 Examples of Issues:
o Incorrect IP address or status (e.g., a CI marked as "active" but decommissioned).
o Duplicate or outdated (stale) CIs.
 How to Improve:
o Use Discovery to update the CMDB regularly.
o Deduplicate records using Identification and Reconciliation Rules.

CMDB Health Dashboard

ServiceNow provides a CMDB Health Dashboard to monitor and manage the health of the
CMDB. This dashboard helps visualize the health scores for each of the three dimensions
(Completeness, Compliance, and Correctness) across all CIs or specific CI classes.
Key Features:
1. Health Scores:
o Shows scores for completeness, compliance, and correctness as percentages.
o Helps identify which CI classes need attention.
2. Drill-Down Capabilities:
o View detailed metrics for specific CIs, classes, or relationships.
o Identify which CIs are causing poor health scores.
3. Actionable Insights:
o Recommendations and workflows for improving CMDB health.
o Ability to assign tasks for remediation (e.g., fixing orphan or stale CIs).

In ServiceNow's CMDB (Configuration Management Database), terms like orphan CI and

stale CI are used to describe certain types of data quality issues that can negatively impact the
accuracy and usefulness of the CMDB. These terms are part of the CMDB Health Metrics,
which are categorized under completeness, correctness, and compliance.
Here’s an explanation of these terms:

1. Orphan CI
An Orphan CI (Configuration Item) is a CI in the CMDB that lacks valid relationships with
other CIs.
Characteristics:
 It does not have parent or child relationships defined.
 It is "isolated" within the CMDB, which makes it difficult to understand its role in the IT
infrastructure.
 Orphan CIs typically indicate a lack of proper dependency mapping or missing
relationships.
Why It's a Problem:
 Without relationships, an orphan CI cannot contribute to service mapping or impact
analysis.
 It reduces the effectiveness of incident management, change management, and
disaster recovery processes because its dependencies and impacts are unclear.
Example:
 A server that is listed in the CMDB but has no relationships defined with applications or
services running on it.
Resolution:
 Use tools like Service Mapping or Discovery to identify and establish accurate
relationships for orphan CIs.
 Regularly review and update dependency mappings.

2. Stale CI
A Stale CI is a CI in the CMDB that has not been updated within a defined timeframe,
indicating that it may no longer be accurate or relevant.
Characteristics:
 The last update timestamp is older than the configured threshold (e.g., 90 days or
more).
 It may represent an asset that has been decommissioned, replaced, or changed without
the CMDB being updated.
Why It's a Problem:
 Stale CIs introduce data inaccuracies into the CMDB.
 They can lead to incorrect impact analysis, inefficient resource allocation, and challenges
in compliance reporting.
 Stale data makes it difficult to trust the CMDB for decision-making.
Example:
 A network device that was replaced three months ago but still exists in the CMDB with
outdated details.
Resolution:
 Use Discovery, Event Management, or other data sources to regularly update the
CMDB.
 Establish thresholds for stale data and monitor them through the CMDB Health
Dashboard.
 Implement processes to retire or archive outdated CIs.

Other Common CMDB Issues

1. Duplicate CI:
 o Multiple entries for the same CI, often due to incorrect data collection or
reconciliation.
o Resolution: Use identification rules to merge duplicates and maintain unique
records.
2. Missing Relationship CI:
o CIs that have incomplete or incorrect relationships, affecting service mapping and
impact analysis.
o Resolution: Identify missing relationships and update the dependency mappings.
3. Unauthorized CI:
o CIs that do not comply with defined policies, such as missing mandatory fields or
unsupported software versions.
o Resolution: Validate compliance and correct any discrepancies.

Why Address These Issues?

 Improve CMDB Health: Ensures accuracy, completeness, and compliance.
 Enable Effective ITSM Processes: Reliable data leads to better incident, problem, and
change management.
 Enhance Service Visibility: Accurate relationships improve service mapping and
dependency views.
 Support Automation: Trustworthy data is essential for automating workflows like
impact analysis or disaster recovery.

How to Monitor and Fix These Issues

1. CMDB Health Dashboard:
o ServiceNow provides the CMDB Health Dashboard to measure completeness,
compliance, and correctness metrics, including orphan and stale CIs.
2. CMDB Query Builder:
o Helps visualize CI relationships and identify issues like orphans or missing
dependencies.
3. Discovery and Service Mapping:
o Regularly run Discovery to update CI data and identify stale or orphaned records.
o Use Service Mapping to establish dependencies and ensure completeness.
4. Governance Policies:
o Set up governance processes and automated rules to detect and remediate orphan,
stale, or duplicate CIs.
Notification
Outbound Email
Notifications send outbound email to one or more recipients in response to specific activities in
ServiceNow. Notifications can be sent when:
 Records are inserted or updated
 Events are generated
 The Notification activity executes in a workflow
 The Send Email action executes in a flow
There are three sections to configure in a Notification.
 When to send
 Who will receive
 What it will contain
When to send has 3 options – trigger, event, record insert or update
When to Send → Triggered
You will create notification here and then set send when as "triggered" now this notification
will execute once you will have notification action added/execute on your flow designer.
How to Trigger a Notification in Workflow Studio (Flow designer)
1️⃣ Ensure Notification is Set Up
 Before using it in a workflow, create an email notification in System Notification →
Email → Notifications.
 Set "Send when" to "Triggered" in the When to Send tab.
2️⃣ Add the Notification Action in Workflow Studio
 In Workflow Studio, create a new Action.
 Add an Action Step to Trigger Notification.
3️⃣ Configure the Notification Step
 Record: Drag-and-drop a record (Incident, Change, Problem, User, etc.).
o 📌 Example: If you're sending an incident update email, select the Incident record.
 Table Name: Auto-fills based on the selected record.
 Notification: Choose the notification you created earlier.
 If the notification is not linked to a record, leave the Record field blank.
4️⃣ Handle Errors
 If this step fails, define whether:
 o The workflow continues to the next step.
o It stops and triggers error handling.

When to Send → Event is Fired

 Used for: Notifications triggered via the Event Queue (gs.eventQueue()).
 How it works:
o The notification is asynchronous and triggered when an event is fired from the
event queue.
o These notifications are more flexible, allowing for notifications across different
tables or workflows.
🔹 Example: Sending a notification when an incident is closed.
javascript
CopyEdit
if (current.state == 7) { // Incident is closed
gs.eventQueue("incident.closed", current, current.assigned_to.email, "");
}
 The event "incident.closed" is fired.
 The system processes the event later and triggers any notifications linked to that event.

Advanced Condition
Use a server-side script to evaluate conditions that cannot be created using the Condition field.
The script has access to two global variables:
 current: The target table record associated with the notification (All notifications).
 event: The event object that triggered the notification (only available for notifications
sent when Event is fired).
The script must set the answer variable to either true or false. If there is no script, the field
returns true. Both the Condition and Advanced Condition fields must return true for the
notification to be sent.
The demo script shown compares the month and day of the Occasion date to today to see if it
matches today's date. The script also checks that the occasion is a Work Anniversary.
Note :- we can define the script for notification in the “notification email script” module and
can call this script in our notification by adding this “$
{mail_script:CountOverdueNeedItTasksAssignedTo}”” in the “what it will contain” section.

Notifications that have the same target table and recipients are considered duplicates if the
weights are different. If weights are same, an additional evaluation is done to check if the
subject and the body (excluding watermark) are same to qualify as duplicate notification. When
there are duplicate notifications, the system only sends the notification with the highest weight.
All other notifications are moved from the Outbox to the Skipped mailbox. The default value 0
causes the system to send the notification (assuming the conditions are met).
For example, suppose that a service desk agent adds a comment to an incident and shortly
thereafter closes it. By default, these actions trigger both the Incident commented and Incident
Closed notifications.
However, both notifications are from the Incident table and also notify the incident caller. The
system only sends the notification with the highest weight, which in this case is the Incident
Closed notification.
Note: The SMTP Sender scheduled job determines how often to send email. By default, this job
runs every minute.

Outbound notifications can be sent through :-

Events, Scheduled Notifications, Workflows & Flow Designer, Notifications Module (Record
Insert/Update/Delete) (Email->Notification), Business Rules, Inbound Email Actions,
GlideEmailOutbound API

Inbound email
https://developer.servicenow.com/dev.do#!/learn/learning-plans/xanadu/
servicenow_administrator/app_store_learnv2_automatingapps_xanadu_inbound_email_actions
Watermark
In simple terms, a watermark in the context of ServiceNow and email communication is a
unique identifier embedded in an email's subject line or body. It acts as a tag that links the
email to a specific record (like an incident or task) in the ServiceNow system.

What Exactly Is a Watermark?

 It is a special string of characters (e.g., Ref:MSG0000008), generated by ServiceNow.
 The watermark is added automatically to outbound emails (emails sent from
ServiceNow).
  It serves as a reference code that the system can recognize when someone replies to the
email.

Why Is It Called a Watermark?

Just like a physical watermark on paper (used for authenticity and identification), an email
watermark is:
 Embedded in the email and not obtrusive.
 Used to identify and authenticate the context of the communication.

Where Can You See the Watermark?

1. Subject Line:
o Example: Incident INC0005574 - Unable to Access Account (Ref:MSG0000008)
o Here, Ref:MSG0000008 is the watermark.
2. Email Body:
o Example (at the bottom of an email):
This email is associated with Ref:MSG0000008.

How ServiceNow Uses the Watermark

1. Outbound Email:
o ServiceNow generates a unique watermark for the email.
o The watermark is added to the subject line or email body.
o Example:
 Outbound email sent with subject:
Incident INC0005574 - Unable to Access Account (Ref:MSG0000008)
 The watermark MSG0000008 is now linked to the incident record
INC0005574.
2. Inbound Email (Reply):
o When the user replies to the email, the reply typically includes the watermark.
o ServiceNow reads the watermark from the reply and links the response to the
appropriate record.

What Happens Without a Watermark?

If the reply doesn't contain a watermark:
  ServiceNow tries other methods to identify the record, such as:
o Reply-To Header: Contains metadata that links to the original email.
o Recognized Patterns: Scans the subject line for a record number like
INC0005574.

In Summary
A watermark is:
 A unique reference code automatically embedded in emails.
 Used by ServiceNow to track and link email replies to specific records.
 Essential for automating and streamlining email-based communication workflows
NOTE: By default, inbound emails of the Forward type always generate new incidents
regardless of the presence of a watermark. If this behavior does not match desired business
logic, change the recognized reply and forward prefixes to treat forwards like replies.
Type: Available types are:
 New: An email that is not recognized as a reply or forward.
 Reply: An email with a watermark, with an In-Reply-To email header, or whose subject
line begins with a recognized reply prefix.
 Forward: An email whose subject line begins with a recognized forward prefix, even if
the email also contains a watermark or In-Reply-To header.

The function provided is a typical template for an email action script in ServiceNow, allowing
custom logic to be executed when handling inbound or outbound emails. Here’s a detailed
explanation of each parameter:

1. current:
 Type: GlideRecord
 Description: Represents the record in the target table that is associated with the email
action.
 Purpose:
o You can use it to interact with the associated record.
o For example, if the email is linked to an incident, current would point to the
specific incident record.
The function provided is a typical template for an email action script in ServiceNow, allowing
custom logic to be executed when handling inbound or outbound emails. Here’s a detailed
explanation of each parameter:

1. current:
 Type: GlideRecord
 Description: Represents the record in the target table that is associated with the email
action.
 Purpose:
o You can use it to interact with the associated record.
o For example, if the email is linked to an incident, current would point to the
specific incident record.
Example:
javascript
Copy code
if (current.isValidRecord()) {
current.comments = "Email received and processed.";
current.update();
}

2. event:
 Type: GlideRecord
 Description: Represents the event that triggered the email action, if applicable.
 Purpose:
o Provides context about the triggering event, allowing the script to perform actions
based on event details.
o

3. email:
 Type: EmailWrapper
 Description: Encapsulates the details of the email being processed.
 Purpose:
o Provides access to email content, headers, attachments, etc.
o Useful for extracting information from inbound emails.
Key Properties:
 email.subject: The subject line of the email.
 email.body_text: The plain-text body of the email.
 email.body_html: The HTML body of the email (if available).
 email.to: The "To" recipients.
 email.from: The sender's email address.
 email.attachments: Access to email attachments.

4. logger:
 Type: ScopedEmailLogger
 Description: Provides logging capabilities specific to the email action.
 Purpose:
o Allows logging of messages to facilitate debugging or tracking email processing.
o Log messages appear in the System Logs (System Logs > Email Logs).
Example:
logger.debug("Processing email for record: " + current.number);
logger.error("An error occurred while handling email: " + email.subject);

5. classifier:
 Type: EmailClassifier
 Description: Contains classification information for the email.
 Purpose:
o Provides details about how the system classified the email, such as whether it’s a
reply, forward, or a new message.
o Allows custom handling based on the classification.
Key Properties:
 classifier.type: The type of email action (e.g., reply, forward, or new).
 classifier.watermark: The watermark extracted from the email (if applicable).

GlideSysAttachment API
The GlideSysAttachment API in ServiceNow allows you to programmatically manage file
attachments in your instance. It provides methods to upload, download, delete, and manipulate
attachments associated with records.
Methods in GlideSysAttachment
1. write(tableName, recordSysId, fileName, fileContent)
Uploads an attachment to a record.
 Parameters:
o tableName (string): The name of the table (e.g., "incident").
o recordSysId (string): The sys_id of the record.
o fileName (string): The name of the file.
o fileContent (string): The Base64-encoded content of the file.
 Returns: The sys_id of the created attachment record.
2. read(tableName, recordSysId, fileName)
Retrieves the content of a specific attachment.
 Parameters:
o tableName (string): The name of the table.
o recordSysId (string): The sys_id of the record.
o fileName (string): The name of the file to read.
3. getAttachments(recordTableName, recordSysId)
Retrieves all attachments associated with a record.
 Parameters:
o recordTableName (string): The name of the table.
o recordSysId (string): The sys_id of the record.
 Returns: A GlideRecord object containing the attachments.
4. deleteAttachment(sysId)
Deletes a specific attachment by its sys_id.
 Parameters:
o sysId (string): The sys_id of the attachment to delete.
Explanation of SLA Repair in ServiceNow
The SLA Repair functionality in ServiceNow is designed to correct SLA records to ensure
their timing and duration information is accurate. This feature is particularly useful when
system anomalies or configuration changes lead to incorrect SLA data. Below is an explanation
of its purpose, usage, and considerations:

Purpose of SLA Repair

1. Ensure Data Accuracy:
o Fix inaccuracies in SLA timing and duration due to changes in definitions,
schedules, or conditions.
2. Handle Changes in SLA Configurations:
o Reflect updates made to SLA definitions or conditions for active Task SLAs.
3. Resolve System Anomalies:
o Correct errors caused by unexpected system behavior or anomalies.

How SLA Repair Works

1. Remove and Recreate SLA Records:
o SLA repair removes the current SLA record and recreates it from the beginning,
recalculating all timing and duration information.
o It uses the task's history to determine the accurate SLA state and timing.
2. Recreating Workflows:
o When SLAs are repaired, the associated workflows are also recreated.
o The workflow follows the repair path for activities like SLA Percentage Timers,
avoiding unnecessary repetitive activities.
3. Dot-Walk Field Behavior:
o The repair considers only the final state of dot-walk fields (e.g.,
incident.caller_id.location).
o If values of dot-walk fields change during SLA execution, the repair process uses
the most recent value to calculate the SLA's state.
4. Creating New SLAs:
o If new SLA definitions have been added since the task was created or updated,
SLA repair will create new SLAs for the task, ensuring they adhere to the latest
definitions.
When to Use SLA Repair
 Definition or Schedule Changes:
o If the SLA definition or schedule has been modified and active SLAs need to
reflect these changes.
 Condition Updates:
o If the conditions for triggering, pausing, or stopping an SLA have been updated.
 System Anomalies:
o To address anomalies that result in incorrect SLA timing or state.

How to Perform SLA Repair

1. Repair a Single SLA:
o Navigate to the form for the specific SLA record.
o Use the Repair SLA option available in the record's context menu.
2. Repair Multiple SLAs:
o Navigate to the list of SLA records (e.g., Task SLAs).
o Select multiple records and choose the Repair SLA option from the list actions.

Limitations and Considerations

1. Not Available for SLA Definitions:
o You cannot directly repair an SLA definition, as this could affect a large number of
records and impact system performance.
2. Dot-Walk Field Limitations:
o The repair process considers only the final state of dot-walk fields, not their
historical values.
3. Performance Impact:
o Repairing multiple SLAs simultaneously can have a significant performance
impact, especially on large datasets.

Configuring SLA Repair

 Control via System Properties:
o Navigate to Service Level Management > Properties > SLA Repair to configure
system properties controlling SLA repair workflows.
 Repair Path in Workflows:
 o Workflows used in the repair process must include a defined repair path in
activities like SLA Percentage Timers to optimize processing during repair.
<td> <img ng-src="{{key.image}}" width="50" height="50" alt="{{key.track_name}}" />
{{key.name}} </td>

Key.album.images[0].url
Key.artists[0].name
Key.name
Key.external_urls

// input = JSON.parse(input);
// console.log("input",input);

// try {
// var r = new sn_ws.RESTMessageV2('spotify', 'search');
// r.setQueryParameter('q', input.userInput );
// var response = r.execute();
// var responseBody = response.getBody();
// responseBody = JSON.parse(responseBody);
// data.result = responseBody;
// console.log(data.result);
// }
// catch (ex) {
// var message = ex.message;
// gs.error('Error: ' + message);
// }
function createRequest(record) {

var ga = new GlideRecord('sys_user');

if(ga.get(record.u_name)){

var id = GlideGuid.generate(null);
var cart = new Cart(id);
var item = cart.addItem('6c82faddc3bb5210807fb7ddd401313b');

cart.setVariable(item, 'requested_for', ga);

cart.setVariable(item, 'description', record.u_description);
cart.setVariable(item, 'employee_number', record.u_employee_number);
cart.setVariable(item, 'location', record.u_location);
cart.setVariable(item, 'title', record.u_title);
cart.setVariable(item, 'start_date', record.u_start_date);

var rc = cart.placeOrder();

gs.addInfoMessage('Request Item Created: ' + rc.number);

return rc;
}
}

var gr = new GlideRecord('u_employee_data_import_set');

gr.query();

while (gr.next()) {
if (!gr.u_name || !gr.u_start_date) {
gs.info("Missing fields");
continue;
}

var startDate = new GlideDateTime(gr.getValue('u_start_date'));

if (!startDate.isValid()) {
gs.info("Invalid start date");
continue;
}

var currentDate = new GlideDateTime();

if (startDate >= currentDate) {

var gu = new GlideRecord('sys_user');

if (gu.get(gr.u_name)) {
var ritm = new GlideRecord('sc_req_item');
ritm.addQuery('requested_for', gr.u_name);
ritm.addQuery('cat_item', '6c82faddc3bb5210807fb7ddd401313b');
ritm.query();

if (!ritm.next()) {
var requestID = createRequest(gr);
var newRitm = new GlideRecord('sc_req_item');
newRitm.addQuery('request', requestID);
newRitm.query();
if(newRitm.next()){
gs.info("founded");
}
} else {
gs.info("RITM already created for: " + gu.name);
 }
} else {
var incidentGR = new GlideRecord('incident');
incidentGR.initialize();
incidentGR.short_description = 'User not found: ' + gr.u_name;
incidentGR.caller_id = '6816f79cc0a8016401c5a33be04be441'; // System admin
var incID = incidentGR.insert();
gs.info("Incident created for: ");
}
} else {
gs.info("Start date is in the past");
continue;
}
}
var gr = new GlideRecord('u_employee_data_import_set');
gr.query();

while (gr.next()) {
if (!gr.u_name || !gr.u_start_date) {
gs.info("Missing fields");
continue;
}

var startDate = new GlideDateTime(gr.getValue('u_start_date'));

if (!startDate.isValid()) {
gs.info("Invalid start date");
continue;
}

var currentDate = new GlideDateTime();

if (startDate >= currentDate) {

var gu = new GlideRecord('sys_user');

if (gu.get(gr.u_name)) {
var ritm = new GlideRecord('sc_req_item');
ritm.addQuery('requested_for', gr.u_name);
ritm.addQuery('cat_item', '6c82faddc3bb5210807fb7ddd401313b');
ritm.query();

if (!ritm.next()) {
// var requestID = createRequest(gr);
var newRitm = new GlideRecord('sc_req_item');
 newRitm.initialize();
newRitm.requested_for = gr.getValue('u_name');
newRitm.cat_item = '6c82faddc3bb5210807fb7ddd401313b';
var id = newRitm.insert();
gs.info("created : " + id.number);
} else {
gs.info("RITM already created for: " + gu.name);
}
} else {
var incidentGR = new GlideRecord('incident');
incidentGR.initialize();
incidentGR.short_description = 'User not found: ' + gr.u_name;
incidentGR.caller_id = '6816f79cc0a8016401c5a33be04be441'; // System admin
var incID = incidentGR.insert();
gs.info("Incident created for: ");
}
} else {
gs.info("Start date is in the past");
continue;
}
}