Question 1

What is ServiceNow, and what do people mean by the Now Platform and its "single data model"?

Accepted Answer

ServiceNow is a cloud platform for digital workflows. It started with IT Service Management, but today it runs HR, customer service, security operations, asset management and custom apps, all on one underlying platform, which ServiceNow markets as the Now Platform (recent docs call it the ServiceNow AI Platform).

Every customer gets their own instance: a dedicated application and database stack reached at a URL like company.service-now.com. Typically you have separate dev, test and prod instances.

The single data model means every app shares the same database, tables and services: users, groups, the CMDB, the Task table, workflows, notifications, reporting and security. So an incident, an HR case and a change can all point at the same user and the same CI, and one ACL model, one flow engine and one reporting engine work across all of them. That avoids integrating a dozen separate tools.

Question 2

What are the types of business rules (before, after, async, display), and when would you use each?

Accepted Answer

A business rule is a server-side script that runs when a record is displayed, inserted, updated, deleted or queried. The When field decides the timing:

before: after the user submits but before the database write. Use it to validate data or set fields on current; changes save automatically, no update() needed. Can abort with current.setAbortAction(true).
after: after the database write. Use it to update related records, such as child tasks, because the current record is already saved.
async: runs later, in the background, as a scheduled job. Use it for slow work like integrations or heavy recalculation, so the user isn't waiting. previous isn't available.
display: runs when a form is loaded, before it reaches the browser. Mainly used to fill g_scratchpad with server data for client scripts.

There is also the Query operation, normally paired with before, which adds conditions to every query on the table, for example to hide records.

Question 3

What types of client scripts are there, and what parameters does an onChange script receive?

Accepted Answer

Client scripts run JavaScript in the browser on forms. There are four types:

onLoad: when the form first renders, before the user can type. Good for setting defaults or hiding fields.
onChange: when a specific field's value changes. It receives control, oldValue (the value when the record loaded), newValue, isLoading and isTemplate.
onSubmit: when the form is submitted. Return false to cancel the submission, typically after validation fails.
onCellEdit: the only type that runs in list editing. It gets sysIDs, table, oldValues, newValue and a callback; calling callback(false) stops the change.

The isLoading guard matters because onChange also fires while the form loads. And client scripts are for user experience, not security: anything enforced only in the browser can be bypassed through lists, imports or APIs.

Question 4

What is the difference between a UI policy, a client script and a data policy? When would you choose each?

Accepted Answer

- UI policy: client-side, mostly no-code. Based on a condition it makes fields mandatory, read-only or visible, and can reverse the actions when the condition is false. It can also run a script when true or false. First choice for simple form behaviour. - Client script: client-side JavaScript for anything a UI policy can't do: calling the server with GlideAjax, setting values, changing choice options, validating on submit. - Data policy: server-side enforcement of mandatory and read-only. It applies no matter how data arrives: forms, imports, web services. It can't hide fields. On load, client scripts run before UI policies, and when they conflict on mandatory or read-only, the UI policy generally wins. The key interview point: UI policies and client scripts only protect the form. If a rule must hold for imports, APIs and list edits too, use a data policy (a data policy can also be applied as a UI policy on the client), a business rule, or an ACL.

Question 5

What is the difference between an incident and a problem, and where does a known error fit in?

Accepted Answer

An incident is an unplanned interruption to a service, or a reduction in its quality. The goal of Incident Management is to restore service as quickly as possible, even with a workaround. Example: email is down for the sales team, so the service desk restarts the mail service. A problem is the cause, or potential cause, of one or more incidents. Problem Management looks for the root cause and a permanent fix, and it can be reactive (after repeated incidents) or proactive (spotting trends before users are hit). A known error is a problem whose root cause is understood and that has a documented workaround, often published to the knowledge base so the service desk can resolve related incidents faster. The permanent fix usually goes through Change Management. In ServiceNow, incidents link to a problem through the problem_id field, and a problem can raise a change request to deliver the fix.

Question 6

How do you query records with GlideRecord? Walk me through addQuery, addEncodedQuery, setLimit and get.

Accepted Answer

GlideRecord is the server-side API for database operations. You create it for a table, add conditions, call query(), then iterate with next().

addQuery(field, value) or addQuery(field, operator, value) adds a condition; multiple calls are ANDed.
addEncodedQuery(string) takes the encoded query you can copy from a list filter, like active=true^priority=1. ^ is AND, ^OR is OR.
setLimit(n) caps the number of rows fetched, which is important for performance.
get(sys_id) or get(field, value) loads a single record and returns true if it was found, so always check the return value.

Prefer getValue() for reading a field as a string and setValue() for writing. And test encoded queries carefully: an invalid field name is dropped from the query, which can silently return every record in the table.

Question 7

How do you call server-side code from a client script? Show a GlideAjax call and the matching script include.

Accepted Answer

The standard way is GlideAjax calling a client-callable script include. On the server, the script include extends AbstractAjaxProcessor, its name matches the class name, and the Client callable (Glide AJAX enabled) box is checked. Methods read inputs with this.getParameter() and return a value. On the client, you create new GlideAjax('ClassName'), set sysparm_name to the method name, add your own parameters (they must start with sysparm_), and send it asynchronously. getXMLAnswer() hands the callback the answer string directly; getXML() gives you the XML response to parse. Avoid getXMLWait(): it's synchronous, freezes the browser and isn't available in scoped apps. Methods whose names start with an underscore aren't callable from the client, and recent releases protect client-callable script includes with ACLs, so check access when a call silently returns nothing.

Question 8

What are current and previous in a business rule, and when is previous not available?

Accepted Answer

current is a GlideRecord holding the record being processed, including the values the user just submitted. In a before rule you change it directly and the changes are saved automatically. previous holds the record as it was before this update, so you can compare old and new values. The GlideElement helpers changes(), changesFrom() and changesTo() use it under the hood, e.g. current.state.changesTo(6). previous is only meaningful on update and delete. It's not available in async business rules, because they run later as a scheduled job after the transaction has finished; that's why the default template says previous /*null when async*/, and why changes() doesn't work inside an async script. You can still use change conditions in the async rule's condition builder, because that's evaluated during the original transaction.

Question 9

How are ACLs evaluated in ServiceNow? Explain table versus field ACLs and the order of matching.

Accepted Answer

To access a record, a user must pass both the table-level ACL and the field-level ACL for the operation (read, write, create, delete). Table ACLs match from most specific to most general: the table (incident), then its parent (task), then *. Field ACLs, per the docs: incident.number, task.number, *.number, then incident.*, task.*, *.*. The first matching ACL the user passes grants access and stops processing at that level; if the user passes none of the matching ACLs, access is denied. If several ACLs match at the same point in the order, passing any one is enough. Within a single ACL, the user must meet all of its requirements: one of the required roles, the data condition and the script (answer = true). Recent releases add Deny-Unless ACLs, which are evaluated before the normal Allow-If ones: fail a Deny-Unless and you're denied, whatever the Allow-If rules say. Admins can view and debug ACLs, but creating or editing them requires elevating to security_admin. The security debug output shows which rule passed or failed.

Question 10

What is an update set, and how do you move one from dev to test to production?

Accepted Answer

An update set is a named group of configuration changes (customer updates in sys_update_xml) that you move between instances as a unit. The flow: - In dev, create an update set and make it current, then build. Each change to a tracked record is captured; multiple edits to the same record keep only the latest version. - Mark it Complete. - In the target instance, retrieve it, either from a remote update source or by importing the exported XML. - Preview it. The preview flags problems such as collisions with newer local changes or missing referenced records. You resolve each one by accepting or skipping the remote update. - Commit it. Good habits: never build in the Default update set, keep sets small and focused, preview in test before prod, and use batching (parent/child sets) for large releases. Update sets are per application scope, so scoped app changes go into that app's update set.

Question 11

What are the three change types in ServiceNow, and what role does the CAB play?

Accepted Answer

ServiceNow follows the ITIL change types:

Standard: pre-authorized, low risk, repeatable, with a proven history. Requested from a catalog of standard change templates. No peer approval or CAB step; it goes from New straight to Scheduled.
Normal: anything that isn't standard or emergency. It goes through the full lifecycle: New, Assess, Authorize, Scheduled, Implement, Review, Closed, with technical or peer approval and CAB authorization.
Emergency: must be done as soon as possible, for example to fix a major incident or apply an urgent security patch. It skips Assess and goes straight to Authorize, where the emergency CAB approves it quickly.

The Change Advisory Board is the group that reviews and authorizes changes, weighing risk, impact, schedule conflicts and blackout windows. ServiceNow supports it with CAB meetings, agendas and the CAB Workbench. Good practice is to push more low-risk work into standard changes so the CAB spends time on genuinely risky ones.

Question 12

What is a script include, what kinds are there, and why prefer one over a global business rule?

Accepted Answer

A script include is a reusable server-side library: a class or function you call from business rules, flows, UI actions, other script includes or, if client callable, from the browser via GlideAjax.

The common shapes:

Class-based: Class.create() with a prototype, an initialize constructor and a type property. Called with new IncidentUtils().countOpenForCaller(id).
Classless (on-demand): a single function whose name matches the script include name.
Extending: Object.extendsObject(Parent, {...}), most often extending AbstractAjaxProcessor for GlideAjax.

The name must match the class or function name. Accessible from controls whether other scopes may call it, and callers from another scope use the scope prefix, like new global.IncidentUtils().

They beat global business rules because script includes load only when called, while global business rules load on every transaction. They're also easier to test and reuse.

Question 13

What are g_form and g_user? Name the methods you use most often.

Accepted Answer

Both are client-side globals available in form scripts. g_form (GlideForm) controls the current form: - getValue and setValue; pass the display value as the third argument of setValue for reference fields to save a server round trip - setMandatory, setReadOnly, setDisplay (removes the space) versus setVisible (leaves a gap) - showFieldMsg / hideFieldMsg, addInfoMessage / addErrorMessage - addOption, removeOption, clearOptions for choice lists - isNewRecord, getUniqueValue, getTableName, save, submit g_user (GlideUser) describes the logged-in user: userID, userName, firstName, lastName, getFullName(), hasRole(), hasRoleExactly() and hasRoleFromList(). Watch out: g_user.hasRole('itil') also returns true for admins, while hasRoleExactly() doesn't. And checking roles in the browser is for UX only; real enforcement is ACLs.

Question 14

A client script needs data that isn't on the form. What are your options, and which is most efficient?

Accepted Answer

There are four ways to get server data into the browser:

Display business rule + g_scratchpad: the rule runs when the form is built and puts values into g_scratchpad, which ships with the form. No extra round trip, so it's the most efficient choice when you know what you need at load time.
Asynchronous GlideAjax: calls a client-callable script include on demand, for example in an onChange. Best when the data depends on what the user just picked.
g_form.getReference(field, callback): fetches the whole referenced record. Easy, but it pulls every field; the docs no longer recommend it.
Client-side GlideRecord: also not recommended, for the same performance reasons.

A related anti-pattern is adding a field to the form only to hide it so a script can read it. It works, but it's slower than a scratchpad value. So: scratchpad for load-time data, async GlideAjax for dynamic data, and never a synchronous call.

Question 15

How would you count records efficiently? Compare getRowCount() with GlideAggregate.

Accepted Answer

getRowCount() is a GlideRecord method: you run a normal query, which retrieves the matching records, and then ask how many came back. That's fine if you're going to loop over the records anyway, but wasteful if all you need is the number. GlideAggregate extends GlideRecord and pushes the aggregation to the database: COUNT, SUM, MIN, MAX, AVG and a few others. You add the aggregate *before* query(), then read it with getAggregate(). Pass a field name, or call groupBy(), to get one row per group, like a SQL GROUP BY. addHaving() filters on the aggregate, and orderByAggregate() sorts by it. So the rule of thumb from the docs: if you only need a count, use GlideAggregate; use getRowCount() only when you also need the records. Note that getAggregate() returns a string, so convert it before doing arithmetic.

Question 16

What is not captured by update sets, and how do you move those things between instances?

Accepted Answer

Update sets track configuration on tables that have the update_synch attribute: forms, fields, business rules, client scripts, ACLs, catalog item definitions and so on. Things that commonly catch people out: - Data: incidents, requests, submitted catalog orders, CIs, users, group memberships and role grants. These are data, not configuration. - Home pages and content pages: not added by default; you have to unload them into the current update set. - Table deletions: removing a table isn't tracked, so you delete it manually on the target. - Data-losing dictionary changes: a type change that would lose data is skipped on commit and logged. - Changes made in another scope or another update set, which is why picking the right current update set matters. To move data, use Export XML / Import XML for a few records (keeps sys_ids), or import sets, including instance-to-instance imports, for larger volumes. Don't add the update_synch attribute yourself: the docs warn it can cause serious performance problems.

Question 17

How do tables, the dictionary and table extension work in ServiceNow? Why is the Task table important?

Accepted Answer

Tables are defined in sys_db_object and their columns in the dictionary, sys_dictionary, which stores each field's type, length, default value, reference target and attributes. Every record has system fields like sys_id (a 32-character GUID), sys_created_on and sys_updated_by. A table can extend another, and only at creation time. The child inherits all the parent's fields and adds its own; sys_class_name tells you which class a record belongs to. Custom global tables and fields get a u_ prefix; scoped ones get the app's x_ prefix. Task is the key base table. Incident, Problem, Change Request, Requested Item, Catalog Task and many others extend it, so they share fields like number, state, assignment group, assigned to, priority, work notes and comments, plus features built on Task: approvals, SLAs, assignment rules and the activity stream. That's why you extend Task for any new work-tracking app. When a child needs different behaviour for an inherited field, such as a different default or reference qualifier, you use a dictionary override rather than changing the parent.

Question 18

What is a reference field, and what is dot-walking? Where can and can't you dot-walk?

Accepted Answer

A reference field stores the sys_id of a record in another table, like a foreign key, and shows that record's display value. caller_id on Incident references sys_user. Dot-walking follows references with dots to reach fields on related records: current.caller_id.manager.email. You can use it: - in server scripts (business rules, script includes) - in condition builders and filters, by expanding related fields - in list and form layouts, to show related-record fields - in encoded queries, like caller_id.vip=true On the client you can't dot-walk with g_form: g_form.getValue('caller_id') only gives you the sys_id. Use a display rule with g_scratchpad, GlideAjax, or, less ideally, g_form.getReference(). Two tips: dot-walked values are GlideElement objects, so call toString() or getDisplayValue() when you need a string; and each hop can mean another database lookup, so avoid long dot-walks inside big loops.

Question 19

Explain how import sets, transform maps and coalesce work. How do you stop duplicates being created?

Accepted Answer

An import has three parts: - A data source (file, JDBC, LDAP, REST and others) loads rows into an import set staging table. - A transform map maps staging fields to a target table, such as sys_user or cmdb_ci_server, through field maps and optional scripts. - The transform writes each row to the target and records the outcome (inserted, updated, ignored, error) in the import log. Coalesce decides insert versus update. Mark one or more field maps as coalesce: if a target record matches on all coalesce fields, it's updated; if not, a new record is inserted. With no coalesce, every row is inserted, which is the classic cause of duplicates. Coalesce on fields that are genuinely unique, like email or employee number; if several target records match, only the first is updated. For custom logic, transform event scripts run at onStart, onBefore, onAfter and onComplete, among others, with source, target, map, log and action. Setting ignore = true in onBefore skips that row.

Question 20

What is the difference between Flow Designer and the legacy Workflow editor? Which would you use for new work?

Accepted Answer

Flow Designer is ServiceNow's low-code automation tool; in recent releases it lives inside Workflow Studio. A flow has a trigger and a series of actions: - Triggers: record created or updated, scheduled (daily, weekly, run once, repeat), or application triggers such as Service Catalog, SLA Task and inbound email. - Actions: reusable building blocks with defined inputs and outputs, from core ones like Create Record and Ask for Approval to spoke actions for third-party systems through IntegrationHub. - Subflows: reusable sequences you call from other flows. - Flow logic: If, For Each, Do Until, Wait and so on, with data pills passing values between steps. The legacy Workflow editor is the older drag-and-drop canvas of activities and transitions, attached to a table. It still runs in many instances, and you'll maintain existing workflows, but the docs now point to Workflow Studio for new process automation, and even suggest it over business rules. Flows are easier to read, reuse and upgrade, and the execution details page makes debugging much simpler.

Question 21

What is a UI action, and how do you make one that runs client-side validation and then server-side code?

Accepted Answer

A UI action adds a button, link or menu item to forms and lists: form button, form context menu, form link, list button, list choice, list context menu and so on. It has a Condition (evaluated on the server) and optional required roles that control when it appears, and a script that runs when it's clicked. By default the script runs on the server, with current available; action.setRedirectURL() controls where the user lands. With the Client box checked, the Onclick field names a function that runs in the browser with g_form available. To do both, use the classic pattern from base-system actions: the client function validates, then calls gsftSubmit(null, g_form.getFormElement(), '<action name>') to submit the form back to the server with that action name. On the server there is no window object, so a typeof window == 'undefined' check calls the server function. The Action name must match the one passed to gsftSubmit. Workspaces use a separate Workspace client script.

Question 22

What is the CMDB? Explain CIs, CI classes and relationships.

Accepted Answer

The Configuration Management Database stores the things you manage, configuration items (CIs), and how they relate, so you can understand the impact of an incident or change. - CI classes form a table hierarchy under cmdb_ci: for example cmdb_ci_hardware extends to cmdb_ci_computer, which extends to cmdb_ci_server and then to cmdb_ci_linux_server. Application and service classes sit alongside them. The CI Class Manager is where you view and extend the hierarchy. - Relationships live in cmdb_rel_ci, each with a parent, a child and a type such as *Depends on::Used by* or *Runs on::Runs*. They let you trace from a business service down to the servers it relies on. - Population: Discovery, Service Mapping and Service Graph Connectors fill the CMDB automatically; the Identification and Reconciliation Engine (IRE) uses identification rules to avoid duplicate CIs and reconciliation rules to decide which data source may update which attributes. A healthy CMDB is what makes impact analysis, change risk and event correlation trustworthy, and CMDB Health dashboards track completeness, correctness and compliance.

Question 23

When a user orders from the Service Catalog, which records get created? Explain REQ, RITM and SCTASK.

Accepted Answer

Submitting a cart creates a three-level structure:

Request (sc_request, numbered REQ...): the overall order, like a shopping-cart receipt. It holds who requested it, for whom, and the overall approval and state.
Requested Item (sc_req_item, RITM...): one per catalog item in the order. Each RITM carries the variable answers the user filled in and runs that item's fulfillment process, a flow or a legacy workflow.
Catalog Task (sc_task, SCTASK...): the actual work assigned to fulfillment groups, created by the RITM's flow. One RITM can have several tasks, in sequence or in parallel.

All three extend Task, so they get assignment, SLAs, approvals and the activity stream. On the server, you read variables from the RITM with current.variables.<variable_name>. Interviewers like to ask where approvals sit: typically on the RITM for item-specific approval (for example the user's manager), sometimes on the REQ for the whole order.

Question 24

What are catalog items, variables and variable sets? When would you use a multi-row variable set?

Accepted Answer

A catalog item is something users can order from the Service Catalog, like a laptop or software access. It has a name, description, category, pricing, a fulfillment flow and, most importantly, variables: the questions shown on the order form, such as select boxes, reference fields, checkboxes or dates. A variable set is a reusable group of variables you attach to many items. The classic example is a "Requested for" block used by dozens of items; change it once and every item picks up the change. Variable sets come in two kinds: - Single-row: an ordinary group of questions answered once. - Multi-row (MRVS): a grid where the user adds several rows, for example one row per new starter or per server. Its value is stored as JSON, so scripts parse it. Behaviour on the order form comes from catalog client scripts and catalog UI policies, which work like their form counterparts but target variables. They can be defined on an item or on a variable set.

Question 25

What is a record producer, and how is it different from a regular catalog item?

Accepted Answer

A record producer is a special catalog item that creates a record in a target table, typically a task table like Incident or an HR case, instead of a Request and Requested Item. It gives end users a friendly catalog-style form while producing a normal record behind it. Ways to populate the target record: - Name a variable the same as a target field, like caller_id, and it maps automatically. - Use a template for static values. - Use the script: current is the record being created and producer holds the user's answers, e.g. producer.issue_type. - Redirect afterwards with producer.redirect in the platform UI or producer.portal_redirect in Service Portal. Don't call current.update() or setAbortAction() in the script; the platform inserts the record for you. And the docs say not to use record producers to create Requested Items: if the user is ordering something that needs fulfillment, use a real catalog item so the request process runs.

Question 26

What is an order guide, and how does it decide which items to order?

Accepted Answer

An order guide lets a user fill in one form and submit a single request that generates several requested items. The standard example is new-hire onboarding: enter the starter's department, location and role once, and the guide orders a laptop, phone, badge and software access. How it works: - The order guide has its own variables, the initial questions. - Rule base entries each say "if these conditions on the answers are true, include this catalog item". - Cascading variables: answers given in the guide can flow down to variables with the same name on the included items, so users don't re-enter them. - The user reviews the chosen items, fills in item-specific questions and submits once. A script field can also add or remove items with guide.add() and guide.remove(). Order guides can even run automatically from a flow or server script, without the user submitting, which suits HR-driven onboarding. The trade-off versus one big catalog item is that each item keeps its own fulfillment process.

Question 27

What is the difference between a scoped application and the global scope? Why build scoped apps?

Accepted Answer

A scoped application gets its own namespace, like x_acme_book_rooms (x_, the instance's company code, then the app ID). Its tables, script includes and other files carry that prefix, and the platform restricts what other scopes can touch. Protections you can configure: - Table application access: whether other scopes can read, create, update or delete the table, and whether it's reachable from web services. - Accessible from on script includes: this scope only, or all scopes. - Cross-scope privileges and runtime access tracking (None, Tracking or Enforcing) control what the app's scripts may do outside its scope. - Scoped scripts get the scoped API set: for example gs.info() instead of gs.log(), and no getXMLWait(). Global is the legacy shared space where most base-system ITSM configuration lives; global code can reach almost anything, which is exactly the risk. Scoped apps give isolation, clearer ownership, safer upgrades and clean packaging through source control or the app repository, and new scoped apps default to the ES2021 JavaScript mode.

Question 28

How would an external system create or read incidents through REST, and when would you build a Scripted REST API instead?

Accepted Answer

The out-of-box option is the Table API: /api/now/table/{tableName}. GET lists or reads a record by sys_id, POST creates, PUT or PATCH updates, DELETE deletes. Useful parameters include sysparm_query (an encoded query), sysparm_fields, sysparm_limit, sysparm_offset and sysparm_display_value. The REST API Explorer lets you try calls and generates sample code. Requests run as the authenticated user, so ACLs and data policies apply. For inbound data that needs mapping or validation, the Import Set API posts rows into a staging table so a transform map handles coalescing. Build a Scripted REST API when you want a clean contract that doesn't expose your table structure: combining several tables, business validation, custom status codes, or versioning. It lives at /api////, each resource has a script that receives request and response, and you can require ACLs on the API or individual resources.

Question 29

Write the script for a Scripted REST API POST resource that creates an incident. What do request and response give you?

Accepted Answer

Each resource script is an IIFE receiving a RESTAPIRequest and a RESTAPIResponse.

From request you get:

request.body.data: the parsed request body; dataString gives the raw text
request.pathParams: values from the relative path, like {id} in /incident/{id}
request.queryParams: query-string values
request.getHeader(name), plus uri and url

With response you call setStatus() and setBody(), which serializes an object to the requested format (JSON or XML), or simply return an object from the script. You can also set headers.

Good practice: validate input and return proper status codes (400 for bad input, 201 for created, 404 when a record isn't found), keep business logic in a script include so the REST script stays thin, version the API so you can change it without breaking consumers, and rely on authentication plus ACLs rather than hand-rolled checks.

Question 30

How do events and notifications work together? Show how you would fire a custom event from a business rule.

Accepted Answer

An event is a record in the event queue (sysevent) saying "something happened". You register the name in the Event Registry, then queue it from a script with gs.eventQueue(name, record, parm1, parm2). Scheduled jobs process the queue and hand each event to whatever listens: - Email notifications set to *Event is fired*; they can take recipients from parm1 or parm2 - Script actions, which run server-side code for the event - legacy workflow activities and inactivity monitors A notification can instead be sent when a record is inserted or updated (with conditions), or be triggered from a flow's notification step. Each defines who receives it, what it contains (subject, body, email scripts for dynamic content), and a weight: when duplicate notifications target the same record and recipients, only the highest weight is sent; weight 0 is always sent. Why use events? They decouple *when something happens* from *what reacts*, and processing is asynchronous, so the user's transaction isn't slowed.

Question 31

How do SLAs work in ServiceNow? Explain SLA definitions, task SLAs and their conditions.

Accepted Answer

An SLA definition (contract_sla) describes a target: the table (for example Incident), the duration (say 4 hours), the schedule (such as 8-5 weekdays, which decides business time) and a set of conditions. The type can be SLA (with a customer), OLA (between internal teams) or underpinning contract (with a vendor). When a task matches, the SLA engine attaches a task SLA (task_sla) record that tracks timing: start time, breach time, actual and business elapsed time and percentage, time left, and whether it has breached. Conditions: - Start: when the SLA attaches - Pause / Resume: stop and restart the clock, typically while On Hold awaiting the caller - Stop: when the SLA completes, for example when the incident is resolved - Cancel and Reset: cancel it, or complete it and attach a fresh one Task SLA stages are In progress, Paused, Completed and Cancelled. Notifications and escalations at thresholds such as 50% or 75% are usually driven by the SLA's flow. A common gotcha: if the pause condition overlaps the start condition badly, the SLA stays paused forever or gets cancelled.

Question 32

What is gs, and which GlideSystem methods do you use most?

Accepted Answer

gs is the GlideSystem object, available in server-side scripts. The methods you reach for most: - User and session: getUserID(), getUserName(), getUserDisplayName(), getUser() (a GlideUser object), hasRole(), getSession(), isInteractive() - Logging: gs.info(), gs.warn(), gs.error(), gs.debug(), which accept {0}-style parameters. gs.log() exists only in global scope. - Messages to the user: addInfoMessage(), addErrorMessage(); getMessage() for translated text - Properties: getProperty(name, default), setProperty() - Events: eventQueue() and eventQueueScheduled() - Date helpers: beginningOfToday(), daysAgo() and friends, often used in queries - Utility: nil(), generateGUID(), tableExists() Like g_user.hasRole(), gs.hasRole() returns true for admin users. And session messages don't make sense in async code: addInfoMessage() isn't supported in async business rules.

Question 33

How do users, groups and roles relate, and what is the best practice for granting access?

Accepted Answer

- Users (sys_user) are people or integration accounts. - Groups (sys_user_group) are teams, such as a Service Desk or a Network group. They're used for assignment, approvals and notifications. - Roles (sys_user_role) grant permissions, like itil for fulfillers or catalog_admin. ACLs, modules, UI actions and scripts check roles. Roles can contain other roles, so granting one role can bring several others. A user gets roles directly or, preferably, by inheriting them from group membership. Best practice: assign roles to groups, not individual users. When someone joins the Network team they're added to the group and get the right access automatically; when they leave the group it's removed. That's easier to audit and matches how HR and identity systems provision people. Keep admin to a small set of people, and remember that some roles, like security_admin, are elevated: an admin must explicitly elevate to use them. Also, roles that grant fulfiller rights often have licensing implications, so check before handing them out.

Question 34

Why shouldn't you call current.update() in a business rule, and what should you do instead?

Accepted Answer

current.update() saves the record again, which triggers the insert/update business rules on that table again, which may call update() again. At best you get a double save with duplicate audit entries and notifications; at worst a recursion that the platform has to detect and stop. The docs say it's never necessary. What to do instead: - Before rules: just set fields on current. Changes are written automatically once all before rules finish. - After rules: use them to update related records, such as the parent problem or child tasks, not the current one. - Async rules: good for slow work; if you really must write back to the same record, keep it minimal and deliberate. In the rare case where you must update the current record from an after or async rule, setWorkflow(false) before update() suppresses business rules, but it also skips engines, notifications and audit-driven logic, so treat it as a last resort and document why.

Question 35

This script is meant to collect the sys_ids of active P1 incidents, but every entry in the array is the same. Why, and how do you fix it?

Accepted Answer

inc.sys_id isn't a string. Dot-walking a field on a GlideRecord returns a GlideElement object, and the GlideRecord reuses its element objects as next() moves from row to row. So you push the same object reference on every iteration, and when you read the array afterwards every entry reflects the last row the record pointed at. The fix is to push a primitive string: - ids.push(inc.getValue('sys_id')) - ids.push(inc.getUniqueValue()) - ids.push(inc.sys_id.toString()) or String(inc.sys_id) The same bug shows up with any field, for example building an object like { number: inc.number } inside a loop. That's one reason experienced developers use getValue() by default. Remember that getValue() returns null for empty fields and "0" or "1" for booleans, so compare accordingly.

Question 36

When a record is saved, in what order do business rules, engines and notifications run? Why does the business rule Order value matter?

Accepted Answer

Per the docs, when a record is inserted or updated:

Before business rules with order below 1000
Before engines: approval, assignment rules, data policy, data lookup, escalation, field normalization and others, in no guaranteed order
Before business rules with order 1000 or higher
The database operation
After business rules with order below 1000
After engines: including the table notifications engine and the trigger engine that starts record-triggered flows
Email notifications, by weight
After business rules with order 1000 or higher

Async rules run later, from a scheduled job created during the transaction. Display rules run only when a form loads, and query rules run before queries.

So Order is more than tie-breaking. If you need a value that assignment rules or a data lookup will set, your before rule must be order 1000 or above. If you want to adjust something before the data policy engine checks mandatory fields, keep it below 1000. Client-side scripts always run before the form is submitted, so they come before all of this.

Question 37

What is a before query business rule, and when would you use one instead of an ACL?

Accepted Answer

A before query rule runs before the platform queries a table, and it can add conditions to current so that some rows are never returned. The base system's rule that limits which incidents users without the itil role can see is a well-known example. Compared with read ACLs: - The filtering is silent: users don't get the "rows removed by security constraints" message they get when ACLs strip rows from a list, and counts and pagination stay correct. - It happens in the database query, which usually performs better than evaluating ACLs row by row. - But it's a blunt instrument: it only restricts reads, it applies to every query on that table, including your own scripts, and it's easy to lock out integrations or reports. Always add a condition or early return for admins and system contexts. The docs also warn to use them sparingly, keep conditions on indexed fields and avoid lots of OR clauses. Security still belongs in ACLs; use query rules for data segregation that ACLs handle badly, not as a replacement for domain separation.

Question 38

How do you call an external REST API from ServiceNow in script? Where should that call run?

Accepted Answer

Use RESTMessageV2 from the sn_ws namespace. Two styles: - Named REST Message records (System Web Services > Outbound > REST Message): store the endpoint, HTTP methods, headers, authentication and variable substitutions like ${title}. Scripts call new sn_ws.RESTMessageV2('Ticketing API', 'Create ticket') and fill variables with setStringParameter() or setStringParameterNoEscape(). - Ad hoc: new sn_ws.RESTMessageV2() with setEndpoint(), setHttpMethod(), setRequestHeader(), setRequestBody(). execute() returns a RESTResponseV2 with getStatusCode(), getBody() and haveError(). Authentication goes through setBasicAuth() or, better, an authentication profile such as OAuth 2.0 via setAuthenticationProfile(). For systems inside the corporate network, setMIDServer() routes the call through a MID Server. Where to run it: never in a before rule that blocks the user's save. Use an async business rule, an event with a script action, or a flow with an IntegrationHub REST step, and handle timeouts, errors and retries explicitly.

Question 39

What is IntegrationHub, and what is a spoke?

Accepted Answer

IntegrationHub extends Flow Designer (Workflow Studio) with integration capabilities, so integrations are built as flow actions rather than scripts. - A spoke is a scoped application bundling Workflow Studio content (actions, sometimes subflows and triggers) for one system or domain: for example Slack, Microsoft Teams, Jira or Azure AD. You drop an action like "Create Jira issue" into a flow and fill in its inputs with data pills. - Some spokes come with the platform or the parent application, such as the ITSM spoke; many third-party spokes require an IntegrationHub subscription, and usage is licensed. - When there's no spoke, you build a custom action using steps such as the REST step, SOAP step or JSON parser; higher tiers add steps like PowerShell, SSH and JDBC, which typically run through a MID Server. - Connection and credential aliases keep endpoints and secrets out of the action, so the same flow works in dev, test and prod with different connections. Why interviewers care: it's the low-code, upgrade-friendly alternative to hand-written RESTMessageV2 scripts, and it gives you reusable, testable, observable integrations.

Question 40

What is a MID Server, how does it communicate with the instance, and what is it used for?

Accepted Answer

A Management, Instrumentation and Discovery (MID) Server is a Java application you install on a Windows or Linux host inside your network. It lets a cloud instance reach systems it can't reach directly. How it talks to the instance: the MID Server always initiates the connection outbound over HTTPS, so you don't open inbound firewall ports. Work is exchanged through the ECC Queue (ecc_queue): the instance writes *output* records for a MID Server, the MID Server picks them up (it's notified through the message bus and also polls periodically), does the work, and writes *input* records with the results. Common uses: - Discovery and Service Mapping, scanning the network to populate the CMDB - Integrations with internal systems: JDBC or LDAP imports, REST or SOAP calls via setMIDServer(), IntegrationHub PowerShell and SSH steps - Event Management and metric collection Operational points: validate a new MID Server before use, run several for capacity and failover (clusters), give each only the capabilities and IP ranges it needs, and note that MID Servers upgrade automatically to match the instance.

Question 41

How do you run a script on a schedule in ServiceNow, and what should you watch out for?

Accepted Answer

The classic tool is a Scheduled Script Execution (a scheduled job, sysauto_script), under System Definition > Scheduled Jobs. You pick when it runs (daily, weekly, monthly, periodically, once or on demand), a Run as user and optionally a condition script, then write the server-side script. Behind the scenes the scheduler creates sys_trigger entries. Alternatives: a flow with a scheduled trigger for low-code logic, scheduled data imports for integrations, and scheduled reports. Things to watch: - It runs non-interactively: no gs.addInfoMessage(), no form, no user session context, and the Script Debugger can't pause it. Log with gs.info(). - Choose Run as carefully; the job gets that user's access. - Process large volumes in batches with setLimit() and indexed queries, rather than one giant transaction. - Schedule heavy jobs outside business hours, and make them safe to re-run if they fail halfway. - Test in sub-production; "Execute Now" on a big job in prod is a classic outage.

Question 42

What is the Automated Test Framework (ATF), and how do you use it in an upgrade or release process?

Accepted Answer

ATF lets you build automated tests on the instance itself, without external tools. - A test is a sequence of steps: impersonate a user, open a new form, set field values, click a UI action, submit, then assert field values, visibility or mandatory state. There are server steps too, like record queries and Run Server Side Script (which supports Jasmine), plus Service Catalog, Service Portal, REST and custom UI steps. - Test suites group tests, can be nested, and can be scheduled. Browser-based steps run in a Client Test Runner tab; server steps run on the instance. - ATF rolls back the data a test creates when it finishes, and tests can be parameterized to run with multiple data sets. In a process: build tests for critical flows (incident creation, catalog ordering, approvals, key business rules), run the suite after every upgrade in dev and test, before promoting update sets, and in CI pipelines. Design tips from the docs: create your own test users and records instead of relying on existing data, avoid changing system tables, and don't run ATF in production; execution is disabled by default there through a system property.

Question 43

How is a Service Portal widget structured, and how do the client and server parts talk to each other?

Accepted Answer

A portal is made of pages, pages have containers, rows and columns, and columns hold widget instances. A widget has: - HTML template: AngularJS markup bound to the controller, e.g. {{c.data.items}} - Client script: an AngularJS controller; by convention var c = this - Server script: runs on load, fills the data object, reads instance options and, on later calls, the input object sent from the client - Optional link function (DOM work), option schema (configurable instance options), CSS/SCSS and Angular providers (shared directives or services) Communication: the server script runs when the widget loads and data arrives as c.data. The client calls c.server.update() to send c.data back as input and rerun the server script, or c.server.get({ action: ... }) to send a custom payload. $sp gives server helpers like $sp.getParameter(); spUtil gives client helpers like recordWatch() and addInfoMessage(). Best practices: clone base-system widgets instead of editing them, or embed them; always setLimit() queries; avoid unfiltered record watchers and auto-refresh loops.

ServiceNow interview questions & answers

Top 43 ServiceNow interview questions most asked first