ServiceNow Interview Preparation Guide 2026

41) What is GlideRecord?

GlideRecord is the primary server-side API used to query, insert, update, and delete records in ServiceNow tables. It is one of the most fundamental scripting objects and appears constantly in business rules, script includes, and background scripts.

42) What is the basic pattern for querying with GlideRecord?

The basic pattern is to instantiate a GlideRecord object for a table, add query conditions, call query(), and then loop using next() to process each matching record. This pattern is asked in almost every ServiceNow developer interview as a baseline coding check.

43) What is the difference between get() and query() in GlideRecord?

get() retrieves a single record directly by sys_id or a unique value and returns a boolean, while query() executes a broader search that may return multiple records requiring a next() loop. Interviewers use this question to check whether candidates understand efficient single-record retrieval versus multi-record processing.

44) What does addQuery() do?

addQuery() adds a filter condition to a GlideRecord query, similar to a WHERE clause in SQL. Multiple addQuery() calls are combined with AND logic by default unless addOrCondition() is used.

45) What is addOrCondition() in GlideRecord?

addOrCondition() adds an OR condition to an existing GlideRecord query, allowing more flexible filtering than the default AND-based addQuery() chaining. It is commonly tested to see if candidates understand query logic beyond simple filters.

46) What is the difference between update() and insert() in GlideRecord?

update() saves changes to an existing record that was retrieved via query or get, while insert() creates a brand-new record in the table. Using the wrong method on the wrong record state is a common scripting mistake interviewers ask about.

47) What is deleteRecord() versus deleteMultiple()?

deleteRecord() deletes a single retrieved GlideRecord, while deleteMultiple() deletes all records matching the current query conditions without needing to loop through them individually. deleteMultiple() is powerful but risky if query conditions are not carefully scoped.

48) Why is querying without conditions considered a bad practice?

Querying a large table without any addQuery() conditions can return an enormous result set, causing severe performance issues and potentially locking up the instance. This is one of the most common anti-patterns interviewers ask candidates to identify and fix.

49) What is GlideAjax?

GlideAjax is a class that enables a client script to call server-side code in a script include asynchronously without submitting or reloading the form. ServiceNow documentation outlines general steps to follow when using GlideAjax in a client script to communicate with server-side logic.

50) Why is GlideAjax used instead of direct GlideRecord in client scripts?

GlideAjax is used because client scripts run in the browser and cannot directly execute server-side database operations like GlideRecord safely or efficiently; GlideAjax bridges that gap by calling a script include on the server. Community discussions specifically address moving logic from GlideRecord to GlideAjax within onChange client scripts to follow this best practice.

51) What is a script include?

A script include is a reusable server-side script container that defines functions or classes that can be called from business rules, client scripts via GlideAjax, or other server-side scripts. It supports the DRY principle by centralizing reusable logic in one place.

52) What is the “Client callable” checkbox on a script include?

The “Client callable” setting must be enabled on a script include for it to be invoked through GlideAjax from a client script. Forgetting to enable this setting is a common practical debugging scenario in interviews.

53) What is the general structure of a GlideAjax call?

ServiceNow’s cheat-sheet guidance describes creating a GlideAjax object referencing the script include name, setting the function name to call, adding parameters, and then calling getXML with a callback function to handle the response asynchronously. This asynchronous callback pattern is central to understanding client-server communication in ServiceNow.

54) What is a callback function in GlideAjax?

A callback function is the function executed once the server-side script include finishes processing and returns a response, allowing the client script to then update the form or UI based on that response. It is essential because GlideAjax calls are asynchronous, not synchronous.

55) What is a client script?

A client script is browser-side JavaScript that runs on a form to control UI behavior, such as showing or hiding fields, setting values, or validating input, without needing a full server round trip. Client scripts are a core topic in almost every ServiceNow developer interview.

56) What are the types of client scripts?

The main client script types are onLoad, onChange, onSubmit, and onCellEdit. Each type is triggered by a different user interaction and is chosen based on when the logic needs to run.

57) What is an onLoad client script?

An onLoad client script runs when the form finishes loading, and it is commonly used to set default field states or prepare the form based on existing values. It runs before the user makes any changes to the form.

58) What is an onChange client script?

An onChange client script runs when a specific field’s value changes, making it ideal for dynamic behavior like updating dependent fields or triggering GlideAjax calls based on user input.

59) What is an onSubmit client script?

An onSubmit client script runs when the form is submitted, typically used for final validation before the record is saved. Returning false in this script type prevents the form from submitting.

60) What is an onCellEdit client script?

An onCellEdit client script runs when a cell is edited directly in a list view rather than on a full form. It is less commonly used but tested to check whether candidates understand list-based inline editing scenarios.

61) What is the difference between a client script and a UI policy?

A UI policy is generally recommended for straightforward field behavior like mandatory, read-only, or visible conditions triggered on load or change, while client scripts are used for more complex logic that a UI policy’s simpler condition builder cannot express. Community guidance notes UI policies can also run scripts for true and false conditions, blurring the line somewhat, but the general rule is to prefer UI policies for simple declarative behavior.

62) Which runs first, a UI policy or a client script?

This exact execution order is frequently debated in community forums, and the safe interview answer is that execution order can depend on configuration and should generally not be relied upon; instead, logic should be designed so that order dependency is avoided wherever possible. It is a good scenario question to demonstrate careful, defensive scripting habits.

63) What is a UI policy?

A UI policy is a declarative configuration tool used to dynamically control field states, such as mandatory, read-only, or visible, based on conditions, without necessarily writing custom scripts. It is preferred over client scripts for simple field behavior because it is easier to maintain.

64) What is a UI action?

A UI action defines custom buttons, links, or context menu items on a form or list, such as a custom “Escalate” button on an Incident form. UI actions can run client-side or server-side logic depending on configuration.

65) What is a Data Policy?

A Data Policy enforces field-level rules, such as mandatory or read-only conditions, at the server level regardless of how the data is entered, including through imports or web services. This is different from a UI policy, which only affects the form’s visual behavior in the browser.

66) Why is a Data Policy needed if a UI policy already enforces a rule?

A UI policy only controls behavior within the form UI, so data entered through APIs, imports, or scripts could bypass it, while a Data Policy enforces the rule at a deeper level regardless of entry method. This distinction is a classic interview question testing understanding of client-side versus server-side enforcement.

67) What is a business rule?

ServiceNow documentation defines a business rule as a server-side script that runs when a record is displayed, inserted, updated, or deleted, or when a table is queried. Business rules are commonly used to validate data, set default values, trigger actions, or prepare information for the user interface.

68) What are the four types of business rules?

The four types are before, after, async, and display, and each is distinguished by exactly when it executes relative to the database operation. This four-type breakdown is one of the most frequently asked ServiceNow interview questions across all experience levels.

69) What is a before business rule?

A before business rule runs just before a record is saved, inserted, or updated, making it ideal for data validation or setting default values before the database operation occurs. Community guidance notes this is exactly when to use this type: when you need to control or modify data before it is written to the database.

70) What is an after business rule?

An after business rule runs after the record has been successfully saved to the database, and it is typically used for notifications, integrations, logging, or updating related records. It should be used when logic must happen only after the database operation is fully complete.

71) What is an async business rule?

An async business rule also runs after the record is saved, but it executes in the background outside the user’s immediate transaction, making it ideal for long-running or heavy operations like integrations or large calculations. Because it runs asynchronously, it does not block or slow down the user’s experience, and it is recommended particularly when calling web services.

72) What is a display business rule?

A display business rule runs when the form is loaded, just after data is read from the database but before the user sees the record, and it is mainly used to pass server-side data to the client, usually through the g_scratchpad object. This makes it the standard technique for making server-side data available client-side at form-load time without an extra GlideAjax call.

73) What is g_scratchpad used for?

g_scratchpad is a client-accessible object populated by a display business rule to pass server-side values to client scripts during form load, avoiding an additional GlideAjax round trip. It is a classic technique for efficient display-time server-to-client data transfer.

74) What is the typical execution order of business rules?

Community explanations describe the order as: query business rules run on database interaction, then display business rules run just after data is read, then before business rules run just before the database update, then after business rules run immediately following the update, and finally async business rules run in the background after the after rules. Knowing this sequence in detail is a strong signal of solid ServiceNow scripting fundamentals in interviews.

75) What is a query business rule?

A query business rule runs whenever a table is queried, and it is commonly used to restrict which records a user can see based on conditions, functioning similarly to a security filter layered on top of standard access control. It runs before display business rules in the overall execution sequence.

76) When should you choose an async business rule over an after business rule?

Choose async when the logic is long-running, non-critical to the immediate transaction, or involves external integrations, since it will not delay the user’s save operation, while after rules should be used when the logic must complete before the transaction is considered fully finished. This distinction is frequently tested with scenario questions about slow integrations blocking user saves.

77) What is the “Order” field on a business rule?

The Order field determines the sequence in which multiple business rules of the same type execute on the same table, with lower numbers generally executing first. It becomes critical to manage carefully when several business rules interact with the same fields.

78) What are best practices for writing business rules?

Best practices include keeping logic focused and modular, avoiding heavy GlideRecord operations in before rules where possible, using script includes for reusable logic, and choosing the correct rule type based on when the logic truly needs to run. Interviewers often ask candidates to critique a poorly designed business rule as a practical test of these principles.

79) Can business rules be scoped to run only under certain conditions?

Yes, every business rule has a condition field, and the script only executes if that condition evaluates to true, which helps avoid unnecessary processing and keeps logic targeted. This condition-based filtering is essential for performance and maintainability.

80) Why is scripting knowledge important even for administrator-track candidates?

Scripting knowledge is important because even administrator-focused roles frequently require reading, modifying, or troubleshooting existing business rules, client scripts, and script includes during day-to-day configuration work. Interviewers often include basic scripting questions for administrator roles specifically to confirm the candidate can support developer-built customizations.