0% found this document useful (0 votes)
7 views26 pages

ServiceNow Introduction Notes

The document provides a comprehensive introduction to ServiceNow, a cloud-based platform designed to automate and optimize digital workflows across various departments. It covers key topics such as the platform's history, architecture, core concepts, IT service management modules, and scripting capabilities. Additionally, it outlines the roles of different user types and the importance of the Configuration Management Database (CMDB) in managing IT assets.

Uploaded by

BHARGAV SAI14
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views26 pages

ServiceNow Introduction Notes

The document provides a comprehensive introduction to ServiceNow, a cloud-based platform designed to automate and optimize digital workflows across various departments. It covers key topics such as the platform's history, architecture, core concepts, IT service management modules, and scripting capabilities. Additionally, it outlines the roles of different user types and the importance of the Configuration Management Database (CMDB) in managing IT assets.

Uploaded by

BHARGAV SAI14
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd

ServiceNow

Complete Introduction Notes


From Zero to Confident — Everything You Need to Revise

Topics Covered:

✦ What is ServiceNow?
✦ History & Evolution
✦ Architecture & Instance Model
✦ Core Platform Concepts
✦ ITSM Modules
✦ CMDB & Asset Management
✦ Scripting & Development
✦ Flow Designer & Automation
✦ Security & Access Control
✦ Integrations & APIs
✦ Reporting & Dashboards
✦ Career & Certification Paths
1. What is ServiceNow?
ServiceNow is a cloud-based Platform as a Service (PaaS) that enables organizations to automate,
manage, and optimize their digital workflows. Think of it as the operating system for enterprise
operations — connecting people, processes, systems, and data all on one unified platform.

🔑 One-Line Definition
ServiceNow = A single cloud platform that digitizes and automates workflows across every
department in an enterprise.

1.1 What Problem Does It Solve?


Before ServiceNow, organizations struggled with:
• Siloed departments using different tools (IT using one system, HR using another, Finance using
another)
• Manual, paper-based or email-based processes that were slow and error-prone
• No visibility into who is doing what, or the status of a request
• Inconsistent service delivery — every team handled requests differently
• Lack of data to measure performance or improvement

ServiceNow solves all this by bringing everything onto ONE platform with standard workflows,
automation, and reporting.

1.2 Who Uses ServiceNow?


User Type What They Do in ServiceNow
IT Staff Log/resolve incidents, manage changes, run discovery
End Users (Employees) Submit service requests, track tickets, read KB articles
HR Teams Manage onboarding, employee cases, policy requests
Finance Teams Handle procurement requests and approvals
Developers / Admins Build apps, configure workflows, write scripts
Managers / Executives View dashboards, KPIs, reports, approve changes
Service Desk Agents Answer calls, create and manage tickets in real-time
2. History & Evolution of ServiceNow
Understanding the history helps you appreciate WHY the platform is built the way it is.

Year Milestone
2004 Founded by Fred Luddy (ex-Peregrine Systems CTO) in San Diego, CA
2004–2007 Built as a help desk tool — focused purely on IT ticketing
2008–2010 Expanded into full ITSM (Incident, Problem, Change Management)
2011 Added Platform-as-a-Service (PaaS) capabilities — custom app
development
2012 IPO on NYSE — valued at $2.6B at launch
2013–2015 Expanded beyond IT into HR, Customer Service, Security Operations
2016 Launched Service Portal (modern UI) and Performance Analytics
2017 Acquired DxContinuum (AI/ML) — foundation for Now Intelligence
2018–2019 Introduced Flow Designer, IntegrationHub, Agent Workspace
2020 Launched Now Platform Paris release with heavy AI/ML integration
2021–2022 Expanded to Industry-specific solutions (Healthcare, FinServ, Telecom)
2023–2024 Generative AI (Now Assist) integrated across the platform
2025 AI Agents, Agentic workflows, deep LLM integrations

Key insight: ServiceNow started as an IT tool and evolved into a full enterprise platform. This explains
why IT workflows (ITSM) are the most mature, but every other department now has equal capability.
3. Platform Architecture — How ServiceNow is Built

3.1 The Single-Platform Model


ServiceNow's greatest strength is its single-data-model architecture. This means:
• One database — every module shares the same underlying data
• One codebase — no patching different systems together
• One user interface — consistent look and feel everywhere
• One workflow engine — the same automation engine powers IT, HR, Finance, etc.
• One reporting engine — you can report across any data on the platform

⚡ Why This Matters


Unlike competitors who bolt-on modules from different acquisitions, ServiceNow was designed as
one system from day one.
This means data flows naturally between departments — an IT incident can automatically trigger
an HR task or a procurement order without custom integration.

3.2 Instance Architecture


Every ServiceNow customer gets their own dedicated instance (environment). This is a key
differentiator from shared SaaS apps.

Term Explanation
Instance Your organization's dedicated ServiceNow environment (e.g.
[Link])
Production Instance The live environment that real users work in
Sub-Production Instances Dev, Test, UAT — used for development and testing before go-
live
Multi-Instance Architecture Each customer's data is isolated — no sharing between
customers
Cloning Copy Production data/config down to Dev/Test for realistic testing

3.3 Upgrade Model


• ServiceNow releases 2 major upgrades per year (named after cities — Tokyo, Utah, Vancouver,
Washington, Xanadu...)
• Upgrades are applied by ServiceNow to your instance — you don't install anything
• You can defer upgrades but cannot skip them indefinitely
• Sub-production instances are upgraded first so you can test before production is upgraded
3.4 ServiceNow Instance Types — Environments
Environment Purpose Who Uses It
Development (Dev) Build new features, scripts, Developers, Admins
workflows
Test / QA Test changes before release QA team, Developers
UAT User acceptance testing by Business users, Managers
business
Production Live environment — real users Everyone
4. Core Platform Concepts — The Building Blocks
These are the fundamental concepts that everything in ServiceNow is built on. Understand these
deeply.

4.1 Tables
Everything in ServiceNow is stored in a table. Tables are like database tables (or Excel sheets). Every
module you use — Incident, Change, CMDB — is just a table.

Table Name What It Stores


incident All incident records
change_request All change requests
problem Problem records
sc_request Service catalog requests
cmdb_ci All Configuration Items (CIs)
sys_user All users
sys_user_group All groups
task Parent table for all task-type records

💡 Key Concept: Table Inheritance


ServiceNow uses table inheritance — just like object-oriented programming.
For example: 'incident' extends 'task'. This means incidents inherit all fields from task.
So 'assigned_to', 'state', 'priority' — these exist on 'task' and are inherited by incident,
change_request, problem, etc.
This is why you can write one script that works on any 'task' type record.

4.2 Records & Fields


• Record = one row in a table (one incident, one user, one CI)
• Field = one column in a table (short_description, state, assigned_to)
• Every record has a unique sys_id — a 32-character GUID that never changes
• sys_id is the true identifier — numbers (INC0001234) can change, sys_id cannot

4.3 Forms & Lists


View Description
List View Shows multiple records in a table — like a spreadsheet view
View Description
Form View Shows one record in detail — all its fields
Related Lists At the bottom of a form — shows related records from other
tables (e.g., Tasks on a Change)
Activities (Work Notes) Communication log on a record — Work Notes (internal) vs
Comments (visible to user)

4.4 The Navigation Bar


• Top navigation: Global Search, Notifications, User Menu, Settings
• Left sidebar: Application Navigator — all modules and apps
• Type in the nav filter to quickly find any module
• Favorites: Star any module to pin it to the top
• History: Recently visited records are saved automatically

4.5 sys_id — The Master Key


🔐 Why sys_id is Critical
Every single record in ServiceNow has a sys_id — a 32-char unique ID.
How to find it: Right-click the record header bar → 'Copy sys_id'
It never changes, even if you update the record.
Used in URLs: [Link]?sys_id=abc123... opens that exact record.
Used in scripts: [Link]('abc123') fetches that exact record.
Used in integrations: Always reference records by sys_id, never by number.
5. ITSM — IT Service Management
ITSM is the core use case of ServiceNow. It is based on the ITIL framework (IT Infrastructure Library)
— a set of best practices for delivering IT services.

5.1 The 4 Core ITSM Modules


A) Incident Management
Goal: Restore normal service operation as quickly as possible after an unplanned disruption.

Concept Detail
What is an Incident? Any unplanned disruption to IT service — server down, app
crashing, user can't login
Priority Based on Impact × Urgency matrix (P1 Critical → P4 Low)
States New → In Progress → On Hold → Resolved → Closed
SLA Service Level Agreement — time target to resolve (e.g. P1 must
be resolved in 4 hours)
Assignment Group Team responsible for resolving the incident
Work Notes Internal notes between IT staff
Comments Updates visible to the person who raised the ticket
Escalation Moving ticket to higher priority group if unresolved

B) Problem Management
Goal: Find and eliminate the ROOT CAUSE of recurring incidents so they stop happening.

• Reactive Problem Management: Triggered after one or more incidents


• Proactive Problem Management: Identifies potential issues before incidents occur
• A Problem can have many related Incidents
• Known Error: When root cause is known but fix isn't ready yet — documented as Known Error
• Workaround: Temporary fix documented so agents can resolve incidents faster while problem is
open

C) Change Management
Goal: Control all changes to the IT environment to minimize risk of disruption.
Change Type Description Approval Needed?
Standard Change Pre-approved, routine, low-risk (e.g. No — pre-approved
password reset)
Normal Change Planned changes that need CAB review Yes — CAB approval
(e.g. server upgrade)
Emergency Change Urgent fix required ASAP (e.g. critical Yes — emergency CAB
security patch)

• CAB = Change Advisory Board — committee that reviews and approves normal changes
• Change Window = Scheduled maintenance window when changes can be made
• Rollback Plan = How to undo the change if it fails

D) Service Request Management


Goal: Handle requests from users for standard services (not incidents).

• Users submit requests via the Service Catalog (a menu of available services)
• Examples: 'New laptop request', 'Software access', 'VPN setup', 'New employee onboarding'
• RITM = Requested Item — the specific item in a request
• Catalog Task = Task assigned to a fulfillment team to action part of the request

🔍 Incident vs Request — Know the Difference


INCIDENT: Something broke / stopped working — 'My email is down'
REQUEST: I want something new / need access — 'Can I get Slack access?'
This distinction is critical in ITSM — they follow different workflows and SLAs.

5.2 SLA — Service Level Agreements


• Defines the maximum time to respond to and resolve a ticket
• SLA Breach = ticket not resolved within the defined time — triggers escalation
• SLA Pause = clock pauses when ticket is On Hold (waiting for user info)
• OLA = Operational Level Agreement — internal SLA between IT teams
• UC = Underpinning Contract — SLA with external vendor

5.3 Knowledge Management


• Knowledge Base (KB) = Library of articles that help users self-serve
• Reduces ticket volume — users find answers themselves before calling the help desk
• KB Article = step-by-step guide, FAQ, or troubleshooting document
• Knowledge can be linked to incidents so agents can share fixes instantly
• Feedback loop: Agents mark articles helpful/unhelpful → improves over time
6. CMDB — Configuration Management Database
The CMDB is the heart of ServiceNow's ITSM capability. It is a database of all IT assets and their
relationships.

6.1 What is the CMDB?


📦 CMDB in Simple Terms
The CMDB is like a map of your entire IT landscape.
It tracks every piece of infrastructure (servers, databases, applications, networks) and shows
HOW THEY ARE CONNECTED.
Without the CMDB, when an incident occurs, you don't know what other systems might be
affected.
With the CMDB, you can see: 'This server going down will impact these 5 apps and these 200
users.'

6.2 Key CMDB Terminology


Term Definition
CI (Configuration Item) Any component tracked in the CMDB — server, app, database,
network device
CI Class The type/category of a CI (e.g. cmdb_ci_server, cmdb_ci_appl)
CI Relationship A link between two CIs showing how they relate (Runs On,
Depends On, Hosted On)
CMDB Health Score measuring accuracy and completeness of CMDB data
Discovery Automated scanning of network to find and populate CIs
automatically
Service Mapping Maps the relationships between CIs that form a business service
Reconciliation Process of merging duplicate CI data from multiple discovery
sources

6.3 CI Class Hierarchy


CMDB uses inheritance — child classes inherit fields from parent classes.

CI Class Tree
cmdb (root)
└── cmdb_ci (all CIs have these fields: name, sys_class_name, sys_id)
├── cmdb_ci_hardware
│ ├── cmdb_ci_computer
│ │ ├── cmdb_ci_server
│ │ │ ├── cmdb_ci_win_server
│ │ │ └── cmdb_ci_linux_server
│ │ └── cmdb_ci_workstation
│ └── cmdb_ci_netgear
├── cmdb_ci_appl (applications)
└── cmdb_ci_database

6.4 Why CMDB Data Quality Matters


• Stale/wrong CMDB = wrong impact assessment during incidents
• CMDB should be kept fresh by automated Discovery (not manual entry)
• CI Health Dashboard shows which CIs have missing data or conflicts
• Source of Truth: CMDB is the single source of truth for all IT assets
7. Scripting & Development in ServiceNow
ServiceNow uses JavaScript as its scripting language. All server-side scripts run on the Rhino (Mozilla)
JavaScript engine. Client-side scripts run in the browser.

7.1 Types of Scripts — The Big Picture


Script Type Where It Runs Triggered By
Business Rule Server Database operations (insert, update, delete, query)
Client Script Browser Form events (onLoad, onChange, onSubmit)
UI Policy Browser Form field changes — show/hide/mandatory (no
code needed)
Script Include Server Called by other server-side scripts
Scheduled Job Server Time-based schedule
UI Action Server or Client Button/link clicks on a form or list
Flow Designer Server Trigger conditions (record event, schedule, API)
Event Script Server System events being fired

7.2 Business Rules — Deep Dive


Business Rules are the most important server-side scripts. They run automatically when records are
inserted, updated, deleted, or queried.

When Setting Behavior


Before Runs BEFORE the record is written to the DB. Can modify field
values before save.
After Runs AFTER the record is written to DB. Cannot modify current
record fields.
Async Runs in background AFTER the DB write. Non-blocking — user
gets response immediately.
Display Runs when form loads. Used to set g_scratchpad values to pass
to client scripts.

⚠️ Common Business Rule Mistakes


Running heavy logic in 'Before' rules — slows down the user's save action.
Running email notifications in 'Before' — email sends even if save fails!
Infinite loops: A Business Rule updates a record → triggers itself again infinitely.
Solution: Use '[Link]()' or add a condition to prevent infinite loops.
7.3 Key Server-Side Objects
Object What It Does
current The record being processed in the Business Rule
previous The record's values BEFORE the current update
gs (GlideSystem) Utility class: [Link](), [Link](), [Link](), [Link]()
GlideRecord Query, insert, update, delete database records
GlideAggregate Run aggregate queries: COUNT, SUM, AVG, MIN, MAX
GlideDateTime Work with date/time values
GlideElement Represents a single field on a record

7.4 GlideRecord — The Core Database API


GlideRecord is how ALL database interaction happens in ServiceNow scripts.

GlideRecord Patterns — MEMORIZE THESE


// QUERY records:
var gr = new GlideRecord('incident');
[Link]('state', 1); // state = Open
[Link]();
while ([Link]()) { [Link]([Link] + ' ' + gr.short_description); }

// GET single record by sys_id:


var gr = new GlideRecord('incident');
[Link]('sys_id_value_here');
[Link](gr.short_description);

// INSERT new record:


var gr = new GlideRecord('incident');
[Link]();
gr.short_description = 'New incident from script';
gr.caller_id.setDisplayValue('John Smith');
var sysId = [Link]();

// UPDATE existing record:


var gr = new GlideRecord('incident');
[Link]('sys_id_value');
[Link] = 6; // Resolved
[Link]();

7.5 Client-Side Scripts


Event When It Fires
onLoad() When the form first loads
onChange(control, oldValue, When a field value changes
newValue, isLoading)
onSubmit() When user clicks Save/Submit — can cancel the submit
onCellEdit(sysForm, table, When a cell in a list is edited
oldValue, newValue,
callback)

Key client-side object: g_form


• g_form.getValue('field_name') — get field value
• g_form.setValue('field_name', 'value') — set field value
• g_form.setVisible('field_name', false) — hide a field
• g_form.setMandatory('field_name', true) — make field required
• g_form.addErrorMessage('Something went wrong!') — show error banner

7.6 Script Include — Reusable Code Library


• A Script Include is a class or function defined once and called from anywhere on the server-side
• Prevents code duplication — write logic once, call from Business Rules, Scheduled Jobs, REST
APIs
• Two types: Class-based (most common) and Function-based
• Must set 'Client Callable' = true if you want to call it from a client script via GlideAjax
8. Flow Designer & Automation
Flow Designer is ServiceNow's modern low-code/no-code automation tool. It replaced the legacy
Workflow Editor and is now the primary way to automate processes.

8.1 Flow Designer vs Legacy Workflow


Feature Flow Designer (Modern)
Interface Step-by-step linear UI — easy to read and build
Code required? Mostly no-code — uses pre-built Actions and Spokes
Where built? Separate Flow Designer studio
Reusable components? Yes — Subflows and Actions can be reused across flows
Debugging? Excellent — Execution Details shows every step result
Recommended? YES — use this for all new automation

8.2 Key Flow Designer Components


Component What It Is
Flow The top-level automation — contains a trigger and sequence of
steps
Trigger What starts the flow (record created, record updated, schedule,
API call, inbound email)
Action A single step in the flow (Create Record, Update Record, Send
Email, Call REST)
Spoke A collection of Actions for a specific app (Slack Spoke, Jira
Spoke, ServiceNow Core Spoke)
Subflow A reusable flow that can be called from within another flow (like a
function)
Decision Branching logic — if/else conditions inside a flow
Pill A data reference — dynamic value from a previous step used in
the current step

8.3 Common Flow Triggers


• Record Created — fires when a new record is inserted in a table
• Record Updated — fires when a specific field changes on a record
• Record Deleted — fires when a record is deleted
• Scheduled — runs at a defined time/frequency (daily, hourly, etc.)
• Inbound Email Action — fires when an email is received
• Service Catalog — fires when a catalog item is submitted
• REST API — fires when called via HTTP from external system
9. Security & Access Control
ServiceNow has a layered security model. Understanding it is critical for both exams and real-world
implementation.

9.1 The Security Layers


Security Layer Order (Top to Bottom)
1. Roles — what the user is allowed to do at a high level
2. Groups — collection of users with a shared role/purpose
3. ACLs (Access Control Lists) — granular table/field/record-level permissions
4. Data Policies — enforce field rules even via API (stricter than UI Policy)
5. Business Rules — can enforce security logic programmatically

9.2 Roles
A role is a named permission set. Users are granted roles, and roles grant access to modules, apps,
and data.

Role Access Level


admin Full platform access — can do anything
itil Core ITSM access — incidents, problems, changes, knowledge
itil_admin ITSM + admin capabilities (manage assignments, groups)
catalog_admin Manage the service catalog and catalog items
approver_user Approve requests (no need for full ITSM access)
rest_api_explorer Access the REST API Explorer UI
report_admin Create and manage reports and dashboards
asset Asset Management module access

9.3 ACLs — Access Control Lists


ACLs control precisely WHO can READ, WRITE, CREATE, or DELETE data at the table, field, or
record level.

• Table ACL: Controls access to an entire table (e.g. can this role read the 'incident' table?)
• Field ACL: Controls access to a specific field (e.g. can this role see the 'salary' field?)
• Record ACL: Controls access to specific records based on conditions
• Operation types: read, write, create, delete, execute
🔐 ACL Evaluation Order
1. If user has 'security_admin' role — bypass all ACLs.
2. Check if a matching ACL exists for the operation.
3. If no ACL exists — access is GRANTED (open by default).
4. If ACL exists — evaluate role, condition, and script. ALL must pass.
5. If any check fails — access DENIED.

9.4 Impersonation
• Admin users can impersonate any other user
• Used to test what another user sees / can access
• Access: Click avatar (top right) → Impersonate User → search name
• Impersonation is logged — audit trail shows who was impersonated and when
10. Integrations & APIs

10.1 ServiceNow REST API


ServiceNow has a powerful built-in REST API that allows external systems to interact with any data on
the platform.

API Endpoint Purpose


Table API (/api/now/table/) CRUD operations on any table — most commonly used
Aggregate API Run aggregate queries (COUNT, SUM) via REST
Attachment API Upload/download attachments on records
Import Set API Push data into staging tables for import processing
Scripted REST API Custom REST endpoints built with JavaScript
NOW Assist API AI capabilities via REST

10.2 Integration Methods


Method Use Case
REST API (outbound) ServiceNow calls external APIs (e.g. create Jira ticket from
ServiceNow)
REST API (inbound) External system calls ServiceNow (e.g. monitoring tool creates
incident)
IntegrationHub Low-code integration using pre-built Spokes for Slack, Jira,
Azure, AWS, etc.
MID Server Bridge to on-premises systems behind firewall
Import Sets Bulk data import from files (CSV, Excel) or external DB via JDBC
Transform Maps Map imported data fields to target table fields
Email Integration Inbound email creates/updates records; outbound email
notifications
SOAP (Legacy) XML-based web services — still supported for legacy integrations

10.3 MID Server Recap


• MID = Management Instrumentation Discovery
• Java agent installed inside your on-premises network
• Makes outbound-only connections to ServiceNow (no inbound ports needed)
• Enables Discovery, Orchestration, IntegrationHub for internal systems
• Can be clustered for High Availability
11. Reporting & Dashboards

11.1 Reports
Report Type Best Used For
List Show a table of records with columns — like a filtered list view
Bar Chart Compare values across categories (incidents by priority)
Pie / Donut Chart Show proportional breakdown (% of incidents by state)
Line Chart Show trends over time (monthly ticket volume)
Heat Map Show density — useful for identifying patterns
Pivot Table Cross-tabulate two dimensions (group × priority count)
Single Score Show one KPI number prominently on dashboard
Gauge Show progress toward a target (% SLA compliance)

11.2 Dashboards
• A dashboard is a collection of reports and widgets on one screen
• Multiple tabs — organize different views for different audiences
• Shared dashboards — visible to specific roles or groups
• Interactive — users can filter and drill down into data
• Homepages — each user can customize their personal homepage

11.3 Performance Analytics (PA)


Performance Analytics goes beyond basic reports — it tracks KPIs over time and enables trend
analysis and goal setting.

• Indicator: A measurable KPI (e.g. 'Number of open P1 incidents')


• Breakdown: Segment data by category (by team, by region, by priority)
• Score: The value of an indicator at a point in time
• Widget: A PA visualization element that can be added to a dashboard
• PA collects historical data — unlike regular reports which only show current state
12. Service Portal
The Service Portal is the modern, consumer-friendly interface that end users interact with. It's separate
from the admin/agent backend interface.

12.1 What is the Service Portal?


• URL: [Link]/$[Link]
• Designed for end users (not IT staff) — simple, clean, mobile-friendly
• Built with AngularJS widgets — highly customizable
• Users can submit requests, track tickets, search knowledge, chat with agents

12.2 Service Portal Components


Component Description
Portal The top-level container — one instance can have multiple portals
Page A URL-accessible screen in the portal (home, catalog, request
details)
Widget A self-contained UI component (search bar, ticket status, KB
article)
Theme CSS styling applied to the portal (colors, fonts, branding)
Menu Navigation links at the top of the portal
Knowledge Base Searchable articles — prominently featured on portal home
Service Catalog Browse and submit requests from the portal
13. Certifications & Career Path

13.1 Certification Tracks


Certification Focus Area Who Should Take It
CSA — Certified System Platform basics, UI, tables, Anyone new to ServiceNow
Administrator users, groups, security,
reporting
CAD — Certified GlideRecord, Business Rules, Developers
Application Developer Client Scripts, REST API, App
Engine
CIS-ITSM Incident, Problem, Change, ITSM implementers
Service Catalog implementation
CIS-Discovery Discovery architecture, MID Discovery/CMDB specialists
Server, CMDB, patterns
CIS-HRSD HR Service Delivery — HR implementation consultants
onboarding, employee cases,
COEs
CIS-CSM Customer Service Management Customer service teams
CIS-SecOps Security Incident Response, Security teams
Vulnerability Response
CMA — Certified Master Expert-level, multi-domain Senior architects
Architect platform architecture

13.2 Recommended Study Path


• Step 1: Complete ServiceNow Learning Path on [Link] (free)
• Step 2: Get a Personal Developer Instance (PDI) — free sandbox at [Link]
• Step 3: Take CSA first — it covers all platform fundamentals that other certs build on
• Step 4: Specialise — CAD for developers, CIS-ITSM for functional consultants
• Step 5: Practice in PDI daily — hands-on experience is critical, not just theory

🚀 How to Get a Free Practice Instance (PDI)


1. Go to: [Link]
2. Create a free account
3. Click 'Request Instance' — get a free dedicated sandbox instance
4. Use it to practice everything in these notes — scripting, workflows, reports, catalog
5. Instance sleeps after inactivity — wake it up anytime from the developer portal
14. Quick Reference — Must-Know Facts

14.1 Important Numbers & Facts


Fact Detail
Founded 2004 by Fred Luddy
Releases per year 2 major releases (named after cities)
Context window (API) Up to 200K tokens
sys_id format 32-character alphanumeric GUID
Default port 443 (HTTPS) for MID Server communication
Script language JavaScript (Rhino engine server-side, browser engine client-side)
Base table for tasks 'task' table — parent of incident, change, problem, sc_task
CMDB root table 'cmdb_ci' — all CI types extend this

14.2 Shortcut Navigation Tips


• Type '[Link]' in nav filter → goes directly to incident list
• Type '[Link]' in nav filter → opens a new blank incident form
• Right-click field label → 'Show Field Name' to see the actual field name for scripting
• Right-click record header → 'Copy sys_id' to get the record's unique ID
• Ctrl+click a menu item → opens in a new tab
• System Definition → Scripts - Background → run ad-hoc server scripts (admin only)

14.3 Common GlideSystem (gs) Methods


Method What It Returns / Does
[Link]() Returns sys_id of the logged-in user
[Link]() Returns username (e.g. '[Link]')
[Link]().getFullName() Returns 'John Smith'
[Link]() Current date/time in platform format
[Link]() Current datetime as string
[Link](msg) Writes to system log (debug level)
[Link](msg) Info-level log
[Link](msg) Error-level log
[Link]('itil') Returns true if current user has 'itil' role
Method What It Returns / Does
[Link]('[Link]') Get a system property value

14.4 Exam Tips — CSA & CAD


• CSA: Focus on UI, tables, groups/roles, ACLs, reporting, import sets, ITSM modules
• CAD: Focus on Business Rules (timing), GlideRecord, Client Scripts, Script Includes, REST API
• Know the difference: Business Rule vs Client Script vs UI Policy vs Data Policy
• Know the difference: Incident vs Problem vs Change vs Request
• Know ACL evaluation order — trick questions appear about this
• Understand 'before/after/async' Business Rule timing deeply
• [Link]() vs [Link]() — know when to use each

✅ Final Revision Checklist


□ Can I explain what ServiceNow is in 2 sentences?
□ Do I know the 4 core ITSM modules and their purpose?
□ Can I explain the difference between Incident, Problem, Change, and Request?
□ Do I know what a table, record, field, and sys_id are?
□ Can I write a basic GlideRecord query from memory?
□ Do I know the 4 Business Rule timings and when to use each?
□ Do I understand how ACLs work and their evaluation order?
□ Do I know what the CMDB is and why it matters?
□ Do I know what a MID Server is and why it exists?
□ Can I explain the difference between Flow Designer and a Workflow?

End of ServiceNow Introduction Notes • Good luck with your studies! 🎯

You might also like