What are you looking for?

ServiceNow Developer Guide for Beginners: Where to Actually Start

Skylo Wiki
Skylo Wiki
Author at Skylo Wiki
March 16, 2026 · 17 min read
Share:

I remember the first time I logged into ServiceNow. Someone at work had set up a developer instance for me, handed me the URL, and said “just explore it.” I stared at the screen for twenty minutes and had no idea what I was looking at.

If that sounds familiar — this article is for you.

ServiceNow is one of those platforms that looks overwhelming at first but clicks pretty fast once someone explains the right things in the right order. The problem is most guides either go too deep too fast, or stay so surface-level they’re useless after five minutes.

This guide is neither. It’s the one I wish I had when I started.

By the end of it you’ll have your own free developer environment running, understand how the platform is structured, know what the core concepts actually mean, and have written your very first working script.

Let’s go.


What Is ServiceNow and Why Should You Learn It?

ServiceNow is a cloud-based platform that companies use to manage IT services, automate workflows, and handle everything from employee onboarding to security incidents — all in one place.

Think of it like this: every time you raise a support ticket at your company, request access to a system, or get your laptop replaced by IT — there’s a good chance ServiceNow is the engine running that process behind the scenes.

More than 85% of Fortune 500 companies use it. Banks, hospitals, telecom companies, government departments — the adoption is everywhere.

For developers, this means one thing: demand is real and it’s high.

Entry-level ServiceNow developers in the US earn between $90,000–$120,000/year. Senior developers and Solution Architects regularly clear $150,000+. In India, certified ServiceNow professionals are among the highest-paid in the IT sector.

But beyond salary — it’s a genuinely interesting platform to work on. You’re not just writing code. You’re solving actual business problems, automating workflows that affect thousands of people, and seeing your work in use every single day.

What Does a ServiceNow Developer Actually Do?

Unlike a traditional software developer who builds apps from scratch, a ServiceNow developer works within the platform to:

  • Build and customise applications on top of the ServiceNow framework
  • Write server-side and client-side scripts (JavaScript)
  • Create automated workflows using Flow Designer or Workflow Editor
  • Build Service Catalog items (the forms users fill in to make requests)
  • Integrate ServiceNow with external systems like Jira, Slack, SAP, or Azure
  • Manage tables, fields, forms, and access controls

You don’t need to know Java, Python, or any backend language to start. ServiceNow scripting is JavaScript-based, and the platform provides its own APIs (called Glide APIs) that handle most of the heavy lifting for you.


Step 1: Get Your Free Developer Instance

Before anything else — you need a place to practice. The good news is ServiceNow gives every registered developer a free Personal Developer Instance (PDI). It’s a full, real ServiceNow environment that you own and can break as many times as you like without any consequences.

Here’s how to get yours:

1. Go to the Developer Portal

Head over to developer.servicenow.com and click Sign Up.

[Screenshot: ServiceNow Developer Portal homepage — shows the “Start Building” CTA and sign-up option]

2. Create Your Account

Register with your email address. Use a real email — you’ll need to verify it. Fill in your name, company (you can put “Personal” if you’re learning independently), and set a password.

3. Request a Developer Instance

Once logged in, click Request Instance from your dashboard. You’ll be asked to choose a release version — pick the latest stable release (at the time of writing this is the Xanadu release). Stick with the latest unless a specific tutorial you’re following requires an older version.

[Screenshot: ServiceNow Developer Portal dashboard showing the “Request Instance” button]

4. Wait and Log In

Your instance spins up in about 2–3 minutes. You’ll receive an email with your instance URL, username (usually admin), and a temporary password.

Your URL will look something like: https://dev12345.service-now.com

Log in with the admin credentials and you’re in.

Important: Your developer instance hibernates after a period of inactivity (usually 10 days). You’ll get an email warning you before it happens. Simply log in to wake it up. If it’s been hibernating for too long it gets reclaimed — so log in regularly and save your work.


Step 2: Understand the Interface — Don’t Skip This

The biggest mistake beginners make is jumping straight into scripting without understanding how the platform is laid out. Spend 30 minutes here and everything else will make more sense.

The Application Navigator

This is the left-hand sidebar — the main way you navigate the entire platform. It lists every module available to you, organised into application groups.

Type anything in the filter box at the top of the navigator and it will search across all modules. This becomes your best friend very quickly.

[Screenshot: ServiceNow Application Navigator — left sidebar with filter box and module list highlighted]

Try typing “Incident” — you’ll see options like Incident → All, Incident → Create New, Incident → Open. That’s the Incident Management module, which is one of the most core parts of the platform.

The Banner and User Menu

The top bar has your profile, settings, and — critically — the System Settings gear icon. Click it and set the UI to UI16 if you’re on an older instance, or leave on the default for newer ones. You’ll also find the ability to enable the developer mode here.

Lists and Forms

Almost everything in ServiceNow is either a List (a table of records) or a Form (a single record).

  • List view: rows and columns, like a spreadsheet. Each row is a record.
  • Form view: a single record opened up, showing all its fields.

Right-click on a column header in list view and you’ll see options to filter, sort, or configure the columns. Right-click on a field in form view and you’ll see options to configure that field. This right-click menu is where a lot of developer power lives.


Step 3: Learn the Core Concepts (Plain English)

ServiceNow has its own vocabulary. Once you know these terms, documentation suddenly starts making sense.

Term What It Actually Means
Table A database table. Every type of record (Incident, User, Task) lives in its own table. Like a spreadsheet tab.
Record A single row in a table. One incident = one record.
Field A column in a table. The “Short Description” field on an Incident, for example.
Form The UI view of a single record. What you see when you open an Incident.
Incident An unplanned interruption to a service. “My laptop won’t connect to Wi-Fi” = an Incident.
Change Request A planned change to a system or process that requires approval before it happens.
Service Catalog A menu of things users can request — like ordering a new laptop or requesting software access.
Business Rule Server-side script that runs automatically when a record is inserted, updated, deleted, or queried.
Client Script JavaScript that runs in the user’s browser when they interact with a form.
GlideRecord The main API for querying and modifying database records in ServiceNow scripts.
ACL Access Control List — controls who can read, write, create, or delete records.
Update Set A container for capturing your configuration changes so you can move them between environments (like dev → test → production).
Scope / Application A namespace for your customisations. Keeps your code separate from other apps and from the base platform.

Don’t try to memorise all of this. Come back to this table when you hit a term you don’t recognise.


Step 4: Always Work Inside an Update Set

This is something many beginners skip and regret later.

An Update Set tracks every configuration change you make on an instance — new scripts, modified forms, new fields, workflow changes — everything. Without one, your changes are invisible to the tracking system and can’t be moved to another instance cleanly.

Here’s how to create and activate one before you do anything else on your dev instance:

  1. In the Application Navigator, search for Update Sets
  2. Go to System Update Sets → Local Update Sets
  3. Click New
  4. Give it a clear name — e.g., Learning - Basics - [Your Name]
  5. Click Submit
  6. Open the Update Set you just created and click Make This My Current Set

Now every change you make will be captured inside that Update Set. Get into the habit of creating a new Update Set for every feature or task you work on.

[Screenshot: ServiceNow Update Sets list view — showing the “Make This My Current Set” option highlighted]


Step 5: Explore Tables and the Data Dictionary

One of the most useful things you can do early on is get comfortable with how tables work in ServiceNow.

Navigate to System Definition → Tables in the Application Navigator. You’ll see a list of every table on the platform. Search for “incident” and open the Incident table.

What you’ll see:

  • The table name: incident (always lowercase — this is what you use in scripts)
  • All the fields on the table and their data types
  • Which tables it extends (Incident extends Task, which is a core table)

Table Inheritance — A Critical Concept

ServiceNow uses table inheritance heavily. The task table is the parent of Incident, Change, Problem, and many others. This means they all share common fields like number, short_description, assigned_to, state, and sys_id.

When you write a script that works on the Task table, it often works on Incidents and Changes too. This is a powerful concept that saves a lot of repeated work.


Step 6: Write Your First GlideRecord Script

Here’s where the actual developer work begins. GlideRecord is the primary API for interacting with the database in ServiceNow. Almost every server-side script you write will use it.

Think of GlideRecord like a SELECT query combined with the ability to loop through results and modify them.

Open the Script Editor

Go to System Definition → Scripts – Background in the Application Navigator. This is a server-side script playground — it runs code directly on the server and you can see the output immediately. Perfect for learning.

[Screenshot: ServiceNow Background Scripts interface — empty script editor with Run Script button]

Warning: Background Scripts run with full admin permissions. On a production instance, only senior developers should have access. On your dev instance, it’s safe — but treat it with respect even here.

Example 1: Query All Open Incidents

Paste this into the script editor and click Run Script:

var gr = new GlideRecord('incident');
gr.addQuery('state', '1'); // 1 = New
gr.query();

while (gr.next()) {
    gs.info('Incident: ' + gr.number + ' - ' + gr.short_description);
}

Here’s what each line does:

  • new GlideRecord('incident') — creates a query object pointing at the incident table
  • addQuery('state', '1') — adds a WHERE clause: state = 1 (New)
  • gr.query() — executes the query against the database
  • while (gr.next()) — loops through each returned record
  • gs.info(...) — prints output to the log (you’ll see it at the bottom of the screen)
  • gr.number — accesses the number field of the current record

Run it. You should see a list of Incident numbers and descriptions in the output. If your dev instance has no incidents yet, it returns nothing — try changing the query to gr.query() without the addQuery line to fetch all incidents.

Example 2: Update a Record

This script finds an incident by number and updates its description:

var gr = new GlideRecord('incident');
gr.addQuery('number', 'INC0010001'); // Replace with a real number from your instance
gr.query();

if (gr.next()) {
    gr.short_description = 'Updated by script - learning GlideRecord';
    gr.update();
    gs.info('Updated successfully: ' + gr.number);
} else {
    gs.info('Incident not found');
}

Key things to note:

  • if (gr.next()) — when you expect one record, use if not while
  • gr.field_name = 'value' — sets a field value
  • gr.update() — saves the changes to the database

Example 3: Create a New Record

var gr = new GlideRecord('incident');
gr.initialize(); // Prepares a new record with default values

gr.short_description = 'Test incident created via script';
gr.category = 'software';
gr.impact = '3'; // 3 = Low
gr.urgency = '3'; // 3 = Low

var sysId = gr.insert(); // Saves the record and returns its sys_id

gs.info('Created incident with sys_id: ' + sysId);

Run this and then navigate to Incident → All — you’ll see your newly created incident at the top of the list. That feeling never gets old.


Step 7: Write Your First Business Rule

Business Rules are server-side scripts that run automatically when records are created, updated, deleted, or queried. They’re one of the most commonly used tools in ServiceNow development.

Let’s create a simple one: automatically set the priority of an Incident to “Critical” when a VIP user submits it.

Create the Business Rule

  1. Navigate to System Definition → Business Rules
  2. Click New
  3. Fill in the header:
    • Name: Set Critical Priority for VIP Users
    • Table: Incident [incident]
    • When: before
    • Insert: ✅ checked
    • Update: ✅ checked
  4. Scroll down to the Advanced tab and paste this script:
(function executeRule(current, previous /*null when async*/) {

    // Check if the caller is a VIP user
    var callerGr = new GlideRecord('sys_user');
    if (callerGr.get(current.caller_id)) {
        if (callerGr.vip == true) {
            current.priority = '1'; // 1 = Critical
            current.impact    = '1'; // 1 = High
            current.urgency   = '1'; // 1 = High
            gs.addInfoMessage('Priority set to Critical — VIP caller detected.');
        }
    }

})(current, previous);

[Screenshot: ServiceNow Business Rule form — showing the When/Insert/Update checkboxes and the script tab]

Click Submit to save it.

Now create a new Incident and set the Caller to a user who has the VIP flag checked (you can set this on any user record under System Security → Users). When you submit the Incident, the priority should automatically jump to Critical.

Understanding Business Rule Timing

When What It Means Use Case
before Runs before the record is saved to DB Modify field values before save
after Runs after the record is saved Trigger notifications, create related records
async Runs in background after save Heavy operations that don’t need to block the user
display Runs when record is loaded in form view Pre-populate g_scratchpad values for Client Scripts

Use before when you need to change values on the record being saved. Use after or async for everything else. Running heavy operations in before rules slows down every save — something experienced developers watch closely.


Step 8: Write Your First Client Script

Client Scripts run in the user’s browser — not on the server. They’re JavaScript that reacts to what happens on a form in real time: a field changes, a form loads, a user submits.

There are four types:

Type When It Runs
onLoad When the form first loads
onChange When a specific field value changes
onSubmit When the user clicks Submit
onCellEdit When a cell is edited in list view

Let’s create a simple one: show a warning message when someone sets an Incident’s Impact to “High”.

  1. Navigate to System Definition → Client Scripts
  2. Click New
  3. Fill in:
    • Name: Warn on High Impact Selection
    • Table: Incident [incident]
    • Type: onChange
    • Field Name: Impact
  4. Paste this script:
function onChange(control, oldValue, newValue, isLoading, isTemplate) {
    if (isLoading || newValue === '') {
        return; // Don't run on initial page load
    }

    if (newValue === '1') { // 1 = High impact
        g_form.showFieldMsg(
            'impact',
            '⚠️ High Impact selected — make sure you have manager approval before assigning.',
            'info'
        );
    } else {
        g_form.hideFieldMsg('impact', true); // Remove the message if impact changes away from High
    }
}

Save it. Open any Incident form, change the Impact field to 1 – High, and you’ll see the blue info message appear directly under the field. Change it to something else and it disappears.

[Screenshot: ServiceNow Incident form — showing the inline field message appearing below the Impact field after selecting High]

The g_form API is the main tool for Client Scripts. Key methods:

  • g_form.getValue('field_name') — get a field’s value
  • g_form.setValue('field_name', 'value') — set a field’s value
  • g_form.setMandatory('field_name', true) — make a field required
  • g_form.setReadOnly('field_name', true) — make a field read-only
  • g_form.setVisible('field_name', false) — hide a field
  • g_form.showFieldMsg('field_name', 'message', 'info') — show a message under a field

Step 9: Understand the Most Important Rule in ServiceNow Development

Here it is — the one thing that separates beginners from developers who actually know what they’re doing:

Configuration before Customisation.

Always try to solve a problem using the platform’s built-in tools before writing a single line of code.

ServiceNow has an enormous amount of out-of-the-box functionality. Flow Designer, Notifications, UI Policies, Data Policies, Approval workflows — most things you need can be configured without scripting at all.

Why does this matter?

  • Upgrades: ServiceNow releases major platform upgrades twice a year. Configuration survives upgrades cleanly. Heavy customisation (code) can break.
  • Performance: Built-in tools are optimised by ServiceNow. Your custom script might not be.
  • Support: If you’re on a client’s instance, customisations can affect their support agreement.

When you do need to write code — write it inside a properly scoped application, follow the coding standards, and test everything in dev before it touches production.


Step 10: What to Learn Next

You’ve covered a lot. Here’s a clear path forward:

What to Learn Why It Matters Where to Learn
Flow Designer Modern visual workflow builder — replaces Workflow Editor in most new projects Your dev instance + Now Learning
Script Includes Reusable server-side JavaScript libraries you can call from any script ServiceNow Docs
REST API Integration Connect ServiceNow to external systems — critical for enterprise work ServiceNow REST API Explorer (built into your instance)
Service Catalog Build catalog items that users request — bread and butter of ServiceNow development Your dev instance
CSA Certification Certified System Administrator — the entry-level cert that opens doors now.learning.servicenow.com (free)
Scoped Applications Build proper, upgrade-safe applications inside a namespace ServiceNow Developer Community

The ServiceNow community at community.servicenow.com is genuinely excellent. Search any problem you hit there before spending hours debugging alone.


Quick Reference: Most Used GlideRecord Methods

// Query records
var gr = new GlideRecord('table_name');
gr.addQuery('field', 'value');
gr.addQuery('field', 'CONTAINS', 'text');    // Like a LIKE query
gr.addNotNullQuery('field');                  // WHERE field IS NOT NULL
gr.addNullQuery('field');                     // WHERE field IS NULL
gr.orderBy('field');                          // ASC sort
gr.orderByDesc('field');                      // DESC sort
gr.setLimit(10);                              // LIMIT 10
gr.query();

// Loop results
while (gr.next()) {
    var val = gr.getValue('field_name');      // Always use getValue() for safe output
    gs.info(val);
}

// Get one record by sys_id
gr.get('abc123def456...');

// Create record
gr.initialize();
gr.field_name = 'value';
var newSysId = gr.insert();

// Update record
gr.field_name = 'new value';
gr.update();

// Delete record (use carefully)
gr.deleteRecord();

// Count records
var count = new GlideAggregate('table_name');
count.addQuery('state', '1');
count.addAggregate('COUNT');
count.query();
count.next();
var total = count.getAggregate('COUNT');

Wrapping Up

You’ve gone from zero to running real queries, creating records, writing Business Rules, and building Client Scripts — all in one sitting.

ServiceNow has a reputation for being hard to learn. In my experience, it’s not hard — it’s just big. There’s a lot of it. But the core concepts we covered today are the ones you’ll use in 80% of everything you build, regardless of how advanced you get.

The most important thing now is to keep your hands on the platform. Open your dev instance every day. Break things. Fix them. The people who get good at ServiceNow fast are not the ones who read the most — they’re the ones who build the most.

In the next article in this series, we’ll go deeper into Flow Designer — how to build automated workflows visually, connect them to triggers, and pass data between actions without writing a single line of code. It’s genuinely powerful and it’s where most modern ServiceNow development lives today.

If anything in this guide wasn’t clear, drop a comment below — I read every one.

Skylo Wiki

About the author:

Skylo Wiki

Author at Skylo Wiki

Related Articles

Leave a Reply

Your email address will not be published. Required fields are marked *

four + seventeen =