ServiceNow: interview questions and learning guide

Incident Management

Like a fire brigade: first put out the fire, investigate the cause later.

An incident is an unplanned interruption or drop in the quality of an IT service. The goal is to restore service quickly. Priority is worked out from impact (how many people or services are affected) and urgency (how fast it must be fixed). SLAs track how quickly you respond and resolve.

Interview tip: Restore first, investigate later.

Problem Management

A leaking pipe: wiping the floor every day is incident work. Fixing the pipe is problem work.

Problem management finds and removes the root cause of repeated incidents. A problem record links related incidents. Until a fix exists, a workaround keeps users working. A known error records the cause and the workaround.

Interview tip: Incident = restore. Problem = prevent.

Change Management

Like air traffic control: a plane cannot take off without a plan and clearance.

Change management controls changes to live services to reduce risk. Standard changes are pre-approved and low risk. Normal changes need assessment and approval, often by a CAB. Emergency changes are urgent fixes with fast approval.

Interview tip: Always ask: what is the risk, and how do we roll back?

CMDB

Like a family tree for your IT: who depends on whom.

The CMDB stores configuration items (CIs) such as servers, applications and databases, and the relationships between them. Knowing the relationships shows what a failure will affect. It is only useful if the data stays accurate, so discovery and ownership matter.

Interview tip: No relationships, no impact view.

Service Catalog

Like a restaurant menu for IT services.

The service catalog lets users request things such as a laptop or software access. Each catalog item can have variables that collect details, and a flow that fulfils the request. Order guides bundle several items into one request.

Interview tip: Menu item = catalog item. Details you fill in = variables.

Business Rules

Like an automatic door sensor that reacts whenever something happens to a record.

A Business Rule is server-side logic that runs when a record is inserted, updated, deleted or queried. A 'before' rule runs before the record is saved, so it can change field values. An 'after' rule runs once the record is saved. Async rules run in the background so users do not wait.

Interview tip: Before = change the record. After = react to it.

GlideRecord

Like asking a librarian to find every book on a shelf, then reading them one by one.

GlideRecord is a server-side scripting class used to query and change records in a table. You build the query, call query() to run it, then loop with next() to read each row. Call update() to save changes. Avoid queries inside loops for performance.

Interview tip: addQuery sets the question, query() asks it, next() reads each answer.

Client Scripts vs UI Policies

UI Policies are simple house rules. Client Scripts are a custom helper for tricky cases.

Both run in the browser on forms. UI Policies handle common needs such as making a field mandatory, visible or read-only, with conditions and little code. Client Scripts handle logic UI Policies cannot, such as onChange or onSubmit validation.

Interview tip: Try a UI Policy first. Use a Client Script for custom logic.

Script Includes

A toolbox you build once and borrow from anywhere.

A Script Include stores reusable server-side code, often as a class with functions. Business Rules or flows call it so you avoid copy-paste. A client-callable one can be used from the browser through GlideAjax.

Interview tip: If you copy code twice, make it a Script Include.

Flow Designer

Like a recipe card: when X happens, follow these steps automatically.

Flow Designer builds automation with little or no code. A flow has a trigger, then actions, with conditions and approvals. Subflows are reusable pieces you can call from many flows. Always add error handling and test with real data.

Interview tip: Trigger first, then actions, then test with real data.

REST Integration

Like ordering through a waiter: you send a request and get a response with a status.

REST integrations let systems exchange data over HTTP. GET reads, POST creates, PUT or PATCH updates and DELETE removes. Status codes show the result: 2xx means success, 401 means not authenticated and 404 means not found. Always plan for authentication, errors and retries.

Interview tip: 2xx good, 4xx you asked wrong, 5xx the server failed.

Access Control (ACLs)

A security guard checking your badge at each door.

ACLs decide who can read, write, create or delete records and fields. An ACL checks roles, conditions and sometimes a script. Access is granted only when the checks pass. Follow least privilege: give only the access that is needed.

Interview tip: Least privilege: give only the access that is needed.

Users, Groups and Roles

Think of roles as keys, groups as key rings, and users as the people who carry them.

Every person in ServiceNow is a user record. Users are placed in groups, such as a support team. Roles give access to features and data. A role can be given to a user directly, or to a group so every member inherits it. Good admins give roles to groups, not to people, because it is easier to audit and change.

Interview tip: Say that you assign roles to groups and keep user records clean, because interviewers want to hear about scalable access.

Lists, Forms and UI Configuration

Lists and forms are the shop window of ServiceNow, and the admin decides what each visitor sees.

A list shows many records in rows. A form shows one record. Admins use Form Layout or Form Designer to add fields, sections and related lists. Views let different audiences see different layouts of the same table. Changes to layout are saved as records, so they can be moved by update set. Keep forms short, because too many fields slow users down.

Interview tip: Explain that you configure forms for each audience with views instead of crowding one form with every field.

Tables, Dictionary and Data Policies

A table is a spreadsheet, the dictionary is the rulebook for every column, and a data policy is the guard on the door.

Every record lives in a table. A table can extend another table and inherit its columns, like incident extending task. The dictionary stores the definition of each column, such as type, length and default. Data policies make fields mandatory or read-only no matter how data enters, including imports and web services. UI policies only act on the form.

Interview tip: Remember the difference: data policy works on all entry points, UI policy works only in the browser form.

Update Sets and Moving Changes

An update set is a shipping box that records every configuration change so you can carry it to the next instance.

When you configure an instance, changes are captured in the current update set. You then export or retrieve that set on the target instance, preview it, fix any problems, and commit it. Data such as incident records is not captured. Always keep one update set per feature, with a clear name, and move them in order so nothing breaks.

Interview tip: Say you preview every set before committing and never leave work in the Default set.

Notifications and Email

A notification is a postman that waits for an event and then delivers the right message to the right people.

Notifications send email when something happens, such as a record being created or updated. The admin sets when it fires, who receives it, and what the message says. Many notifications are triggered by events. Inbound email actions can also turn incoming mail into records. Always test with a small group first so you do not flood real users.

Interview tip: Mention that you check the email log and notification preferences when someone says they never got an email.

SLAs, Assignment and Task Management

SLAs are the stopwatch on every ticket, and assignment rules decide who picks up the stopwatch.

The task table is the parent of incident, problem, change and request. This means they share fields like state, assigned to and priority. An SLA definition starts a timer when a condition is met and tracks it against a duration. Assignment rules and data lookups route work to the right group automatically. Schedules decide when the clock runs.

Interview tip: Show that you know the SLA stages: start, pause, stop and breach, and that schedule choice changes the result.

Import Sets and Transform Maps

An import set is a loading dock: data arrives in a staging area first, then a map moves it to the real shelf.

Data is loaded from a file or database into a staging table called an import set table. A transform map then moves each row into the target table. Field maps say which source column goes to which target field. Coalesce marks a field as a match key, so existing records are updated rather than duplicated. Always test with a few rows first.

Interview tip: Explain coalesce clearly, because duplicate records are the most common import failure.

Reports and Dashboards

A report is one chart that answers one question, and a dashboard is the wall where the charts live together.

Reports read data from a table and show it as a list, bar, pie, trend or pivot. Dashboards place many reports on one page for a team. Access depends on who the report is shared with and on the data access rules of the table. Scheduled reports send results by email. Performance analytics adds time series so you can see trends over weeks and months.

Interview tip: State that reports respect table security, so a person may see a chart but not the rows behind it.

Knowledge Management

Knowledge articles are the shared notebook of the company, so the same problem is solved once.

A knowledge base holds articles on one subject. Each article goes through states like draft, review and published. User criteria decide who can read or contribute. Good articles are short and linked to tickets, so agents can attach them while resolving. Feedback and view counts show which articles help and which are stale and should be retired.

Interview tip: Link knowledge to deflection: a good article stops future tickets, which is the real value.

Scheduled Jobs, Events and Instance Maintenance

The instance is a building, and scheduled jobs and maintenance are the caretakers who work at night.

Scheduled jobs run scripts or reports at set times. Events are signals that other parts, like notifications, listen for. Admins watch system logs and the event log to find problems. A clone copies one instance over another, often production into test, so teams test with real-looking data. Upgrades bring new platform code, and admins review skipped changes afterwards.

Interview tip: Say that after a clone you must reset email, integrations and scheduled jobs so test never talks to real systems.

GlideSystem and GlideDateTime

GlideSystem is the toolbox on the server wall, and GlideDateTime is its clock.

GlideSystem (gs) gives server scripts quick helpers for the current user, logging, messages, properties and dates. GlideDateTime holds a date and time value and lets you add days, compare values and convert time zones. Dates in the database are stored in UTC, so always think about the user's time zone before you show or compare a value. Use gs for small helper jobs and GlideRecord for table work.

Interview tip: Say that stored dates are UTC and display values follow the user's time zone, because many date bugs come from mixing them.

GlideAjax client-server calls

GlideAjax is a phone line from the browser to the server that does not freeze the screen.

A client script cannot read most tables directly, and a synchronous call would freeze the form. GlideAjax solves this by calling a client callable Script Include in the background. The client sets a method name and parameters, sends the call and gets an answer in a callback. The server class extends AbstractAjaxProcessor and reads the parameters with getParameter. Always use the async form with a callback.

Interview tip: Explain why async with a callback is preferred and name the three pieces: client script, GlideAjax object, client callable Script Include.

Client-side scripting APIs

The form in the browser has a remote control, and g_form holds the buttons.

Client-side scripts run in the browser while the user fills a form. The g_form object reads and changes fields: set values, hide fields, make them mandatory or read only. The g_user object tells you who the user is and which roles they have. Client script types are onLoad, onChange, onSubmit and onCellEdit. Keep these scripts small, because they slow the form and anyone can bypass them, so real rules need server checks too.

Interview tip: Say that client scripts are for user experience and never for security, then name the server-side backup such as an ACL or data policy.

Scoped applications and app development

A scoped app is a private room with its own door, so your work cannot clash with others.

A scoped application keeps its tables, scripts and settings under its own scope name, so they do not collide with other apps. By default other scopes cannot touch your data, so you must open access with cross scope settings or application access rules. Build in Studio or the app development tools, keep the work inside one app and move it between instances by publishing to a repository or exporting. Scoped code can use only the scoped version of the APIs.

Interview tip: Explain why you chose scoped over global: isolation, easy packaging, safer upgrades.

Scripted REST APIs and integration patterns

A Scripted REST API is your own front desk, with the rules for who enters and what they get back.

Scripted REST lets you publish your own endpoints so other systems can call ServiceNow. You define a service, add resources with an HTTP method and path, and write a script that reads the request and builds the response. For calls going out, a REST Message record stores the endpoint and authentication and a script uses RESTMessageV2 to send. Choose auth such as basic, OAuth or API key to match the partner's needs, handle errors with proper status codes and keep payloads small.

Interview tip: Mention auth, input validation, status codes and retries in the same answer, since interviewers listen for all four.

UI Builder and Workspace basics

UI Builder is a Lego table for web pages: you snap components together and wire their data.

UI Builder is the modern tool for building pages in ServiceNow workspaces. You make a page, drop components onto it, and connect each component to data using data resources. Events and handlers let one component react to another, for example a list click that opens a record. Workspaces use these pages to give agents one screen for lists, records and actions. Use client state parameters to pass values between components.

Interview tip: Contrast it with Service Portal in one line: UI Builder is the newer component and data driven way to build experiences.

Flow Designer actions, subflows and Integration Hub

Flow Designer is a recipe card, and a custom action is a new step you can add to every recipe.

Flow Designer builds automation from a trigger plus actions. A custom action packs a script or steps into a reusable block with inputs and outputs. A subflow is a smaller flow that other flows call, which avoids copying logic. Integration Hub adds spokes, which are ready sets of actions for outside tools, and a way to call REST or other connections without code. Plan inputs, outputs and error paths so each piece is easy to test.

Interview tip: Say when you would write a script step and when a built-in action is better: use built-in first for easy upgrades.

Automated Test Framework

ATF is a robot tester that clicks through your instance and tells you what broke.

The Automated Test Framework lets you build tests inside ServiceNow with no outside tool. A test is a list of steps such as impersonate a user, open a form, set field values, submit and assert the result. Tests are grouped in suites and can be run before an upgrade or after a deployment. Good tests use their own test data, clean up after themselves and check outcomes you care about, not every field.

Interview tip: Link ATF to release safety: it catches regressions before users do and speeds up upgrades.

Debugging, logging and script performance

Debugging is detective work, and good logs are the fingerprints you left on purpose.

When a script misbehaves, first reproduce the problem, then read the facts. Use gs.info, gs.warn and gs.error to write to the system log, and gs.debug for detail you can switch on. The Script Debugger lets you pause and step through server code. Session debug options show which rules ran and their order. For speed, keep queries narrow, avoid loops that query inside loops, add limits and use GlideAggregate for counts.

Interview tip: Show a method: reproduce, log, narrow down, fix, retest, and clean up your logs.

Service Portal widgets

A widget is a small shop in the portal street with a kitchen at the back and a counter at the front.

Service Portal pages are built from widgets. Each widget has three parts: an HTML template for the layout, a client controller for browser behavior and a server script that reads data and fills an object called data. The client controller can call the server through the c.server methods. Widgets can take options so one widget serves many pages. Keep the server script light and think about who is allowed to see the data.

Interview tip: Name the three parts and the data object, then mention that widgets must respect ACLs and be reusable through options.

A Business Rule runs on the server when records are queried, inserted, updated or deleted. A Client Script runs in the user's browser on form events such as load, change or submit.

A UI Action adds a button, link or context menu item on a form or list and can run client or server script when clicked.

onChange runs when a field value changes. onSubmit runs when the form is saved or submitted and can stop the save by returning false.

An Update Set records customizations made in a scope so they can be moved to another instance. It tracks changes to configuration records, not business data.

A scope isolates an application's tables and scripts from others, avoids name clashes and controls cross-scope access.

current is the record being processed with its new values. previous holds the values before the update, useful for detecting changes.

Avoid calling update on current in an after rule without conditions, use setWorkflow(false) carefully, and add conditions so the rule does not retrigger itself.

GlideAggregate runs grouped queries such as count, sum and average in the database, which is faster than looping through records with GlideRecord.

addQuery builds conditions one at a time in code. addEncodedQuery takes a query string copied from a list filter and is faster to write for long conditions.

It changes a field's properties, such as default value or mandatory, on an extended table without changing the parent table.

A child table inherits fields and behaviour from a parent table. For example Incident extends Task so it shares fields like number and assigned to.

A reference field points to one record in another table. A list field stores several references in one field.

ServiceNow checks table and field ACLs together. Both must pass, and each ACL needs role, condition and script checks to be true.

It separates data, processes and administration between domains in one instance so different customers or business units cannot see each other's data.

A Scheduled Job runs a script at set times, such as nightly cleanup or reports, without a user action.

An event is a signal fired by script or rule. A notification or script action can listen to the event to send emails or run logic.

Check that the notification is active, the condition matches, the recipients exist, the email is not blocked and the outbound email is working.

It processes incoming emails and can create or update records, such as turning an email into an incident.

An Import Set stages incoming data in a staging table. A Transform Map maps those staging fields to target table fields.

A MID Server is a Java application in the customer network that lets the instance communicate with internal systems for discovery and integrations.

Discovery scans the network to find devices and software and creates or updates CIs with their relationships in the CMDB.

The Common Service Data Model is a framework for modelling services, applications and infrastructure consistently in the CMDB.

Service Portal is the user friendly web front end. Widgets are its building blocks, with HTML, CSS, client and server scripts.

A Catalog Client Script works on catalog item forms and variables, while a normal Client Script works on table forms.

A record producer is a catalog item that creates a record in a table such as an incident from user answers.

Set platform standards, use out-of-the-box first, review each customisation in a design board, track technical debt, and use scopes and update set rules.

Review release notes, clone to a test instance, run ATF and regression, fix skipped changes, plan freeze and communication, then upgrade with rollback readiness.

Index tables, avoid heavy synchronous scripts, use GlideAggregate and async rules, archive old data, and monitor slow transactions.

Set coding standards, use code reviews, share a backlog, pair juniors, track quality and delivery, and align work to business outcomes.

Compare fit, cost, support, upgrade impact and security. Buy when it covers most needs, build when the process is unique and valuable.

Use least privilege integration users, OAuth, ACLs, encryption, audit logs, regular reviews and data classification.

Pick metrics like resolution time, ticket deflection, SLA and cost per ticket, report trends before and after, and tell the story in plain language.