Blog: Mastering ServiceNow – Beginner to Advanced Guide (Simple Explanation)
Before We Begin — A Note to You
If you've ever opened ServiceNow and thought “Where do I even start?”, you're not alone.
Many people use ServiceNow daily but don’t fully understand what happens behind the scenes.
This guide simplifies everything — from basic concepts to advanced topics — using a real-world example (a hotel system).
Topics which we are going to cover in this article :
- What is ServiceNow & Architecture
- Tables, Fields & Data
- Server-Side Scripting
- Client-Side Scripting
- Tasks, Workflows & Approvals
- Events, Notifications & Reports
- Security
What Is ServiceNow & How Does It Work?
ServiceNow is a cloud platform for managing work. It's not software you install — it's a website your company uses. You visit yourcompany.service-now.com, log in, and everything is there. The platform comes with dozens of built-in applications (ITSM,HRSD(plugins required), GRC(Pluggins reuired),Agile Development(pluggin), Platform Analytics(pluggin), ATF( pluggin required) etc.), but what makes it truly powerful is that you can build custom applications on top of it.
Think of ServiceNow like a smartphone operating system. Android is the platform. Instagram, Spotify, and Gmail are the apps. You can use the pre-installed apps or build your own. ServiceNow works the same way — the platform is the OS, and ITSM, HR, Agile,GRC are the apps.
Single-Tenancy — Your Own Space
ServiceNow uses a single-tenant architecture. Each customer gets their own private instance — their own database, their own URL, their own everything. You're not sharing a database with any other company.
This is different from apps like Gmail where millions of people share the same infrastructure. In ServiceNow, your data is isolated. This gives you the freedom to customize aggressively — you can change almost anything without affecting anyone else
Overall view of servicenow architechture( just for understanding created this diagram)
Detail servicenow architechture
ServiceNow ships with hundreds of features that are turned off by default. They're bundled into plugins. When you activate a plugin, all its tables, scripts, menus, and example data get loaded into your instance.
Tables, Fields & Data — The Building Blocks
Everything in ServiceNow starts with data. Before you write any code or build any workflow, you need to understand how data is organized. This is the foundation that everything else rests on.
Tables — Your Data Containers
A table is exactly what it sounds like: a database table with rows and columns. Each row is a record (one incident, one user, one hotel reservation). Each column is a field (name, email, status).
For Gardiner Hotels, we need tables for: Guests, Rooms, Check-ins, and Reservations. Each holds a different type of information.
ServiceNow Table Types (Quick Guide)
1. Core Tables
- These are main built-in tables provided by ServiceNow
- Used by core applications like ITSM
Examples:
- incident
- problem
- change_request
- Think: Ready-made tables for real business use
2. Base Tables
- These are parent tables (foundation tables)
- Other tables extend from them but they dont extends other .
Examples:
- task
- cmdb_ci
Think: Blueprint tables (used for inheritance)
3. Custom Tables
- Tables created by developers/users
- Always start with u_ prefix
Examples:
- u_employee
- u_project
- u_booking
Think: Your own tables for custom apps
4. Extended Tables
- Tables that inherit from another table
- Get all fields + logic from parent
Examples:
- incident => extends task
- u_guest => extends sys_user
Think: Child tables with extra features
System Fields — The Free Ones
Every table automatically gets these fields. You never have to create them:
Field | What It Does |
sys_id | A unique 32-character ID for every record. The primary key of ServiceNow. |
sys_created_on | Date/time the record was created (stored as UTC) |
sys_updated_on | Date/time the record was last changed (stored as UTC) |
sys_created_by | Username of who created the record |
sys_updated_by | Username of who last changed it |
sys_mod_count | How many times the record has been saved |
Important: The sys_id is sacred. It's how every reference in ServiceNow works. Never change a sys_id manually. Never hardcode a sys_id in a script — use field values to find records instead. |
Field Types — Choosing the Right Container
Different data needs different field types. Choosing the right one matters for validation, searching, and display:
Field Type | Best Used For |
String | Short text — names, descriptions, codes (up to 40 chars by default, configurable) |
Integer | Whole numbers — counts, floor numbers, quantities |
True/False | Binary choices — checkboxes |
Date/Time | Timestamps — created dates, due dates |
Choice | Dropdowns with a fixed set of options — status, category, priority |
Reference | Links to another table's records — assigned user, linked incident |
HTML | Rich formatted text with colors and fonts |
Currency | Amount + currency code combined — prices, budgets |
URL | Clickable web links |
Reference Fields — The Glue Between Tables
Reference fields are one of the most important concepts in ServiceNow. They link records from one table to another. A Check-in record has a Guest field that points to the Guest table, and a Room field that points to the Room table.
Under the hood, a reference field just stores a sys_id. But ServiceNow displays the person's name or room number instead of the that ID. This is called the 'display value'.
Dot-Walking — Following the Chain
Because reference fields link tables together, you can 'walk' through them to access related data. This works in scripts, filters, and email templates:
On a Check-in record, access the Guest's email:
current.u_guest.email // On a Maintenance task, access the Assignment Group's manager: current.assignment_group.manager.email //
In a filter on a list:
// 'Assignment Group Manager Name is Bob' becomes:
// assignment_group.manager.name = 'Bob'
Tip: Dot-walking is incredibly convenient, but use it carefully in scripts. Each dot-walk adds a database join, which can slow things down. For a handful of records it's fine. For millions of records, think twice.
Relationships in servicenow table :
ServiceNow relationships define how tables are connected to each other.
The most common type is a reference relationship, where one table points to another using a sys_id.
A one-to-many relationship means one record can be linked to multiple records (like one user to many incidents).
A many-to-many relationship connects multiple records on both sides using a junction (M2M) table.
Most relationships in ServiceNow are created using reference fields.
Server-Side Scripting — Making the Platform Think
Server-side scripting is where ServiceNow really comes alive. This is where you add intelligence — auto-populate fields, validate data, trigger actions, update related records, call external APIs. All of this happens on the server, invisible to the user.
Where Does Server-Side Code Run?
All server-side JavaScript runs on the ServiceNow application server using an engine called Rhino. It's not code running in the user's browser — it runs on the server, processes data, and then sends results back.
Tip: The Background Scripts tool (System Definition > Scripts - Background) is your sandbox for testing server-side code. Write and run JavaScript directly and see the output immediately. Use it constantly while learning.
GlideRecord — Reading and Writing Data
GlideRecord is the most important class in ServiceNow scripting. It's your interface to the database. Once you understand it, you can do almost anything.
Querying Records
var gr = new GlideRecord('u_maintenance');
gr.addQuery('state', 2); // State = Work in Progress
gr.addQuery('priority', '<=', 2); // Priority is High or Critical
gr.orderByDesc('sys_created_on'); // Newest first
gr.setLimit(20); // Max 20 records
gr.query(); // Execute the query
while (gr.next()) {
gs.log(gr.number + ': ' + gr.short_description); }
Creating a Record
var gr = new GlideRecord('u_maintenance');
gr.initialize(); // Prepares the record with default values
gr.short_description = 'Leaking tap in Room 101';
gr.u_room = roomSysId; // Set a reference field by sys_id gr.assignment_group.setDisplayValue('Maintenance Team');
gr.insert(); // Saves to the database
var newSysId = gr.sys_id + ''; // Get the new record's sys_id
Updating a Record
var gr = new GlideRecord('u_maintenance');
if (gr.get('sys_id_here')) { // Returns true if found
gr.state = 3; // Closed Complete
gr.work_notes = 'Issue resolved by maintenance team';
gr.update(); }
Deleting Records
// Delete one record var gr = new GlideRecord('u_maintenance');
if (gr.get(sysId)) {
gr.deleteRecord(); } // Delete multiple records (use with extreme caution!)
var gr = new GlideRecord('u_old_data');
gr.addQuery('sys_created_on', '<', '2020-01-01');
gr.deleteMultiple();
Important: Always use setLimit() when querying. Without it, a query on a large table could return millions of records and crash your instance. Also, always test scripts in Dev before running them in Production.
GlideSystem (gs)
The gs object is globally available in all server-side scripts. You don't create it — it's always there. It gives you access to information about the current session, user, and system:
Function | What It Returns / Does |
gs.getUserID() | sys_id of the currently logged-in user |
gs.getUserName() | Username like 'john.smith' |
gs.getUser() | Full GlideUser object with hasRole(), getFullName(), etc. |
gs.hasRole('itil') | true/false — does the current user have this role? |
gs.addInfoMessage('msg') | Shows a blue notification message on screen |
gs.addErrorMessage('msg') | Shows a red error message on screen |
gs.getProperty('name') | Reads a system property value |
gs.log('message', 'source') | Writes to the System Log |
gs.now() | Today's date as 'YYYY-MM-DD' |
gs.beginningOfToday() | Midnight today as a datetime string |
gs.eventQueue('evt', gr, p1, p2) | Fires a named event |
Business Rules — Automatic Logic on Database Events
A Business Rule is a script that automatically runs when a database action occurs on a specific table. It's the most fundamental way to add logic to ServiceNow.
When Does a Business Rule Run?
Timing | When It Executes |
Before | BEFORE the record is saved. Perfect for validation (block bad saves), and setting default values. |
After | AFTER the record is saved. Perfect for updating related records based on what just happened. |
Async | AFTER the save, but in the background. Perfect for slow operations (API calls, complex logic) that shouldn't block the user. |
Display | When a record is loaded for display (before the form appears). Perfect for passing server data to client scripts. |
Query | When the table is queried. Used to filter what records users can see at the database level. |
Variables Available in Business Rules
- current — GlideRecord of the record being processed
- previous — GlideRecord of the record before this save (what it looked like before changes)
- gs — The GlideSystem helper
- g_scratchpad — Object for passing data to Display Business Rules (client-readable)
Example: Validate Dates Before Saving
/ Business Rule: Stop invalid reservations // Table: Reservation, When: Before, Insert + Update
if (current.u_departure <= current.u_arrival) {
gs.addErrorMessage('Departure must be after arrival date.'); current.setAbortAction(true); // Blocks the save completely }
Script Includes — Your Code Library
Script Includes are reusable JavaScript functions or classes. Instead of duplicating code across multiple Business Rules, you put the logic in a Script Include and call it from anywhere.
Unlike Business Rules, Script Includes only load when called. This makes them efficient and testable.
Script Include Types in ServiceNow
1. Creating New Class (Class-based)
- You create your own reusable class
- Use Class.create()
- Called using new
Example:
var MyClass = Class.create();
MyClass.prototype = {
greet: function(name) {
return "Hello " + name;
},
type: 'MyClass'
};
2. Extending Existing Class
- You inherit from another class
- Use Object.extendsObject()
- Commonly used with AbstractAjaxProcessor
Example:
var MyAjax = Class.create();
MyAjax.prototype = Object.extendsObject(AbstractAjaxProcessor, {
getData: function() {
return "Data from server";
},
type: 'MyAjax'
});
3. On-Demand / Classless
- Simple function without class
- Called directly (no new)
Example:
function add(a, b) {
return a + b;
}
Client-Side Scripting — Making the Interface Smart
Client-side scripting runs in the user's browser. It powers instant feedback — hiding fields based on what's selected, validating input before submission, showing warnings as the user types. Done well, it makes forms feel smart and responsive.
Important: NEVER trust client-side validation for security. A user with browser developer tools can bypass any client-side check in 30 seconds. Always back everything up with server-side Business Rules and Data Policy.
Client-side code is for user experience. Server-side code is for security and data integrity. Use both together.
UI Actions — Buttons on Forms and Lists
A UI Action is a button (or link or context menu item) that appears on a form or list. When clicked, it runs code — either in the browser, on the server, or both.
Types of UI Actions
Where UI Actions Can Appear |
Form button — Prominent button at top/bottom of form. Most visible. |
Form link — Text link in 'Related Links' section at bottom of form |
Form context menu — Right-click on the form title bar |
List banner button — At the top of a list view |
List choice — In the 'Actions on selected rows' dropdown at list bottom |
List context menu — Right-click on a list row |
Example: Server-Side Button to Create a Check-In
// UI Action: 'Check In Guest' button on Reservation form
// Create the check-in record
var checkIn = new GlideRecord('u_check_in');
checkIn.initialize();
checkIn.u_date = current.u_arrival;
checkIn.u_guest = current.u_lead_guest;
checkIn.u_room = current.u_room;
checkIn.insert(); // Send the user to the new check-in record action.setRedirectURL(checkIn);
Client Scripts — Live Responses to User Actions
Client Scripts run in the browser and respond to form events. They're attached to specific tables and trigger on specific actions.
Script Type | When It Fires |
onChange | When a specific field's value changes (the most common type) |
onLoad | When the form first opens (use sparingly — can hurt performance) |
onSubmit | When the user clicks a submit/save button (return false to block) |
onCellEdit | When a cell is edited directly in a list view |
Example: Warn About VIP Guests on Check-In
// onChange Client Script — Table: Check-In, Field: Guest
function onChange(control, oldValue, newValue, isLoading) {
// Don't run while the form is loading
if (isLoading || newValue == '')
{ g_form.hideFieldMsg('u_guest');
return;
}
// Fetch the guest record to check VIP status
g_form.getReference('u_guest', function(guestRecord) {
if (guestRecord.vip == 'true') {
g_form.showFieldMsg( 'u_guest', 'VIP Guest! Prepare premium welcome package.', 'info');
}
else {
g_form.hideFieldMsg('u_guest');
}
});
}
GlideForm (g_form) — Controlling the Form
g_form is your toolkit for manipulating the form in the browser. It reads and changes fields, shows messages, and controls visibility.
Method | What It Does |
g_form.getValue('field') | Get the current displayed value of a field |
g_form.setValue('field', 'value') | Set a field's value (triggers onChange events) |
g_form.setMandatory('field', true/false) | Make a field required or optional |
g_form.setReadOnly('field', true/false) | Make a field editable or locked |
g_form.setDisplay('field', true/false) | Show or completely hide a field |
g_form.showFieldMsg('field', 'msg', 'type') | Show info/error/warning below a field |
g_form.hideFieldMsg('field') | Remove the message below a field |
g_form.flash('field', '#FFFF00', 0) | Briefly highlight a field to draw attention |
g_form.getReference('field', callback) | Async fetch of the referenced record |
g_form.getUniqueValue() | Get the sys_id of the current record |
UI Policy — Visual Rules Without Code
UI Policy lets you set rules like 'when Priority = Critical, make Assignment Group mandatory' — without writing JavaScript. Use it instead of Client Scripts whenever possible, as it's optimized by the platform.
UI Policy can: make fields mandatory, make fields read-only, show or hide fields. All based on conditions you define with point-and-click.
Tip: Always keep 'Reverse if false' and 'On Load' checked in your UI Policies. 'On Load' ensures the policy evaluates when the form opens (not just when fields change). 'Reverse if false' means when the condition is not met, the opposite happens automatically.
GlideAjax — Efficient Server Communication
Sometimes you need live data from the server while the user is filling out the form. GlideAjax is how you do this without a full page reload. It's more efficient than client-side GlideRecord because you get exactly the data you ask for.
Step 1: Create the Server-Side Script Include
Mark this Script Include as 'Client Callable'!
var RoomChecker = Class.create(); RoomChecker.prototype = Object.extendsObject(AbstractAjaxProcessor, {
checkAvailability: function()
{
var roomId = this.getParameter('sysparm_room_id');
var date = this.getParameter('sysparm_date');
var gr = new GlideRecord('u_check_in');
gr.addQuery('u_room', roomId);
gr.addQuery('u_date', date);
gr.setLimit(1);
gr.query();
return gr.hasNext() ? 'occupied' : 'available'; },
type: 'RoomChecker' });
Step 2: Call It from the Client Script
// In a Client Script when the Room or Date field changes:
var ga = new GlideAjax('RoomChecker');
ga.addParam('sysparm_name', 'checkAvailability');
ga.addParam('sysparm_room_id', g_form.getValue('u_room'));
ga.addParam('sysparm_date', g_form.getValue('u_date'));
ga.getXMLAnswer(function(answer) {
if (answer == 'occupied')
{ g_form.showFieldMsg('u_room', 'Room is already occupied on this date!', 'error');
} else
{ g_form.hideFieldMsg('u_room');
} });
Tasks, Workflows & Approvals
ServiceNow is fundamentally a task management system. Understanding how Tasks work — and how to automate the processes around them — is essential for building any real business application on the platform.
The Task Table — Everything's Foundation
The Task table (table name: task) is extended by almost every work-management table in ServiceNow. Incidents, Problems, Change Requests, and our custom Maintenance tasks all inherit from it.
This inheritance means all these different types of work share a common structure. The 'My Work' view shows all your assigned tasks regardless of type. You can report across them with a single query.
Essential Task Fields
Core Fields You'll Use Constantly |
number — Human-readable ID (INC0001234, CHG0000456). Auto-generated, never edit this. |
short_description — One-line summary. Appears in lists and email subjects. |
description — Full details of the work. |
state — Where in the lifecycle (see table below). Drives most automation. |
priority — Urgency level: 1=Critical, 2=High, 3=Medium, 4=Low. |
assigned_to — The individual responsible for the work. |
assignment_group — The team responsible for the work. |
work_notes — Private journal visible only to fulfillers (not requesters). |
comments — Public journal visible to everyone, including requesters. |
watch_list — People who get email updates when the task changes. |
The State Field — The Lifecycle Tracker
State Value | Label & Meaning |
-5 | Pending — Created but shouldn't be worked yet (pre-start planning) |
1 | Open — Ready to be picked up, no one assigned yet |
2 | Work in Progress — Actively being worked on |
3 | Closed Complete — Successfully finished |
4 | Closed Incomplete — Work stopped, issue not fully resolved |
7 | Closed Skipped — No longer relevant, canceled or superseded |
Tip: State is stored as an integer. This lets you use >= and <= in filters. For example, 'State >= 3' catches all closed states in one condition, no matter which specific closed state. |
Graphical Workflow — Automating Multi-Step Processes
Graphical Workflow is ServiceNow's drag-and-drop process engine. You build a flowchart of activities, connect them with arrows, and ServiceNow follows the path automatically when the right conditions are met.
For Gardiner Hotels, when a maintenance request needs the external repair team, the workflow:
- Starts when someone clicks 'Send to External Team'
- Sends an email to the manager asking for approval
- Waits for the approval decision
- If approved: assigns to Cornell Hotel Services and notifies them
- If rejected: notifies the original requester and closes the approval loop
Key Workflow Activities
Activities You'll Use Most Often |
Run Script — Execute any server-side JavaScript at this point in the flow |
Create Task — Make a new related task (child task) |
Approval - User — Ask a specific person to approve; waits for their decision |
Group Approval — Ask all members of a group; configure who wins (first, majority, all) |
Notification / Create Event — Send an email at this point in the process |
Timer — Pause the workflow for a fixed time (useful for follow-ups) |
Wait for Condition — Pause until a field on the record reaches a certain value |
If / Switch — Branch to different paths based on conditions |
Set Field Values — Update fields on the record without a script |
Sub-workflow — Call another workflow as a reusable module |
Approvals — Getting Formal Sign-Off
Approvals are a first-class citizen in ServiceNow. When a workflow generates an approval, the approver receives an email with Approve and Reject links. They can decide right from their email — no login required.
How Email-Based Approval Works
- The approval email contains mailto: links (not regular links)
- Clicking 'Approve' opens the approver's email client with a pre-filled subject line
- The approver sends the email — nothing else required
- ServiceNow reads the incoming email and updates the Approval record
- The Workflow picks up the decision and continues
This is powerful because approvers don't need a ServiceNow account. They just need to be able to receive and send email.
Group Approval Options
Option | How It Decides |
First response decides | Whoever responds first makes the decision for the whole group |
Anyone approves | As soon as one person approves, the approval passes |
Everyone must approve | Every single person must say yes |
Majority rules | More than 50% must approve before it passes |
Reject immediately | If anyone rejects, the whole approval fails immediately |
The Service Catalog — User-Friendly Requesting
The Service Catalog is the self-service shopping interface. Instead of calling IT or sending an email, users browse a catalog, fill out a form, and submit. Behind the scenes, the right task type gets created and the right workflow kicks off.
The Four Types of Catalog Items
Type | What It Does |
Standard Item | Requests something (like a new laptop). Creates a Request + Requested Item +Sc_task |
Record Producer | Creates a record in any table using a friendly form. Our hotel uses this for maintenance requests. |
Order Guide | Bundles multiple items together. Answer some questions, get a package deal. |
Content Item | An information page — no ordering, just reading. Documentation, policies, etc. |
Tip: Record Producers are underrated. They give you all the friendliness of the Service Catalog (images, descriptions, variables, categories) while creating records in your own custom tables. Perfect for non-technical users requesting things. |
Service Level Agreements — Measuring How Fast You Are
SLAs set targets for how quickly tasks should be completed and track whether you're meeting them. They automatically track elapsed time, pause when appropriate, and trigger actions when deadlines approach.
How SLA Time Is Calculated
- Start condition — Clock starts (e.g., when State becomes Open)
- Pause condition — Clock stops temporarily (e.g., when awaiting customer response)
- Stop condition — Clock stops permanently (e.g., when State becomes Resolved)
The actual elapsed time = total calendar time minus any paused time. You can also set SLAs to work only during business hours using a schedule.
When an SLA is nearing its deadline, a Workflow can fire automatically to send reminders, escalate to a manager, or even reassign the task.
Events, Notifications & Reports
Building great processes in ServiceNow is step one. Making sure the right people know what's happening — in real time, via the channels they prefer — is step two. This covers how to keep your entire organization informed.
Events — The Publish-Subscribe System
When something notable happens, you fire an event. Other parts of the system listen for events and react.
Why bother with events instead of just doing everything in a Business Rule? Because it separates concerns. The Business Rule that fires 'maintenance.assigned' doesn't care what happens next. The Email Notification and the Slack integration both listen for that event independently. You can add new listeners without touching the Business Rule.
Firing an Event
//In a Business Rule (After, Insert + Update)
// Table: Maintenance
// Condition: Assignment group changes AND is not empty
gs.eventQueue( 'maintenance.assigned', // Event name (must be registered first) , current// Therecord this event relates to , gs.getUserID(), // parm1 — who triggered it gs.getUserName() // parm2 — their display name );
Before you can fire an event, you must register it: System Policy > Events > Registry > New. This just creates a record saying 'this event name exists'.
Email Notifications — Staying in the Loop
Email Notifications define who gets emails, when, and what those emails say. They're triggered either by events or by directly monitoring a table for changes.
The Three Parts of an Email Notification
When to Send: Either when a specific event fires, or when a record is inserted/updated and your conditions match
Who Receives: Users in specific fields (like Assignment Group), groups, scripted recipients, or the person who triggered the action
What It Contains: HTML message body with ${variable} substitution, subject line, optional attachments
Variable Substitution in Email Bodies
Subject: [${number}] New task assigned - ${short_description} Hello ${assignment_group}, A new maintenance task has been assigned to your team. Task: ${number} Room: ${u_room.u_number} Description: ${description} Priority: ${priority} View it here: ${URI_REF} Thanks, Gardiner Hotels Maintenance System
Work Notes and Comments — Built-In Communication
The Additional Comments and Work Notes journal fields on Task records are connected to email notifications out of the box:
- Additional Comments — Visible to everyone including requesters. Updates are emailed to the Watch List.
- Work Notes — Private to the team. Updates are emailed to the Work Notes List and the Assigned To person.
This means a fulfiller can add a work note on a task and everyone on the work notes list automatically gets an email update. No separate notification setup needed for this basic case.
Reporting — Turning Data Into Insight
ServiceNow's built-in reporting creates charts and lists from any table. You don't need external tools for most reporting needs.
Available Report Types
Report Types in ServiceNow |
List — Filtered, sorted table of records with custom columns. Most versatile. |
Bar Chart — Compare values across categories (state, priority, team) |
Stacked Bar — Show proportional breakdown within categories |
Pie/Donut Chart — Show proportions of a whole |
Line Chart — Track trends over time (open tasks per day, SLA compliance by month) |
Heatmap — Show density across two dimensions (team vs. priority) |
Gauge — Single big number with optional goal indicator |
Multi-Level Pivot — Cross-tab analysis like a pivot table |
Security — Protecting Your Data
Security in ServiceNow is multi-layered. There's role-based access, field-level security, row-level security, domain separation for multi-tenant environments, and multiple authentication options. This chapter walks through all of them.
Roles — The Starting Point
A role is simply a named permission tag. You assign roles to users or groups. Those roles determine what menus they see and what ACL rules they pass.
Important: Give users the minimum permissions they need to do their job. Start with a specific role for your application and grant additional access only when needed. The 'admin' role should be reserved for true system administrators. |
Access Control Lists (ACLs) — Fine-Grained Security
ACLs control access to specific records and fields. They're evaluated every time a user tries to read or write data.
ACL Naming Convention
- u_maintenance — Row-level rule for the maintenance table (controls the whole record)
- u_maintenance.priority — Field-level rule for just the Priority field
- u_maintenance.* — Default rule for all fields in the table
- task.work_notes — Applies to work_notes across ALL tables that extend Task
- *.* — Catch-all default for everything not covered by more specific rules
Each ACL Can Have Three Conditions
- Role check — User must have a specific role
- Field condition — A record-field condition must be true (e.g., State is not Closed)
- Script — A JavaScript script must return true
ALL conditions that are present must be satisfied. If any one fails, access is denied.
ACL Execution Order
ServiceNow searches for the most specific applicable rule:
- It first checks the exact table name (u_maintenance)
- Then the parent table (task)
- Then the wildcard default (*)
More specific rules override less specific ones. This lets you inherit from parent tables and override only where needed.
T |
Getting Data OUT of ServiceNow
ServiceNow exposes all your data as web services by default. Just add a parameter to any list URL:
URL Parameter | Format You Get |
?CSV | Comma-separated values — opens in Excel or any spreadsheet app |
?XML | Standard XML — great for machine-to-machine transfer |
?EXCEL | Native Excel format (.xls) |
?JSON or ?JSONv2 | JSON data — great for web apps and modern integrations |
?WSDL | Web Service Definition — describes all available SOAP methods |
Formatted PDF document with styling |
Import Sets — Bringing Data In Safely
Import Sets are the right way to load bulk data from external systems. They use a two-stage process that lets you validate and transform data before it touches your actual tables.
The Import Set Process
- Define a Data Source — Tell ServiceNow where the data comes from (FTP, HTTP, database, file upload)
- Load the Data — Raw data lands in a staging table exactly as received
- Create a Transform Map — Map staging fields to target fields, add validation logic
- Run the Transform — Data flows from staging to your real table
- Coalesce flag: determines which field to match on to update existing records vs. create new ones
- Scripts let you manipulate data mid-transform (clean up strings, set default values, etc.)
Important: Every Transform Map must have at least one Coalesce field. Without it, every import creates brand new records, resulting in thousands of duplicates. The Coalesce field is usually something unique like an email address, employee ID, or external system ID. |
Transform Map Script Variables
Variable | What It Contains |
source | GlideRecord of the current staging row being processed |
target | GlideRecord of the record in the target table (being inserted or updated) |
action | String: 'insert' or 'update' — tells you what's happening |
ignore | Set to true to skip this row without creating/updating anything |
error | Set to true to abort the entire import with an error |
Moving Your Work — Update Sets
Building things is one challenge. Moving your carefully crafted configuration from Dev to Test to Production without breaking anything is another challenge entirely. This chapter gives you the tools and strategy to do it right.
Update Sets — Packaging Your Changes
An Update Set is a named container that automatically records your configuration changes as you make them. When you're ready to move those changes to another instance, you export the Update Set and apply it there.
How Update Sets Work
- You create an Update Set and select it as your 'current' set
- As you work — creating Business Rules, adding fields, changing forms — each change is captured
- When finished, mark the Update Set as 'Complete'
- Export it as XML, or let the target instance pull it directly from the source
- Preview it on the target (ServiceNow checks for potential problems)
- Commit it — the changes are applied
What Gets Captured (and What Doesn't)
Update Sets capture CONFIGURATION — things that make the system work differently. They do NOT capture data — the actual records users create and work with.
Captured in Update Sets |
Business Rules, Client Scripts, Script Includes, UI Actions |
Table definitions and field additions |
Form and list layouts |
ACL security rules |
Workflows (when published) |
System Properties |
Email Notifications and Templates |
NOT Captured in Update Sets |
User records, group records |
Incident records, task records — actual data |
Groups |
SLA definition |
Homepage customization |
Common Update Set Gotchas
Problem | How to Handle It |
Collision — same record changed in both source and target | Preview shows the conflict. You decide which version to keep. Usually keep the source (newer work). |
Missing dependency — a related record wasn't included | The preview warns you. Either add the missing record to the Update Set, or manually create it in the target first. |
Hardcoded sys_ids — scripts referencing specific records | The sys_id of a group might be different in each instance. Use properties or display values instead of hardcoded sys_ids. |
Workflows — tricky to transport correctly | Always publish each workflow separately. Sub-workflows need separate Update Sets. Test carefully in Dev first. |
Team Development — Git for ServiceNow
Team Development compares two instances and shows exactly what's different. Instead of manually packaging changes, it lets you push changes upstream or pull changes from a parent instance.
The Typical Setup
- Production — The golden master. Everything eventually gets pushed here.
- Test — Pulls from Dev, pushed to Prod after validation. Testers work here.
- Dev — Where all development happens. Pushes up to Test.
The workflow: Developer builds in Dev> Pushes to Test > Testers validate >Push to Production. If something needs fixing, fix it in Dev and push again — never fix directly in Production.
Wrapping Up — What To Do Next
You've just covered the entire ServiceNow platform — from the database foundations through to automating your data center. That's a lot. Don't try to absorb everything at once.
The Learning Path That Works
Stage | Focus Areas & Why |
Month 1: Foundations | Tables, fields, reference fields, table inheritance, forms, lists. Everything else builds on this. |
Month 2: Scripting Basics | GlideRecord (essential), GlideSystem helpers, Business Rules (before/after/display), basic Client Scripts. |
Month 3: Building an App | Build something real — a complete small application with forms, a workflow, notifications, and security rules. |
Month 4: Integration & Migration | Update Sets, Import Sets, REST API, Moving work between instances. |
The Key Mental Models to Hold
Concepts That Will Unlock Everything Else |
EVERYTHING IS A DATABASE RECORD — menus, scripts, layouts, security rules. All of it. |
sys_id is sacred — it's the universal foreign key. Never hard-code sys_ids in scripts. |
Table inheritance flows UP — children inherit everything from parents. Use this deliberately. |
Server-side is for security and logic. Client-side is for user experience. Never trust client-only. |
GlideRecord is the heart of all scripting — master it and you can do almost anything. |
Before Business Rules can block saves. After Business Rules react to saves. Use both intentionally. |
Update Sets capture configuration, not data. Plan your Dev/Test/Prod pipeline early. |
The simplest solution is usually the best — use the platform's built-in tools before writing custom code. |
Where To Keep Learning
- docs.servicenow.com — The official documentation. Comprehensive and well-maintained.
- developer.servicenow.com — Free Personal Developer Instances. Build and experiment for free.
- nowlearning.servicenow.com — Official training courses and certification prep.
- community.servicenow.com — Community forum. Real practitioners helping each other.
- Certifications worth pursuing: Certified System Administrator (CSA) first, then Certified Application Developer (CAD)
