ServiceNow Developer Interview Questions and Answers

A ServiceNow developer builds and maintains custom applications and automations on the Now Platform—data model, forms, client and server scripts, ACLs, flows, integrations, and upgrade-safe scoped apps—not only configuring ITSM modules out of the box.

Typical ownership:

Senior developers also own performance, CSDM/CMDB alignment, and Now Assist readiness (guardrails on generated scripts).

A strong answer separates developer work from admin work (instance strategy, major module config)—but real roles blend both.

Developer interviews drill Glide API execution context, security enforcement, and why you picked a business rule over a client script.

Admin interviews drill process design (incident, change, problem) and platform operations.

Read the job description: many roles want both—prepare one ITSM scenario and one custom-app scenario.

Common pattern: 4–6 rounds

Partners and SIs often add online assessments on scripting basics before technical screens.

A strong candidate narrates execution context (browser vs server vs async) while answering.

Use a personal developer instance (PDI) or company subprod—memorizing syntax without hands-on falls apart on scenario follow-ups.

Supplement with SQL interview prep if the role includes reporting or data exports.

ServiceNow is a low-code enterprise workflow platform on a single data model (tables + ACLs + UI metadata), not a generic three-tier web app you deploy arbitrary server code into.

Key ideas interviewers expect:

• Metadata-driven UI — forms, lists, and policies stored as records
• Configuration first — UI Policies, Flow Designer, Data Policies before custom scripts
• Upgrade-safe development — scoped applications, avoid core table over-customization
• Modules — ITSM, CSM, HRSD, GRC, custom apps on same engine

A strong answer connects architecture to maintainability across upgrades and one instance, many apps.

Child tables extend parent tables and inherit columns and behavior.

task (base)
  └── incident
  └── change_request
  └── problem

Implications developers must know:

Extending Task is standard for work records so assignment, state, and SLAs stay consistent.

Follow-up: database views vs extended tables—views for read-only union reporting, extensions for real IS A relationships.

Global scope — legacy shared namespace; higher collision and upgrade risk.

Scoped application — packaged module with:

• Own namespace prefix (x_company_app_table)
• Controlled application files and APIs
• Cross-scope access policies for foreign table access
• Cleaner transport via application repository / pipeline

Interviewers want:

• Tables and Script Includes live in the app scope that owns them
• Cross-scope requests are explicit, not accidental gs.info() hacks
• You understand what ships in an app vs ad hoc global changes

Senior answer: wrong scope design causes merge conflicts and failed deployments between teams.

Platform-first decision tree:

Say aloud: “I’d start with OOB—UI Policy / Flow—because it’s upgrade-friendly and visible to admins.”

Code when configuration cannot express transaction rules, integrations, or performance-sensitive batch logic.

This mindset separates junior memorizers from hireable developers.

Client Scripts run in the browser on forms (classic UI, Platform Analytics lists differ—clarify context).

Good uses:

• UX hints, dynamic filters, client-side warnings
• Calling GlideAjax for server lookups

Bad uses:

• Authoritative security (bypass via API)
• Data integrity that must survive import/REST (belongs server-side)
• Heavy synchronous server round trips

Pair with technical specialist empathy—scripts should not freeze agents during major incidents.

Default to UI Policy for visibility and mandatory fields.

Use Client Script when UI Policy cannot express the rule (dynamic reference queries, calculated messages, async validation).

Interviewers listen for “UI Policy first” before you mention scripts.

Browsers cannot call GlideRecord directly—no database access on the client.

Flow:

1. Client Script creates GlideAjax('ScriptIncludeName')
2. addParam('sysparm_name', 'methodName') + parameters
3. getXMLAnswer(callback) — asynchronous
4. Server Script Include (AjaxProcessor or client-callable) runs and returns XML/JSON

Why async matters: synchronous calls freeze the browser—bad for agent desktops.

Prefer GlideAjax over legacy patterns that block the UI; compare with getReference() only when appropriate for simple reference fields.

A strong answer explains bridge pattern, not line-by-line syntax only.

• Security enforcement — use ACLs and server rules
• Final validation before persist — use before business rules or Data Policies
• Bulk imports / integrations — bypass the form entirely
• Sensitive data hiding — DOM hiding ≠ access control

Interview scenario: “Hide salary field from users.”

Wrong: Client Script g_form.setVisible(false) only.

Right: Field ACL + UI Policy for UX.

This parallels Salesforce LWC vs sharing rules—UI is not security.

Business Rules are server-side scripts tied to table CRUD/display operations.

Operations filter: insert, update, delete, query.

Golden rules:

• Before to change current without extra update()
• After to touch other tables
• Minimize rule count—overlapping rules are hard to debug

A strong answer includes order of execution awareness (multiple rules on same event).

Before example — abort invalid transition:

// ServiceNow server script — runs on Before Update, Incident table
if (current.state == '7' && !canCloseIncident(current.sys_id)) {
    gs.addErrorMessage('Close all open tasks before resolving the incident.');
    current.setAbortAction(true);
}

setAbortAction(true) stops the save—must run before database commit.

Async when user should not wait—but do not assume immediate consistency for related reads.

ServiceNow-specific APIs (current, gs) require the platform—the logic above is validated as a close-guard pattern using the same rules in plain JavaScript tests.

Decision guide:

• Flow — approvals, notifications, branching, low-code handoff to admins
• Business Rule — tight coupling to DB insert/update, complex validation
• Script Include — shared functions called from BR, Flow script step, REST

Senior answer: avoid duplicating the same logic in Flow script step and Business Rule—centralize in Script Include.

In 2026, know when Flow subflows replace old workflow—still see workflow in mature instances.

Practices interviewers reward:

• Single responsibility — one class per domain (IncidentTaskValidator)
• Client callable only when needed (AbstractAjaxProcessor)
• API access — public / private methods in class-style includes
• No GlideRecord in tight loops — batch queries inside includes
• Unit-testable logic where possible (ATF or extracted pure functions)

Anti-pattern: copy-paste GlideRecord blocks across five business rules instead of one Include.

Naming: scoped prefix, descriptive method names (validateClose, resolveAssignmentGroup).

Use previous to detect what changed:

if (current.assignment_group.changes() && previous.assignment_group) {
    gs.eventQueue('incident.assignment.changed', current, current.sys_id, '');
}

g_scratchpad.myFlag = true on display BR → read in onLoad Client Script.

Follow-up: current.update() in after BR can re-trigger rules—know recursion risk.

Events decouple automation:

1. Business rule calls gs.eventQueue('event.name', current, parm1, parm2)
2. Script Action or Notification or Flow triggered by registered event

Use when:

• Multiple listeners react to same change
• Async notification without blocking save
• Integration fan-out

Know event registration (sysevent_register) and avoid infinite loops (event → update → event).

Contrast with scheduled jobs for time-based batch work.

Access Control Lists enforce server-side create/read/write/delete on tables and fields.

Types:

• Table ACL — row-level CRUD
• Field ACL — column-level write/read
• Conditional ACLs — script or query condition
• Scripted ACL — advanced answer script (use sparingly for performance)

Evaluation: deny by default unless a rule grants access; roles attached to ACLs.

security_admin role required to edit ACLs—often with elevation.

Interview must-know: ACLs apply to REST, imports, and scripts—not only the form.

A strong answer mentions ACL debugging (security rules module, gs.hasRole).

“Hide confidential field” requires field ACL.

“Make field mandatory on form” — UI Policy or Data Policy depending on import needs.

Never treat client-side hide as compliance control.

When role checks alone are insufficient—e.g., record owner, assignment group member, or domain separation logic.

Cautions interviewers expect:

• Performance — scripted ACLs run per row/field access
• Caching — understand when ACL scripts re-run
• Prefer reference qualifiers and roles when possible

Example scenario: user may edit incident only if they are assigned to or in assignment group.

Senior: combine ACL with before business rule only for business logic—not as ACL replacement for simple roles.

Best practice: assign roles to groups, groups to users—not roles directly to hundreds of users.

Developers need:

• admin is not a substitute for proper scoped roles
• Application-specific roles in scoped apps (x_app.user, x_app.admin)
• Least privilege for integration users (rest_api_user pattern)

gs.hasRole('itil') in scripts—know difference between hasRole and admin.

Cross-reference ITIL process language for incident roles (itil, sn_incident_write) in ITSM interviews.

GlideRecord is the server-side database API for CRUD and queries.

var gr = new GlideRecord('incident');
gr.addQuery('active', true);
gr.addQuery('priority', '1');
gr.setLimit(100);
gr.query();
while (gr.next()) {
    gs.info(gr.number + ' : ' + gr.short_description);
}

Best practices:

• addQuery / addEncodedQuery with indexed fields when possible
• setLimit on large tables
• get() for single record by sys_id
• chooseFields / getValue to reduce payload in integrations

Avoid: update() on every row in a loop when batch alternatives exist.

Classic N+1 pattern:

// Anti-pattern — one query per incident
while (incGr.next()) {
    var taskGr = new GlideRecord('task');
    taskGr.addQuery('parent', incGr.sys_id);
    taskGr.query();
    // ...
}

Better: one query, build a map in memory (same pattern as SQL JOIN or prefetch):

// Pattern validated in JavaScript — collect parents, query tasks once, group by parent
const parents = ['INC001', 'INC002'];
const tasks = [
  { parent: 'INC001', state: 'open' },
  { parent: 'INC001', state: 'closed' },
];
const openByParent = new Map();
for (const t of tasks) {
  if (t.state !== 'closed') {
    openByParent.set(t.parent, (openByParent.get(t.parent) || 0) + 1);
  }
}
// openByParent.get('INC001') === 1

On platform: GlideAggregate with groupBy, or encoded query with IN clause for parent sys_ids.

Interviewers want complexity awareness—O(n) queries vs O(1) query + O(n) memory.

GlideAggregate runs COUNT, SUM, AVG, MIN, MAX with groupBy—like SQL aggregation without pulling every row into a script.

Use cases:

• Count open P1 incidents per assignment group
• Dashboard KPI without full GlideRecord scan
• Validate batch job impact before update

Prefer aggregate queries over while (gr.next()) counting when datasets are large.

Tie to SQL interview questions when explaining GROUP BY analogies.

Topics interviewers ask:

• Auth — OAuth, basic, mutual TLS
• Table API — pagination, sysparm_fields, rate limits
• Scripted REST — custom endpoints, validation, error codes
• Idempotency — duplicate create on retries

Security: integration user with minimal roles; validate payload; never embed secrets in client scripts.

Compare with Salesforce REST patterns for enterprise integration vocabulary.

Import Sets stage flat data before loading into target tables.

Flow: load CSV → import set table → transform map → target table (incident, user, CI).

Interview points:

• Use for bulk migration and recurring feeds
• Transform scripts for field mapping logic
• Coalesce on unique key to avoid duplicates
• Run after ACL and business rules apply on insert

Alternative: Integration Hub / ETL for complex pipelines; REST for real-time.

• Workflow — legacy, editor in workflow canvas; maintain existing
• Flow Designer — modern automation, subflows, spokes, Integration Hub actions

New automation: Flow Designer unless organization standard says otherwise.

Flows excel at:

• Approvals and notifications
• Calling REST with built-in actions
• Readable handoff to process owners

Use Script Includes when flow script steps become unmaintainable JavaScript strings.

Know trigger types: record, schedule, inbound email, subflow.

Checklist seniors recite:

Use Performance Analytics / System Diagnostics / Slow query logs—not guesswork.

Scenario answer: “Form slow on load” → check display BRs, client scripts, related lists, ACL scripts.

Tools:

• Script Debugger — step through client/server scripts
• Background Scripts — ad hoc GlideRecord in subprod only
• System Logs — gs.info, gs.debug, application logs
• Session Debug — business rule execution trace
• Update Set preview — deployment conflicts

Process interviewers want:

1. Reproduce in subprod
2. Narrow layer (client vs server vs ACL vs integration)
3. Isolate with disable rule bisect (carefully)
4. Fix + ATF or manual test plan
5. Document in change record

Avoid editing production without change control—state that aloud in interviews.

When updating records from server scripts without touching audit metadata:

var gr = new GlideRecord('sys_user');
gr.addQuery('active', true);
gr.query();
while (gr.next()) {
    gr.setWorkflow(false);      // skip business rules and workflows
    gr.autoSysFields(false);    // skip sys_updated_on / sys_updated_by
    gr.language = 'en';
    gr.update();
}

Use sparingly—skipping workflows can bypass critical logic.

Interviewers ask when dangerous: mass updates without rules, data fixes with compliance risk.

Prefer official data repair patterns and change approval.

Update Sets capture metadata changes for movement between instances.

Captured: business rules, fields, ACLs, client scripts, etc.

Not captured (common trap):

• Data (rows in tables)
• Some plugin artifacts
• Scheduled jobs execution state
• Binary attachments in some flows
• Cross-scope dependencies without proper app export

Best practices:

• Consistent naming (FEATURE-123_short_desc)
• Complete before commit
• Preview on target before deploy
• Pair with application repository / CI for mature teams

Senior: mention Instance Scan and pipeline (Git + ATF) over manual US for prod.

1. Preview update set — review collisions
2. Skipped records — decide merge vs overwrite
3. Remote vs local version diff
4. Re-test business rules and ACLs on target
5. Rollback plan — backup US, reverse US, or restore subprod snapshot

Scenario: two developers edit same business rule—coordinate via scoped app source control, not email attachments.

Link Git interview prep if team uses Git integration with ServiceNow.

ATF runs automated UI and server tests on instance.

Developers use it for:

• Regression after update set deploy
• Critical flow (create incident, approve change)
• Server tests calling Script Includes

Not a replacement for code review or subprod manual QA—but expected in mature shops.

Interview line: “I add ATF for regression on custom app critical paths before production promote.”

CMDB — configuration items and relationships (servers, apps, services).

CSDM (Common Service Data Model) — how to structure CMDB for service mapping and ITOM.

Developer relevance:

• Incident/change reference CIs correctly
• Discovery and Service Mapping feed CMDB—custom tables should relate not duplicate
• Bad CI data breaks assignment, impact analysis, change risk

You may not build CMDB from scratch—but you should not break CI references in custom apps.

ITSM scenario questions often assume valid CI → assignment group routing.

Requirement: State cannot move to Resolved/Closed if open incident_task rows exist.

Strong design:

1. Before Update business rule on incident
2. Condition: state changing to resolved/closed
3. GlideRecord query on incident_task (or task) where parent = current.sys_id and state != closed
4. If rows exist → gs.addErrorMessage + current.setAbortAction(true)

Why not Client Script alone? REST/import/mobile bypass UI.

Why not After? Record already saved—race and audit noise.

Optional: Flow for notification after valid close.

This is a common developer scenario—practice walking through the flow from form click to database commit aloud.

Structured answer interviewers want:

1. Requirements — actors, records, lifecycle
2. Data model — tables, extensions, references, choice lists
3. Security — roles, ACLs, cross-scope
4. UI — forms, lists, workspace if applicable
5. Logic — Flow vs BR vs Script Includes
6. Integration — REST/spokes if needed
7. Testing — ATF, UAT scripts
8. Deployment — scoped app export, pipeline

Mention mobile/offline only if in scope.

Draw one ER diagram with scoped table prefix before deep-diving scripts.

Before Insert (or Before Update on create) business rule:

1. Read current.cmdb_ci
2. GlideRecord('cmdb_ci') → get CI sys_id
3. Set current.assignment_group from CI’s support_group (or custom field)
4. Optionally set assigned_to from on-call rotation via Script Include

Use before rule to avoid second update() on insert.

Edge cases interviewers add:

• CI missing support group → fallback group
• CI changes on existing incident → reassign?

Demonstrates GlideRecord get, dot-walking, and before timing.

Record producers and catalog items use variables (questionnaire) mapped to target table fields.

Developers should know:

• Catalog Client Scripts vs form Client Scripts
• UI Policies on catalog items
• Variable sets reuse
• Flow on requested item fulfillment

Anti-pattern: duplicate incident fields manually when catalog should drive standardized requests.

Common in employee onboarding and hardware request scenarios.

Now Assist and generative features can draft scripts, flows, and summaries—interviewers may ask how you validate output.

Strong developer stance:

• Treat AI output as first draft—review ACL impact, performance, upgrade safety
• Never paste elevated logic without security review
• Understand data residency and what content leaves instance
• Automation still needs testing (ATF) and change control

Platform fundamentals (scope, ACLs, GlideRecord cost) remain mandatory—AI does not replace execution-context knowledge.

Widget server script uses GlideRecord—same performance rules.

Interviewers may ask widget $scope and GlideAjax from portal.

Know which experience the role supports—portal-heavy CSM vs ITSM classic.

Jobs need mutual exclusion awareness—long jobs overlapping next run.

Chunk mass updates with setLimit + scheduleNext() pattern for huge tables.

Dot-walking traverses reference fields in queries: assignment_group.name, caller_id.email.

Works in encoded queries and GlideRecord addQuery.

Cost: each dot may add joins—slow on unindexed paths or huge tables.

Mitigation:

• Query on reference sys_id directly when possible
• Denormalize critical fields only when justified
• Use display values carefully in scripts vs queries

Related to SQL JOIN performance—see SQL interviews.

Domain separation partitions data (e.g., by company) on one instance.

Developers must:

• Set domain on records when required
• Test ACLs per domain
• Avoid global scripts that leak data across domains
• Understand domain pickers on forms

Enterprise interviews for MSP-style instances drill this—startup single-domain instances may skip.

Technical drills:

• Explain before / after / async with one incident scenario
• Draw GlideAjax flow (client → Script Include → response)
• Compare ACL vs UI Policy with security example
• Write N+1 fix strategy on whiteboard
• List update set limitations and preview workflow
• Walk scoped app design for one custom table app
• One REST integration auth and error-handling story

Cross-prep:

• Salesforce developer for CRM platform comparison
• Technical specialist for ITSM process empathy
• SQL interviews for reporting questions
• Git interviews if CI/CD with Git is in JD

Behavioral (STAR): One failed deployment or performance fire you debugged with logs, bisect, and permanent fix (ATF, rule merge, query index).

A strong close:

I lead with configuration-first design, enforce security on the server, and can walk any script choice back to execution context and upgrade impact—not a feature checklist from Trailhead alone.