ServiceNow Developer Interview Questions and Answers

What interviewers are testing: Whether you connect scoped development, server-side security, and upgrade-safe delivery to the business workflows the platform supports.

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 is:

A ServiceNow developer owns scoped applications, data models, client/server scripting, ACLs, flows, integrations, testing, and upgrade-safe delivery. I distinguish that from administrator-heavy platform configuration, although real enterprise roles often overlap.

What interviewers are testing: Whether you understand ServiceNow as a metadata-driven workflow/application platform and connect that model to scoped development, configuration-first choices, and upgrade safety.

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, Workflow Studio flows, 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 is:

ServiceNow is a metadata-driven workflow platform on one data model. I build scoped apps with configuration-first design and keep upgrades safe by avoiding unnecessary core-table customization.

What interviewers are testing: Whether you understand how Task inheritance affects fields, Business Rules, ACLs, and queries on child tables.

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.

A strong answer is:

Child tables extend parents like Incident extending Task, so fields, Business Rules, and ACLs can inherit. I use extensions for real IS A relationships and database views only for read-only unions.

What interviewers are testing: Whether you can explain namespaces, application ownership, cross-scope privileges, and why scoped development reduces coupling.

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

A strong answer is:

Scoped apps give namespace isolation, controlled APIs, and cleaner delivery. I keep tables and Script Includes in the owning scope and make cross-scope access explicit.

What interviewers are testing: Whether you choose the least-custom platform mechanism that satisfies the requirement instead of scripting every problem.

Platform-first decision tree:

Say aloud: "I'd start with OOB—UI Policy or a Workflow Studio flow—because it's upgrade-friendly and visible to admins."

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

A strong answer is:

I start with the least-custom platform mechanism—UI Policy, Data Policy, or Workflow Studio flow—before scripting. Code is for transaction rules, integrations, or batch logic configuration cannot express.

What interviewers are testing: Whether you know browser execution context, supported form events, and why client-side behavior is UX rather than security.

Client Scripts run in the user's browser and primarily affect forms; onCellEdit() handles list-cell edits. They are not security controls.

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

A strong answer is:

Client Scripts run in the user's browser and primarily affect forms; onCellEdit() handles list-cell edits. They improve UX but must not be relied on for security or authoritative data validation.

What interviewers are testing: Whether you default to UI Policy for simple form behavior and reserve Client Scripts for logic UI Policy cannot express.

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).

A strong answer is:

I default to UI Policy for visibility and mandatory fields. I use Client Scripts only when UI Policy cannot express dynamic reference filtering, GlideAjax calls, or richer UX.

What interviewers are testing: Whether you know how client code calls server logic asynchronously without using browser-side database logic as the default design.

Do not treat client-side GlideRecord as the normal way to query platform data. ServiceNow has exposed restricted client-side GlideRecord capabilities in some contexts, but it is limited and discouraged compared with server-side logic. Use GlideAjax to call a client-callable Script Include when a form needs server data, keeping authoritative data access and logic on the server.

Flow:

1. Client Script creates GlideAjax('ScriptIncludeName')
2. addParam('sysparm_name', 'methodName') + parameters
3. getXMLAnswer(callback) — asynchronous
4. Client-callable Script Include (commonly extending global.AbstractAjaxProcessor or the scoped equivalent) runs server-side Glide APIs and returns the answer

Architecture:

Client Script
   ↓ GlideAjax
Client-callable Script Include
   ↓
server-side Glide APIs / logic
   ↓ callback / answer

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 is:

I use GlideAjax when client-side logic needs server data. The client calls a client-callable Script Include asynchronously, which keeps database access and authoritative logic on the server without freezing the form.

What interviewers are testing: whether you demonstrate solid command of Security enforcement—the trap is textbook recall without production context.

• 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.

A strong answer is:

I never use Client Scripts for authorization or final validation. ACLs and before Business Rules enforce security and integrity across form, API, and import paths.

What interviewers are testing: Whether you can choose before/after/async/display based on transaction timing, data consistency, and user latency.

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
• Use conditions, keep rules small, and move reusable logic to Script Includes
• Avoid current.update() recursion
• Async Business Rules do not have reliable previous data for sequencing-sensitive logic, so use synchronous after rules when the previous state or order matters
• Minimize rule count—overlapping rules are hard to debug

A strong answer is:

Business Rules are server-side hooks on table operations. I use before for validation and current mutation, after for related records, and async only when ordering and previous values are not required.

What interviewers are testing: whether you state clear distinctions and when each option applies—not interchangeable buzzwords.

Before example — abort invalid transition:

If state changes to the application's configured Resolved/Closed state
and open child tasks exist:
    add an error message
    abort the action

Use the application's defined state values or a Script Include helper—do not hard-code magic state numbers in reusable logic.

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.

A strong answer is:

Before rules validate or mutate current in the same transaction; after rules handle related records and events synchronously; async rules are for work where sequencing and previous values are not required.

What interviewers are testing: Whether you can distinguish Business Rules, Script Includes, and Workflow Studio flows for record lifecycle vs reusable server logic vs process automation.

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

For new process automation, prefer Workflow Studio flows/subflows rather than legacy Workflow Editor. Workflow Studio is the default current builder and receives new features; legacy Workflow Editor is for maintaining existing estates.

A strong answer is:

I use Workflow Studio flows for approvals and integrations, Business Rules for tight record lifecycle logic, and Script Includes for reusable server code shared by both.

What interviewers are testing: whether you follow a practical ordered approach with the right tools—not a vague tool list.

Practices interviewers reward:

• Single responsibility — one class per domain (IncidentTaskValidator)
• Client callable only when needed (AbstractAjaxProcessor)
• Expose only the methods other scripts need; keep implementation helpers internal by convention/structure and restrict client-callable access to explicitly intended methods
• 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).

A strong answer is:

I keep Script Includes single-purpose, expose only methods other scripts need, mark client-callable includes explicitly, and centralize GlideRecord logic so Business Rules stay small.

What interviewers are testing: whether you define current, previous, and g_scratchpad and connect it to current in production—not textbook definitions only.

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.

A strong answer is:

current is the record in the transaction, previous contains its prior values, and g_scratchpad passes display Business Rule data to client scripts. I use current.field.changes() or changesTo() and compare with previous when I need the old value.

What interviewers are testing: whether you demonstrate solid command of Events—the trap is textbook recall without production context.

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.

A strong answer is:

I use events to decouple listeners from a record change—queue the event from a Business Rule, then let Script Actions, notifications, or flows react without blocking the save.

What interviewers are testing: Whether you understand table/field ACL inheritance, current rule semantics, and the difference between UI visibility and server authorization.

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)

Access is determined by the set of matching ACLs for the requested table/field/operation. The user must satisfy the applicable ACL logic; current releases also support Allow-If and Deny-Unless semantics. Parent-table ACLs can apply to child tables through inheritance.

security_admin role required to edit ACLs—often with elevation.

Interview must-know: ACLs are server-side security and protect normal user/API access, including REST. Do not assume every privileged server-side script automatically enforces end-user ACLs; when scripts run on behalf of a user, choose ACL-aware APIs/checks intentionally. Ordinary server-side GlideRecord does not automatically provide the same user ACL enforcement semantics as a user-facing REST/UI request — use GlideRecordSecure or explicit access checks when script behavior must respect the current user's ACLs.

Senior note: Scripted REST resources can also use path-based ACLs to match access by REST resource path.

A strong answer is:

ACLs enforce server-side access. I debug them with ACL debugging/Watcher tools, verify inherited table and field rules, and use GlideRecordSecure or explicit access checks when server-side code must honor the current user's ACLs.

What interviewers are testing: whether you state clear distinctions and when each option applies—not interchangeable buzzwords.

“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.

A strong answer is:

ACLs authorize access, UI Policies shape form UX, and Data Policies enforce mandatory/read-only behavior beyond normal form UI where configured. I never rely on client-side hide for compliance.

What interviewers are testing: whether you know when to reach for this and the failure modes when you pick the wrong approach.

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

Cautions interviewers expect:

• Performance — scripted ACLs are evaluated during access checks and can become expensive when they perform queries or complex logic across high-volume list/API 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.

A strong answer is:

I use scripted ACLs only when roles alone cannot express owner or assignment-group logic, keep scripts simple, and avoid database queries in ACL evaluation.

What interviewers are testing: whether you demonstrate solid command of roles to groups—the trap is textbook recall without production context.

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)
• Create a dedicated integration account/service identity with only the application/table/API roles required for that integration; do not grant admin merely to make REST work

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.

A strong answer is:

I assign roles to groups, use application-specific scoped roles, and create dedicated integration identities with only the table/API access that integration needs.

What interviewers are testing: Whether you can write bounded/index-aware server queries and avoid N+1/database-in-loop patterns.

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:

• Retrieve only records you actually need
• addQuery / addEncodedQuery with indexed fields when possible
• setLimit on large tables
• get() for single record by sys_id
• Avoid unnecessary dot-walking and query-in-loop patterns
• Use GlideAggregate for counts and aggregates

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

A strong answer is:

GlideRecord is the server database API. I filter on indexed fields, set limits, use get() for one record, and prefer aggregates or batched queries over query-in-loop patterns.

What interviewers are testing: whether you know when to reach for this and the failure modes when you pick the wrong approach.

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.

N+1 performs one database query per parent record. Prefer batching the IDs into one/few queries or using GlideAggregate/grouping, then process the results in memory.

A strong answer is:

N+1 performs one database query per parent record. I batch parent IDs into one or few queries, or use GlideAggregate/grouping, then process results in memory.

What interviewers are testing: whether you define GlideAggregate used for and connect it to COUNT, SUM, AVG, MIN, MAX in production—not textbook definitions only.

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.

A strong answer is:

GlideAggregate lets me count or sum in the database with groupBy instead of loading every row into a script—similar to SQL GROUP BY for KPIs and batch validation.

What interviewers are testing: whether you demonstrate solid command of Inbound—the trap is textbook recall without production context.

Topics interviewers ask:

• Auth — prefer OAuth/token-based authentication or mTLS where appropriate; Basic auth may exist in older/simple integrations but should not be the default design recommendation
• 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.

A strong answer is:

Inbound REST exposes Table API or Scripted REST to external callers; outbound REST uses REST Messages or flow actions. I prefer OAuth or mTLS where appropriate and give integration users least-privilege roles.

What interviewers are testing: whether you know when to reach for this and the failure modes when you pick the wrong approach.

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 determines whether the transform inserts or matches/updates an existing target record; it is not itself a general uniqueness guarantee for every write path
• During a transform, coalesce controls match/update behavior and transform settings/scripts control how data is written. Business Rules may run depending on transform configuration; do not assume UI/client behavior or end-user ACL execution is identical to interactive record creation

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

A strong answer is:

Import Sets stage bulk data, Transform Maps map it to target tables, and coalesce controls insert vs update. I do not assume UI or end-user ACL behavior matches interactive record creation.

What interviewers are testing: Whether you know the current automation stack and can distinguish modern Workflow Studio flows from legacy Workflow Editor estates.

• Legacy Workflow Editor — existing-estate knowledge. As of Zurich, new customers no longer receive ServiceNow-provided legacy workflows; new automation should be built in Workflow Studio.
• Workflow Studio — current default process-automation builder consolidating flows, subflows, actions, playbooks, decision tables, and integrations (Flow Designer is the flow-building experience within it).

For new process automation, prefer Workflow Studio flows/subflows rather than legacy Workflow Editor.

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 common trigger categories such as record, scheduled, Service Catalog, and application-specific triggers; available triggers depend on installed applications and integrations.

A strong answer is:

For new automation I build Workflow Studio flows and subflows. Legacy Workflow Editor is existing-estate knowledge—Zurich stopped providing legacy workflows to new customers.

What interviewers are testing: Whether you diagnose slowness using transaction/query/script evidence rather than adding indexes or disabling rules blindly.

Checklist seniors recite:

Use System Diagnostics, Stats Tools, Slow Queries/Slow Scripts/Slow Transactions, transaction logs, and call-chain data rather than guessing.

A strong answer is:

I diagnose slowness with System Diagnostics, Stats Tools, Slow Queries/Slow Scripts/Slow Transactions, and transaction logs—not guesswork or blind rule disabling.

What interviewers are testing: Whether you isolate client, server, ACL, flow, query, and integration layers using the correct debugging tool for each execution context.

Tools:

• Script Debugger — step through synchronous server-side scripts in interactive transactions (Business Rules, Script Includes, Script Actions, UI Actions)
• Browser developer tools / client logs — debug Client Scripts
• Session Log / Session Debug — trace server-side execution
• Scripts - Background — controlled ad hoc server-side testing in subproduction (no breakpoints in the script field itself)
• Update Set preview — deployment conflicts

Process interviewers want:

1. Reproduce in subprod
2. Narrow layer (client vs server vs ACL vs integration)
3. Use execution/debug logs and targeted conditions first; if controlled isolation requires disabling an artifact, do it only in subproduction with clear rollback and dependency awareness
4. Fix + ATF or manual test plan
5. Document in change record

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

A strong answer is:

I reproduce in subproduction, isolate client vs server vs ACL vs flow vs integration, use Script Debugger for synchronous server scripts and browser tools for Client Scripts, then fix with a regression test plan.

What interviewers are testing: whether you demonstrate solid command of bypass critical logic—the trap is textbook recall without production context.

For controlled data-repair scripts, ServiceNow provides APIs that can suppress workflow/business-rule processing and automatic system-field updates:

var gr = new GlideRecord('sys_user');
gr.addQuery('active', true);
gr.query();
while (gr.next()) {
    gr.setWorkflow(false);      // suppress workflow/BR processing associated with this GlideRecord operation where applicable
    gr.autoSysFields(false);    // prevent automatic sys_updated_on / sys_updated_by updates
    gr.language = 'en';
    gr.update();
}

Use sparingly—setWorkflow(false) should not be treated as a universal "disable all automation" switch, and 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.

A strong answer is:

setWorkflow(false) suppresses workflow/business-rule processing associated with the GlideRecord operation where that API applies; autoSysFields(false) skips automatic sys_updated_on/sys_updated_by updates. I use both sparingly in approved data-repair work.

What interviewers are testing: Whether you know what configuration is captured, what data is not, how preview/conflict resolution works, and when scoped-app deployment tooling is preferable.

Update Sets capture metadata changes for movement between instances.

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

Not the normal purpose:

• Incident/request/task records and other business data
• Users/groups as business data
• CMDB data
• Test transactions/orders
• Bulk application data

Update Sets primarily capture configuration/customization records; what is tracked depends on table update-sync behavior or special handlers. Do not casually mix Update Sets and Application Repository deployment for the same scoped app—ServiceNow warns this can produce skipped changes and commit issues.

Best practices:

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

Mature teams automate validation and promotion with source control/application repository/pipeline tooling plus ATF/Instance Scan as appropriate, rather than relying on unreviewed manual update-set movement.

A strong answer is:

Update Sets capture configuration such as rules, ACLs, and dictionary metadata—not normal business data. Mature teams automate validation and promotion with source control, App Repo, and ATF rather than unreviewed manual movement.

What interviewers are testing: whether you follow a practical ordered approach with the right tools—not a vague tool list.

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 — back out/revert captured customization where supported, redeploy a known-good application version, or apply a tested corrective update; validate rollback in subproduction before production deployment

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.

A strong answer is:

I preview update sets, resolve skipped or conflicting records deliberately, retest ACLs and rules on the target, and validate rollback in subproduction before production deployment.

What interviewers are testing: Whether you know ATF is for platform regression in non-production and does not replace code review or careful production execution.

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

Run regression suites in non-production before promotion; production use must be carefully controlled because tests can create/update records and execute workflows. ATF complements code review and unit-level design—it is not a substitute for either.

A strong answer is:

I run ATF regression on critical custom-app paths in non-production before promotion, because tests can create records and trigger flows and should not be treated as a replacement for code review.

What interviewers are testing: whether you demonstrate solid command of CMDB—the trap is textbook recall without production context.

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.

A strong answer is:

CMDB stores configuration items and relationships; CSDM defines how to structure that data for service mapping. I keep CI references valid so assignment, impact, and change-risk logic works.

What interviewers are testing: Whether you choose a before rule/server validation so the invariant holds across form, API, and integration writes.

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 active/open using a meaningful lifecycle condition—for example active=true if that matches the table
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.

A strong answer is:

I use a before Update Business Rule on incident that checks for open child tasks when state moves to resolved/closed, then addErrorMessage and setAbortAction so REST and imports cannot bypass the rule.

What interviewers are testing: Whether you can design a scoped app end to end—data model, security, UI, automation, testing, and deployment—not only individual scripts.

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.

A strong answer is:

I start with scoped requirements, data model, roles and ACLs, UI, Workflow Studio vs server logic, integrations, ATF, and app-repository deployment—not ad hoc global customization.

What interviewers are testing: Whether you can set assignment defaults in a before rule using reference data efficiently without unnecessary extra queries.

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

1. Read current.cmdb_ci reference
2. Dot-walk or load the CI once if multiple attributes are needed
3. Set current.assignment_group from the 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.

A strong answer is:

On insert I set assignment_group from the referenced CI's support group in a before rule, using the reference directly when possible and loading the CI once only if multiple attributes are needed.

What interviewers are testing: whether you state clear distinctions and when each option applies—not interchangeable buzzwords.

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.

A strong answer is:

Catalog variables collect requester input and map to target table fields. I reuse variable sets, use catalog client scripts only where needed, and let flows handle fulfillment.

What interviewers are testing: Whether you treat generated scripts/flows as untrusted drafts that still require platform-security, performance, and regression review.

Now Assist/AI tooling can assist with platform authoring and workflow generation where those capabilities are licensed and enabled. Interviewers may ask how you validate generated 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.

A strong answer is:

Now Assist can draft scripts or flows where licensed, but I treat generated artifacts as untrusted until reviewed for ACL impact, performance, scope, testing, and change control.

What interviewers are testing: whether you state clear distinctions and when each option applies—not interchangeable buzzwords.

Widget server script uses GlideRecord—same performance rules.

Interviewers may ask widget $scope and GlideAjax from portal.

Know which user experience the target role supports—Classic UI, Service Portal/Employee Center, or configurable workspaces.

A strong answer is:

Classic UI uses form Client Scripts and UI Policies; Service Portal uses widgets; configurable workspaces use Next Experience/UI Builder. I confirm which experience the role supports before designing extensions.

What interviewers are testing: whether you state clear distinctions and when each option applies—not interchangeable buzzwords.

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

Chunk large updates into bounded batches, persist progress/checkpoints, and schedule subsequent batches using documented scheduled-job or flow mechanisms rather than one long transaction.

A strong answer is:

Events react to record changes; scheduled jobs and scheduled flows handle time-based batch work. For large updates I process bounded batches and schedule subsequent batches with documented job or flow mechanisms.

What interviewers are testing: whether you define dot-walking and when is it expensive and connect it to reference fields in production—not textbook definitions only.

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

Works in encoded queries and GlideRecord addQuery.

Dot-walking across reference fields can make queries and display retrieval more expensive, especially across large tables or poorly selective conditions.

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.

A strong answer is:

Dot-walking across reference fields can make queries and display retrieval expensive on large tables. I query by sys_id or reference fields directly when practical and validate with slow-query diagnostics.

What interviewers are testing: whether you define domain separation and developer impact and connect it to Domain separation in production—not textbook definitions only.

Domain Separation provides logical data and process separation within one instance for supported applications and use cases.

Developers must understand domain visibility, inheritance, ACL/query behavior, and whether custom tables and scripts are domain-aware—not simply "set domain field on records."

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

A strong answer is:

Domain Separation provides logical data and process separation within one instance. I test domain visibility, inheritance, ACL/query behavior, and whether custom tables and scripts are domain-aware.

What interviewers are testing: whether you state clear distinctions and when each option applies—not interchangeable buzzwords.

Use GlideRecord for trusted server automation running with appropriate elevated context. Use GlideRecordSecure — or explicit access checks — when script behavior must respect the current user's ACLs.

A strong answer is:

GlideRecord is the default server database API; GlideRecordSecure is what I reach for when user-facing security must be enforced inside server script logic.