ServiceNow Admin

Instances :
In ServiceNow, instances refer to separate environments where the
platform is installed and used. Each instance operates independently and
can serve different purposes within the ServiceNow ecosystem.

#. Types of Instances:
i. Developer Instance:

❖​Personal sandbox for development and experimentation.

❖​Available for free through the ServiceNow Developer Program.

ii. QA Instances:

❖​Include Development, Test/QA, and Staging instances.

❖​Used for development, testing, and validation before moving to
production.

iii. Production Instance:

❖​The live environment where end-users interact with the system.

❖​Contains real business data and is highly restricted.

Personalization and Configuration:

1.​ Personalization:
○​ User-Specific: Customizations that affect only an individual
user's view or experience.
○​ No System-Wide Impact: These changes don't alter the
system for all users.
○​ Examples:
■​ Changing list layout or filter views.
■​ Personalizing form views using the "Personalize Form"
feature.
■​ Creating personal UI themes or dashboards.
2.​ Configuration:
○​ System-Wide: Changes made to the system that affect all
users.
○​ Impacts Core Functionality: These changes alter the behavior
or structure of applications for everyone.
○​ Examples:
■​ Modifying forms and fields in the form designer.
■​ Creating or editing business rules, client scripts, or
workflows.
■​ Adding or changing tables and fields in the data model.

Users, Groups, and Roles:

1.​ Users:
○​ Definition: Individuals who have access to the ServiceNow
platform.
○​ Attributes: Each user has a unique user ID, password, and
associated information like name, email, and department.
○​ Function: Users are assigned specific roles that determine
their level of access to the platform.
○​ Examples: Employees, administrators, managers, or external
stakeholders.
2.​ Groups:
○​ Definition: A collection of users who share a common purpose
or function.
○​ Purpose: Groups are used to manage user permissions more
efficiently by assigning roles to a group instead of individual
users.
○​ Function: Groups can be assigned to tasks such as approval
groups, assignment groups for incidents, or change
management teams.
○​ Examples: IT Support Team, HR Department, Change
Management Team.
3.​ Roles:
○​ Definition: A collection of permissions that define what a user
or group can do in ServiceNow.
○​ Purpose: Roles control access to features, applications, and
data within the platform.
 ○​ Function: Users or groups are assigned roles to determine
their level of access.
○​ Examples:
■​ admin: Full access to all system features and data.
■​ itil: Access to incident, problem, and change
management.
■​ approver_user: Role for users who can approve
requests.

Relationship Between Users, Groups, and Roles:

●​ Users are assigned Roles, either directly or through Groups, which

are also assigned roles.
●​ Groups simplify management by allowing roles to be assigned to
many users at once.
Best Practice:

●​ Create a group for all users who need the same role, then assign that
role to the group instead of assigning it individually to each user.

Users Tables:
User Tables:

1.​ User: sys_user

2.​ Group: sys_user_group
3.​ Role: sys_user_role
4.​ User Has Role: sys_user_has_role
5.​ Group Members: sys_user_grmember
6.​ Group Has Role: sys_group_has_role

Note: Prefix with .LIST to access these tables.

Impersonation:

Impersonation allows a user (usually an admin) to temporarily assume the

identity of another user within the ServiceNow platform.

●​ Purpose: To test permissions, roles, or troubleshoot issues as if

logged in as the impersonated user.
●​ Usage: Available to users with admin roles; accessed via the user
profile menu.
●​ Effect: The impersonating user sees exactly what the impersonated
user sees, including their assigned tasks, forms, and restricted data.
●​ Limitations: Changes made during impersonation are real and affect
the system; however, the impersonating user retains their original
permissions in the background.
●​ Security: Impersonation activity is logged for audit purposes.

Dictionary:

The Dictionary defines the structure and behavior of fields (columns)

within a table in ServiceNow.

●​ Components:
○​ Data Type: Specifies the type of data (e.g., string, integer, date)
that the field can hold.
 ○​ Attributes: Controls field properties like length, default value,
and validation rules.
○​ Relationships: Defines how fields relate to other tables,
including reference fields and foreign keys.
●​ Management: Accessed through the System Definition > Dictionary
module.
●​ Customization: Allows admins to add or modify fields, set mandatory
rules, and configure audit tracking.
●​ Impact: Changes in the dictionary affect how data is stored,
displayed, and validated across the platform.

Extending Tables:

In ServiceNow, extending tables refers to the process of creating a new

table that inherits fields and functionality from an existing table (parent
table). This allows for the reuse of standard functionality while adding
custom fields and behavior specific to the new table.

●​ Extending a Table: Creates a new table (child) that inherits fields

and behavior from an existing table (parent).
●​ Inheritance: The child table inherits fields, scripts, and workflows
from the parent table but can add custom fields or functionality.
●​ Common Parent Tables:
○​ Task Table: Extended by Incident, Problem, Change.
○​ CMDB Table: Extended by specific CI types like servers.
●​ Usage: Extend when creating a new entity that shares common fields
and functionality with an existing table.
●​ Benefits: Reusability, scalability, and maintainability of inherited
functionality.
●​ Creation: Go to System Definition > Tables and select the parent
table in the Extends Table field.

Note: Use Dictionary Override to configure fields inherited from

the Parent table in the Child Table.

Update Sets:
A collection of customizations and configurations that can be moved
between instances (e.g., from development to production).

●​ Purpose: Used to capture changes made in one instance and

transfer them to another, ensuring consistency across environments.
●​ Captures: Includes customizations like business rules, client scripts,
forms, fields, workflows, and UI policies.
●​ Does Not Capture: Data records (like incidents, users, or
configuration items) are not included in update sets.
Steps to Export an Update Set:

1.​ Create Update Set: Navigate to Local Update Sets, create a new one,
and set it to "In Progress."
2.​ Make Changes: Customize your instance; changes are captured
automatically.
3.​ Complete Update Set: Set the update set to "Complete" when done.
4.​ Export: Go to Retrieved Update Sets, select it, and export it as XML.
Steps to Import an Update Set:

1.​ Upload XML: In the target instance, go to Retrieved Update Sets, and
import the update set from XML.
2.​ Preview: Select the update set and click "Preview Update Set" to
check for conflicts.
3.​ Resolve Conflicts: If any conflicts arise, resolve them manually.
4.​ Commit: Once successful, commit the update set to apply the
changes.

Data Import:
Steps for Data Import in ServiceNow:

1.​ Prepare Data: Create a data file (e.g., CSV, Excel) with the necessary
fields.
2.​ Load Data: Go to Administration > DataSource > Create New, attach
the file, and load all records.
3.​ Create Transform Map: Navigate to Transform Maps, map the
source fields to the target table fields.
4.​ Run Transform: Execute the transform to apply data to the target
table.
 5.​ Review Data: Check the import logs and review the data in the target
table for accuracy.
6.​ Fix Errors: Address any issues found during the import (e.g., through
error logs).

Scripts in ServiceNow:
1. Client Script:

●​ Runs On: Executes in the user's browser.

●​ Purpose: Enhances user experience by managing how forms and UI
elements behave based on user actions.​
Types:
○​ onLoad(): Executes when a form loads; used for initial setup.
○​ onChange(): Executes when a field value changes; used to
update other fields or UI elements dynamically.
○​ onSubmit(): Executes when the form is submitted; used for
final validation or modifications before submission.
○​ onCellEdit(): Executes when a cell in a list is edited; used
for dynamic list behaviors.
●​ Common Uses:
○​ Form Validation: Check field values before submission to
ensure data integrity.
○​ Dynamic Updates: Show or hide fields based on user
selections.
○​ Default Values: Automatically set field values based on user
actions or form conditions.
2. Server-Side Script:

●​ Runs On: Executes on the server.

●​ Purpose: Manages data processing, business logic, and interactions
with the database.​
Types:
○​ Business Rules: Run in response to database operations (e.g.,
insert, update, delete) to enforce business logic.
○​ Script Includes: Reusable server-side code that can be called
from other scripts or components.
 ○​ Scheduled Jobs: Execute scripts on a defined schedule to
perform routine tasks.
○​ REST/SOAP Web Services: Handle incoming or outgoing web
service requests for integrations.
●​ Common Uses:
○​ Data Manipulation: Create, update, or delete records in
ServiceNow tables.
○​ Business Logic: Implement rules that define how data should
be processed or validated.
○​ Integrations: Communicate with external systems or services.

UI Policies:

●​ Purpose: Control the behavior and appearance of form fields based

on conditions.
●​ Runs On: Client side (browser).
Common Uses:

●​ Visibility: Show or hide fields based on form data.

●​ Read-Only: Make fields read-only or editable based on conditions.
●​ Mandatory: Set fields as mandatory or optional based on user input
or other field values.
Types:

●​ UI Policy Actions:
Define specific actions (e.g., show/hide, read-only,
mandatory) for fields.
●​ Conditions: Specify when the UI Policy actions should apply.
Example: Show a field only if a certain checkbox is selected.

Configuration:

●​ Navigate to: System UI > UI Policies.

●​ Create: New UI Policy and define conditions and actions.

UI Actions:

●​ Purpose: Add buttons, links, or context menu items that perform

specific actions on a record or form.
 ●​ Runs On: Client side (browser), with server-side processing if
needed.
Common Uses:

●​ Buttons:
Add custom buttons to forms or lists to trigger actions like
saving data, executing scripts, or opening new forms.
●​ Links: Create links in forms or lists to navigate to other records or
pages.
●​ Context Menu Items: Add options to the context menu for additional
functionality.
Types:

●​ Form Buttons:
Appear on form views; used to perform actions on a
single record.
●​ List Buttons: Appear on list views; used to perform actions on
multiple records.
●​ Form Links: Provide navigation or action links within forms.
Configuration:

●​ Navigate to: System Definition > UI Actions.

●​ Create: New UI Action and define properties like name, table, and
script.
Example: A button to "Approve" an incident that updates the status to “Approved.”

Business Rules:

●​ Purpose: Server-side scripts that automate processes and enforce

business logic in ServiceNow.
●​ Execution: Runs on the server when records are inserted, updated,
deleted, or queried.
Types:

●​ Before:
Executes before the record is saved to the database; used for
validation or modifications.
●​ After: Executes after the record is saved; used for post-processing,
such as triggering notifications or additional workflows.
 ●​ Async: Runs asynchronously after the record is saved; used for
non-critical tasks like sending notifications or integrating with external
systems.
●​ Display: Runs when a form is loaded to manipulate data before it is
displayed to the user.
Example: A Business Rule that automatically sets the priority of an incident to "High" if
the impact is set to "Critical" during record creation.

Script Include:

●​ Purpose: Server-side JavaScript code in ServiceNow used to

encapsulate reusable functions and business logic.
●​ Execution: Invoked from server-side scripts (like Business Rules) or
client-side scripts (like Client Scripts) using GlideAjax.
Types:

●​ Classless: Contains standalone functions that can be called directly.

●​ Class-based: Defines a class with methods that can be instantiated
and used across the instance.
Use Cases:

●​ Encapsulating complex business logic that needs to be reused across

different parts of the platform.
●​ Handling integrations with external systems by writing reusable API
call functions.

Access Control List (ACLs):

●​ Purpose: Security rules that define permissions for accessing

records, fields, and UI elements in ServiceNow.
●​ Scope: Can be applied at the table, record, or field level.
Components:

●​ Roles: Specifies which user roles can access the resource.

●​ Conditions: Logical conditions that must be met for access.
 ●​ Scripts: Custom scripts to define more complex conditions or logic
for access.
Types:

●​ Table: Controls access to all records in a specific table.

●​ Field: Controls access to specific fields within a table.
●​ Record: Controls access to specific records within a table.
Management:

●​ Configured through the System Security > Access Controls module in

ServiceNow.
Example: Restricting access to sensitive data fields (e.g., salary information) or allowing
only certain roles to delete records.

Service Level Agreement (SLA):

Ø Definition: A formal agreement between a service provider and a
customer, defining the expected level of service.

Ø Purpose: Specifies the performance metrics (e.g., response time,

resolution time) that must be met for a particular service.

Ø Measurement: Tracked in ServiceNow using SLAs on incidents,

requests, or other tasks to monitor compliance.

Ø Components:

· ​ SLA Conditions: Trigger when an SLA starts, pauses, stops, or

breaches.

· ​ Targets: Define time-based goals (e.g., resolve within 4 hours).

Ø Notifications: Alerts sent if an SLA is at risk of breaching or has

breached.

Operational Level Agreement (OLA):

Ø Definition: An internal agreement between different departments or
teams within an organization.

Ø Purpose: Defines the responsibilities and performance expectations of

internal support teams to meet the SLAs.

Ø Scope: Focuses on the interdependencies between teams that

contribute to delivering the overall service to the customer.

Ø Examples: An OLA between the IT helpdesk and the network team to

resolve issues within a specific timeframe to support an SLA.

Underpinning Contract (UC) :

Ø Definition: A contract between the service provider and an external
supplier.

Ø Purpose: Ensures that the supplier's services align with and support the
SLAs agreed upon with the customer.

Ø Scope: Covers external services and products that underpin the delivery
of the overall service.

Ø Examples: A UC with a third-party vendor for hardware support that

guarantees hardware replacement within 24 hours.

Events:
Ø Purpose: Represent specific actions or changes in the system that can
trigger responses, such as notifications or other automated actions.
Ø Triggered By: Business rules, workflows, or other server-side scripts.

Ø Common Uses:

· ​ Trigger notifications, alerts, or integrations when certain

conditions are met.

· ​ Log significant system activities.

Ø Configuration:

· ​ Navigate to: System Policy > Events > Event Registry.

· ​ Create Events: Define new events by specifying a name and

description.

Ø Example: An event triggered when an incident is created or closed.

Notifications:
Ø Purpose: Send messages (email, SMS, or push) to users when certain
events occur in the system.

Ø Triggered By: Events, conditions, or manual actions.

Ø Common Uses:

· ​ Notify users about record updates, approvals, or system alerts.

· ​ Send escalations or reminders based on conditions.

Ø Types:

· ​ Email Notifications: Send email messages.

· ​ Push Notifications: Send notifications to mobile devices via the

ServiceNow app.

· ​ SMS Notifications: Send text messages.

Ø Configuration:
 · ​ Navigate to: System Notification > Email > Notifications.

· ​ Create Notification: Define triggers (event or condition),

recipients, and message content.

Ø Example: Notify a user when an incident is assigned to them or when an

approval is required.

Flows :
Ø Definition: Automated processes created using Flow Designer, a
codeless interface in ServiceNow that simplifies the automation of
business processes.

Ø Purpose: Streamlines tasks, approvals, notifications, and integrations

without the need for complex scripting.

Ø Components:

· ​ Triggers: Events that start the flow, such as record creation,

updates, or scheduled time-based triggers.

· ​ Actions: Predefined activities that the flow performs, like

creating records, sending notifications, or executing scripts.

· ​ Conditions: Logical checks that determine the flow's path

based on the criteria specified.
 · ​ Subflows: Reusable sets of actions that can be invoked within
multiple flows, promoting modularity.

Ø User-Friendly: Designed for non-technical users to automate processes

through a drag-and-drop interface.

Ø Integration: Can integrate with other ServiceNow applications, external

systems, or APIs to create comprehensive workflows.

Ø Use Cases:

· ​ Automating approval processes for service requests.

· ​ Sending notifications based on specific events or conditions.

· ​ Creating records or tasks in response to triggers like incident

creation.

Ø Real-Time Execution: Provides immediate action upon triggering

events, with the ability to monitor and track flow progress.

Ø Extensibility: Allows advanced users to create custom actions or

integrate with Script Includes for more complex logic.

Ø Versioning: Supports maintaining and deploying different versions of a

flow, facilitating updates and rollbacks.

v Refer this youtube playlist for better understanding of flows:

https://www.youtube.com/watch?v=qeSumpq0KVM&list=PLzTvAeLiW8Aflc
8kE986UslJnyN9nUhw9

Service Catalog:
Ø Service Catalog: A centralized repository in ServiceNow for users to
request and manage services, items, and information.

Ø Purpose: Provides a user-friendly interface for submitting and tracking

service requests and catalog items.

Ø Components:

· ​ Catalog Items: Individual requests such as hardware, software,

access, or other services.

· ​ Order Guides: Grouped requests that allow users to order

multiple related items in a single submission.

· ​ Record Producers: Forms that create records in various

tables, used for custom requests and processes.

Ø Categories: Items and services are organized into categories for easy
navigation and organization.

Ø Variables: Custom fields and questions used to capture user inputs and
specify request details.

Ø Approval: Supports approval workflows to ensure requests are reviewed

and authorized before fulfillment.

Ø Notifications: Automated notifications and alerts for request updates,

approvals, and fulfillment status.

Ø Management: Configured through the Service Catalog module in

ServiceNow, with options for customization and automation.

Ø Benefits: Enhances user experience by providing a streamlined,

self-service portal for requesting and tracking services.

Record Producer:
Ø Record Producer: A specific type of catalog item in ServiceNow used to
create records in any table.
Ø Purpose: Simplifies the process of creating records by providing a
user-friendly interface for users to submit requests or incidents.

Ø Customization: Can be tailored with custom fields, variables, and logic

to capture the necessary data.

Ø Use Cases:

· ​ Creating incidents from a self-service portal.

· ​ Submitting requests for new hardware, software, or access.

Ø Mapping: Fields in the Record Producer can be mapped to

corresponding fields in the target table.

Ø Scripting: Supports the use of scripts to perform additional actions

before or after record creation.

Ø Visibility: Can be made accessible through the service catalog or other

user-facing interfaces.

Ø Benefits: Streamlines record creation, reduces errors, and enhances the

user experience.

Order Guide:
Ø Order Guide: A ServiceNow catalog feature that groups multiple related
catalog items into a single request.

Ø Purpose: Simplifies complex ordering processes by allowing users to

request multiple items or services in a single flow.

Ø Use Cases:

· ​ Onboarding new employees by bundling items like a laptop,

software, and access requests.

· ​ Requesting all components for a new project (e.g., hardware,

software, and training).
Ø Guided Setup: Provides a step-by-step process for users to select and
configure multiple catalog items.

Ø Variables: Supports shared and item-specific variables to capture user

inputs efficiently.

Ø Rules: Conditional rules can be applied to dynamically show or hide

catalog items based on previous selections.

Ø Simplification: Reduces the need for multiple requests, ensuring all

necessary items are requested together.

Ø Management: Configured in the Service Catalog module within

ServiceNow.

Knowledge Bases:
Ø Knowledge Bases: Repositories in ServiceNow for storing and
managing articles, documents, and information to support users and
internal teams.

Ø Purpose: Provides a centralized location for sharing knowledge, best

practices, and solutions to common issues.

Ø Components:

· ​ Knowledge Articles: Individual entries that provide

information, solutions, or instructions.

· ​ Categories: Organizational structure for grouping related

knowledge articles for easier navigation.

· ​ Subcategories: Further division within categories to organize

articles more granularly.

Ø Access Control: Configurable permissions to control who can view,

create, edit, or delete knowledge articles.
Ø Approval Workflows: Articles can be reviewed and approved before
being published to ensure quality and accuracy.

Ø Search Functionality: Allows users to search for articles and find

relevant information quickly.

Ø Feedback: Users can provide feedback on articles, including ratings and

comments, to improve content quality.

Ø Management: Administered through the Knowledge Management

module in ServiceNow, with options for customization and reporting.

Ø Benefits: Enhances self-service support, reduces the need for repeated

inquiries, and improves operational efficiency by centralizing valuable
information.

Reports:
Ø Reports: Tools in ServiceNow for generating and visualizing data based
on records and fields from various tables.

Ø Purpose: Provides insights and analytics to monitor performance, track

trends, and make data-driven decisions.

Ø Types:

· ​ List Reports: Display data in a tabular format, similar to a list

view.

· ​ Chart Reports: Visualize data using charts and graphs (e.g.,

bar charts, pie charts, line charts).

· ​ Pivot Tables: Summarize data dynamically by grouping and

aggregating values.

· ​ Dashboards: Combine multiple reports and widgets into a

comprehensive visual display.
Ø Filters: Allows users to apply conditions to narrow down data and focus
on specific subsets.

Ø Scheduling: Reports can be scheduled to run at specific times and send

results via email.

Ø Sharing: Reports can be shared with users or groups, and permissions

can be configured to control access.

Ø Data Sources: Can pull data from various tables and fields within
ServiceNow or external sources.

Ø Customization: Reports can be customized with formulas, conditional

formatting, and additional calculations.

Ø Management: Created and managed through the Reports module in

ServiceNow, with options for saving and reusing report configurations.

Dashboards:
Ø Purpose: Provide a visual representation of data using widgets like
charts, reports, and performance analytics.

Ø Common Uses:

· ​ Monitor key performance indicators (KPIs) and metrics.

· ​ Display real-time data from various tables.

· ​ Offer an at-a-glance view for decision-makers.

Ø Widgets: Include reports, lists, charts, performance analytics, and more.

Ø Configuration:

· ​ Navigate to: Self-Service > Dashboards.

· ​ Create Dashboard: Add a new dashboard, give it a name, and

assign roles for access.

· ​ Add Widgets: Drag and drop widgets (reports, lists, etc.) to

display specific data.
Ø Types:

· ​ Personal Dashboards: Created by individual users for

personal use.

· ​ Shared Dashboards: Available to multiple users with the

appropriate roles.

Ø Example: A dashboard showing incident metrics, active tasks, and SLA

performance for IT managers.

​ ​ ​ ​ ​ ​