1. Get a Personal Developer Instance
Everything in this course runs on a Personal Developer Instance (PDI) —
a free, full ServiceNow instance you provision from
developer.servicenow.com. It's the same platform enterprises run
ITSM on, just scoped to one developer account and one instance, with no cost and
no local install.
1. Create a free account at developer.servicenow.com
2. Request a PDI (takes a few minutes to provision)
3. Log in at https://<your-instance>.service-now.com
4. Default login: admin / <the password shown at provisioning>
Instances sleep after a period of inactivity to save resources — if yours shows "hibernating," wake it from the developer portal before starting a lesson.
2. The Platform's Layers: Tables, Applications & Scopes
ServiceNow has no separate "backend framework" the way a typical web stack does. Almost everything — incidents, users, your own custom records, even form definitions and scripts themselves — is a row in a table. Learn to read the platform as "a very large, very structured database with a UI and a scripting layer glued on top," and most of what follows stops feeling exotic.
- Table — like a SQL table, but every table auto-inherits system fields (
sys_id,sys_created_on,sys_updated_by, etc.) from the platform's base record type. - Application — a named grouping of tables, UI, and logic (Incident Management, or an app you build yourself).
- Scope — a namespace an application's tables and scripts live in, so two apps can both define a table named
requestwithout colliding. You'll build inside your own scope from Week 21 onward.
sys_id
Every record's primary key is a 32-character GUID called sys_id — not an auto-increment integer. You'll see it constantly in URLs, scripts, and API responses; get comfortable treating it as the record's real identity.
4. Studio: The IDE for Scoped Applications
Studio (Application Navigator → Studio) is where you'll spend most of your time once you start building your own application in Week 21 — a dedicated IDE-style view over one scoped app's tables, scripts, and UI artifacts, with source control integration built in. For the ITSM and Glide scripting modules in the next several weeks, you'll mostly work directly in the classic UI and list/form views instead, since you're extending existing out-of-the-box tables rather than building a new app from scratch.
You'll toggle between the classic UI (lists, forms, the individual script editors reached via the navigator) and Studio (a project-scoped, file-tree style view) throughout this course. Neither replaces the other — Studio is best once you're working inside one application's scope.
5. Hands-on Exercise
Provision your PDI and take the platform's pulse
Get your environment running and prove you can navigate it without a map.
Requirements:
- Provision a PDI and log in as
admin. - Use the navigator filter to open
incident.list, then open any incident record in form view. - Right-click the form header and choose "Show XML" — find the record's
sys_idand note it down. - Open
sys_db_object.list(the table of tables) and search for "incident" — find the row showing what tableincidentextends. - Open Studio and browse its "Create Application" flow far enough to see the scope-naming step, then cancel without creating anything yet.
sys_db_object is itself a table describing every other table on the platform — including itself. This kind of self-describing metadata is a recurring theme; you'll rely on it again when you extend tables in Week 2.
6. Knowledge Check
Four quick questions. Expand each to check your answer.
Q1
What is a PDI, and why does this course use one instead of a local install?
What is a PDI, and why does this course use one instead of a local install?
A Personal Developer Instance is a free, full ServiceNow instance provisioned in the cloud from developer.servicenow.com. ServiceNow has no local/on-machine runtime for individual developers to install — the platform is always a hosted multi-tenant application, so a PDI is the standard way to get a private, sandboxed instance to learn and build on.
Q2
What does it mean that "almost everything in ServiceNow is a table"?
What does it mean that "almost everything in ServiceNow is a table"?
Records you work with daily — incidents, users, and even the definitions of forms and scripts themselves — are rows in tables, each auto-inheriting system fields like sys_id from the platform's base record type. Treating the platform as a large, structured database with a UI and scripting layer on top demystifies most of what looks like platform magic later.
Q3
Why is sys_id used as the primary key instead of an auto-incrementing integer?
Why is sys_id used as the primary key instead of an auto-incrementing integer?
A 32-character GUID can be generated independently on any instance without coordinating with a central counter, which matters because ServiceNow customers run many separate instances (dev, test, prod, PDIs) that may need to exchange or merge records without ID collisions.
Q4
When would you reach for Studio instead of the classic UI's list/form views?
When would you reach for Studio instead of the classic UI's list/form views?
Studio is best once you're working inside one scoped application's boundary — it gives a project-scoped, file-tree style view over that app's tables, scripts and UI artifacts with source control built in. For extending existing out-of-the-box tables (what the next several weeks focus on), the classic UI's lists, forms and individual script editors are the more direct tool.