Top 50 ServiceNow Interview Questions & Answers

ServiceNow is a cloud-based platform that provides IT Service Management (ITSM), IT Operations Management (ITOM), and IT Business Management (ITBM) solutions. It uses a single data model and a common platform to connect workflows across departments — IT, HR, Customer Service, Security, and more. Everything runs on the Now Platform, which includes tables, forms, workflows, and a scripting engine.

• Base tables — standalone tables not extended from another (e.g., cmdb)
• Extended tables — inherit fields from a parent table (e.g., incident extends task)
• Core tables — platform system tables (e.g., sys_user, sys_user_group)
• Custom tables — user-created, prefixed with u_ (or x_ for scoped apps)

The task table is the base table for most work-related records. Incident, Problem, Change Request, and Requested Item all extend it. This means they inherit common fields like number, state, assigned_to, priority, and short_description. Any field added to task automatically appears on all child tables.

Access Control List (ACL) rules define who can read, write, create, or delete records. ACLs operate at three levels: table, row (conditional), and field level. Each ACL checks three things: Roles, Conditions, and Scripts — all three must pass for access to be granted. ACLs are evaluated from most specific (field-level) to least specific (table-level).

• UI Policy — client-side only. Makes fields mandatory, read-only, or visible on the form. Does not enforce via APIs, imports, or server scripts.
• Data Policy — server-side. Enforces rules across all access points: forms, APIs, Import Sets, and server scripts. Use Data Policy when rules must be enforced universally.

Update Sets capture configuration changes (not data) made in a development instance so they can be migrated to test/production. They track changes via the sys_update_xml table. Important: Update Sets do not capture data records (like users or CIs), scheduled jobs, or homepage configurations. Workflows must be published to be captured.

The Configuration Management Database stores information about IT assets (Configuration Items or CIs) and their relationships. CIs can be servers, applications, network devices, etc. The CMDB follows the Common Service Data Model (CSDM) structure. It's critical for Impact Analysis — understanding how a change to one CI affects dependent services.

New → In Progress → On Hold → Resolved → Closed. When a user reports an issue, an Incident is created in New state. An agent picks it up (In Progress), may pause it (On Hold), applies a fix (Resolved), and after confirmation, it's Closed. SLAs typically track time from New to Resolved.

• Incident — an unplanned interruption. Goal: restore service ASAP.
• Problem — the root cause of one or more incidents. Goal: prevent recurrence.
• Change — a planned modification to the IT environment. Goal: implement safely with approvals.

Flow Designer is a no-code/low-code automation tool that replaces legacy Workflows. It uses triggers (what starts the flow), actions (what the flow does), and conditions (branching logic). Flows can be triggered by record changes, schedules, or other flows. It supports subflows for reusability and integrates with IntegrationHub for external system actions.

Import Sets allow you to import data from external sources (CSV, Excel, JDBC, LDAP) into ServiceNow. Data first lands in a staging table (import set table), then a Transform Map maps fields from the staging table to the target table. Transform maps support coalesce fields for matching existing records (update vs insert).

Service Level Agreements define response and resolution time commitments. ServiceNow tracks SLAs via Task SLA records that attach to incidents/cases. Key components: SLA Definition (the rule), SLA Schedule (business hours), and SLA Conditions (when to start/stop/pause the clock). Breached SLAs can trigger notifications and escalations.

The Service Catalog is a self-service portal where end users can request services and items. Key components:

• Catalog Items — orderable services/products
• Record Producers — create records (like incidents) via a catalog-like form
• Order Guides — bundle multiple items into one guided order
• Categories — organize items into logical groups

The flow: Request → Requested Item(s) → Catalog Task(s).

Roles control what a user can do (access, read, write, admin). Groups control who works together (assignment, approval routing). Roles are assigned to users or groups. A user inherits all roles from their groups. Example: the itil role lets you work Incidents; being in the "Network Team" group means network incidents get assigned to you.

Knowledge Management stores articles (solutions, how-tos, FAQs) in Knowledge Bases. Articles go through a workflow: Draft → Review → Published → Retired. Knowledge is surfaced to users via search, the Service Portal, and Virtual Agent. It helps deflect incidents by enabling self-service resolution.

Notifications are email alerts triggered by events or conditions on records. Key fields: When to send (event or condition), Who will receive (users, groups, email fields), and What it will contain (email template with variable substitution). Notifications use Events as triggers — e.g., incident.assigned fires when an incident is assigned.

System Properties are key-value pairs that control instance-wide behavior. Examples: glide.ui.default_page sets the landing page, glide.sys.date_format sets date display format. Properties can be accessed via gs.getProperty('name') in server scripts. They're useful for configuration without code changes.

Domain Separation allows a single ServiceNow instance to serve multiple independent organizations (tenants). Each domain has its own data, processes, and configurations. Data in one domain is invisible to users in another. It's commonly used by MSPs (Managed Service Providers) and large enterprises with independent business units.

• View — controls which fields are displayed on a form or list (layout). Different views show different fields for the same record.
• Filter — controls which records are displayed in a list. Filters don't change the fields shown, just which rows appear.

Impersonation lets an admin act as another user to test their access and see their view of the platform. It's useful for debugging ACLs, testing role-based access, and troubleshooting user issues. All actions during impersonation are logged and attributed to the impersonating admin for audit purposes.

GlideRecord is a server-side JavaScript API for querying and manipulating database records. It's the primary way to interact with tables in Business Rules, Script Includes, and Scheduled Jobs. Example: var gr = new GlideRecord('incident'); gr.addQuery('state', 1); gr.query(); while(gr.next()) { /* process */ }

GlideRecord retrieves individual records. GlideAggregate performs aggregate operations (COUNT, SUM, AVG, MIN, MAX) without loading full records — it's much faster for counting or summing. Use GlideAggregate when you need statistics, not individual record data.

Business Rules are server-side scripts that execute when a record is displayed, inserted, updated, or deleted. Types:

• Before — runs before the database operation (can modify current)
• After — runs after the database operation (current is read-only)
• Async — runs after, in a separate thread (for heavy operations)
• Display — runs before the form loads (can pass data via g_scratchpad)

Client Scripts run in the user's browser. Types:

• onLoad — when the form loads
• onChange — when a field value changes
• onSubmit — when the form is submitted (can prevent submission)
• onCellEdit — when a cell is edited in list view

Client Scripts can access the form via g_form and the list via g_list. They cannot directly query the database — use GlideAjax for server calls.

GlideAjax allows client-side scripts to call server-side Script Includes. It's the bridge between browser and server. The client script sends a request to a Script Include (which must extend AbstractAjaxProcessor), and the server returns data. Use it when a Client Script needs to query the database or run server logic.

Script Includes are reusable server-side JavaScript classes/functions. They're only loaded when called (on-demand), unlike Business Rules which execute automatically. Use cases: utility functions, custom APIs, GlideAjax handlers. Script Includes that handle GlideAjax calls must extend AbstractAjaxProcessor.

current contains the new values being saved. previous contains the values before the update. Example: to check if priority changed: if (current.priority != previous.priority) { /* do something */ }. Note: previous is only available on update operations, not insert.

g_form is the client-side GlideForm API for interacting with forms. Common methods:

• g_form.getValue('field') — get field value
• g_form.setValue('field', value) — set field value
• g_form.setMandatory('field', true) — make field mandatory
• g_form.setVisible('field', false) — hide a field
• g_form.addInfoMessage('text') — show info banner

g_scratchpad passes data from a Display Business Rule (server) to a Client Script (browser). In the Display BR: g_scratchpad.isVip = current.caller_id.vip.toString();. In the Client Script: if (g_scratchpad.isVip == 'true') { /* highlight */ }. It's the recommended way to avoid client-side GlideRecord calls.

Application Scope isolates custom applications from each other and from global. Scoped apps have their own namespace (x_[vendor]_[app]), their own tables, and controlled access to global resources. Scripts in a scoped app can only access global APIs explicitly allowed. This prevents naming conflicts and enforces security boundaries.

• gs.log() — writes to the system log (syslog). Visible in System Logs → System Log.
• gs.info(), gs.warn(), gs.error() — structured logging with severity levels.
• gs.print() — outputs to the screen (only works in background scripts). Not for production use.

ATF lets you create and run automated tests for ServiceNow configurations. You can test form submissions, server-side scripts, and UI interactions. Tests include steps like "Open a record", "Set field value", "Assert field equals". ATF is critical for validating that configurations work correctly before promoting to production.

UI Actions add buttons, links, or context menu items to forms and lists. They can run client-side scripts, server-side scripts, or both. Examples: "Resolve Incident" button, "Assign to Me" link. UI Actions have conditions that control when they appear and can be restricted by roles.

ServiceNow provides both inbound and outbound REST APIs:

• Table API — CRUD operations on any table (/api/now/table/{tableName})
• Scripted REST API — custom endpoints with your own logic
• REST Message — outbound calls to external systems

Authentication: Basic Auth, OAuth 2.0, or mutual TLS.

getValue() returns the internal/database value (e.g., sys_id for reference fields, integer for choice fields). getDisplayValue() returns the human-readable label (e.g., user's name for reference fields, choice label for choice fields). Always use getDisplayValue() when showing data to users.

In a before Business Rule: current.setAbortAction(true); This prevents the insert/update from happening. You should also show a message: gs.addErrorMessage('Cannot save: reason');. This only works in before rules — after rules can't abort because the save already happened.

Scheduled Jobs run server-side scripts on a schedule (daily, weekly, custom intervals). Use cases: data cleanup, sending reports, syncing with external systems. They're configured via System Definition → Scheduled Jobs. Important: Scheduled Jobs run as the system user unless configured otherwise.

current.update() saves the current record immediately. Avoid it in Before Business Rules — it causes a recursive save loop and double execution of other Business Rules. In a Before rule, just set values on current and the system will save automatically. Use current.update() only in After rules or Scheduled Jobs when necessary.

Workflow is the legacy automation engine (graphical drag-and-drop). Flow Designer is the modern replacement — no-code, supports subflows, integrates with IntegrationHub, and is actively developed. ServiceNow recommends Flow Designer for all new automation. Workflows must be published to be captured in Update Sets; Flows are captured automatically.

gs is the GlideSystem API — a server-side utility object available everywhere. Common methods:

• gs.getUserID() — current user's sys_id
• gs.getUserName() — current user's username
• gs.hasRole('admin') — check if user has a role
• gs.addInfoMessage() — show message on the form
• gs.getProperty('name') — read system property
• gs.now() — current date/time

Check in this order:

• Form layout — is the field on the current view/form layout?
• ACL — does the user have read access to that field?
• UI Policy — is a UI Policy hiding the field based on a condition?
• Client Script — is a Client Script using g_form.setVisible('field', false)?
• Role — does the user have the required role to see the field?

Tip: Impersonate the user and check Security Diagnostics (/sys_security.do).

1. Make all changes in Dev inside a named Update Set
2. Complete the Update Set
3. Export the Update Set as XML (or use connected instances)
4. Import it into Test/Prod as a Retrieved Update Set
5. Preview — check for conflicts and errors
6. Commit — apply the changes

Always test in a non-production instance first. Resolve any collisions during Preview.

Most common cause: calling current.update() in a Before Business Rule. This triggers another save, which re-triggers the Business Rule. Fix: remove current.update() from Before rules — just set values on current and let the system save. Other causes: duplicate Business Rules on the same table, or a Workflow/Flow that updates the record.

Create an Assignment Rule or a Before Insert Business Rule:

• Assignment Rules — no-code, set conditions (category = Network) → assign to group (Network Team)
• Business Rule — more flexible, can use scripts for complex logic
• Flow Designer — trigger on insert, use decision logic to set assignment group

Assignment Rules are the cleanest approach for simple routing.

1. Create an Import Set — upload the CSV
2. ServiceNow creates a staging table with the CSV columns
3. Create a Transform Map — map CSV columns to sys_user fields
4. Set a coalesce field (e.g., email) — this determines update vs insert
5. Run the transform — data moves from staging to sys_user

For recurring imports, save the Transform Map and schedule the import.

Use a UI Policy:

• Condition: State = Resolved
• Action: Set resolution_code to Mandatory = true

If it must be enforced via APIs too, use a Data Policy with the same condition. For more complex logic, use a Before Business Rule with current.setAbortAction(true) if the field is empty.

Create a row-level ACL on the table:

• Operation: read
• Role: leave empty (applies to all users)
• Condition: Created by is (dynamic) Me

This ensures each user only sees records they created. Admins bypass ACLs, so they'll still see everything.

Check the SLA Definition:

• Is the Pause condition set correctly? It should be State = On Hold.
• Is the SLA using a Schedule? Pausing only works within the schedule context.
• Check Retroactive Pause — if not enabled, SLAs created before the config change won't pause.
• Check the Task SLA record — look at the Stage field and SLA timeline for debugging.

Use a Display Business Rule with g_scratchpad. In the Display BR (server-side): g_scratchpad.callerVip = current.caller_id.vip.toString();. In the Client Script (onLoad): var isVip = g_scratchpad.callerVip;. This is more efficient than GlideAjax because the data is loaded with the form — no extra server call needed.

Use Flow Designer with decision logic:

1. Trigger: Change Request inserted or updated
2. Decision: Check type field (Standard, Normal, Emergency)
3. Standard → auto-approve (pre-approved template)
4. Normal → route to CAB for approval
5. Emergency → route to Emergency CAB + post-implementation review

Alternatively, create separate Workflow/Flow for each change type and use a Flow Trigger condition to route.