ServiceNow Developer Interview Questions

[Its_Azar]

 

1. Core ServiceNow Platform Fundamentals

1. What is ServiceNow, and how does it differ from traditional web applications?

Interviewers want to assess whether you understand that ServiceNow is not a generic web app, but a low-code enterprise workflow platform.

Key points to explain:

• ServiceNow is built on a single data model using tables

• It provides out-of-the-box ITSM, HR, CSM, GRC, and custom app capabilities

• Developers extend functionality using configuration first, code second

• The platform enforces upgrade-safe development practices

A strong answer connects ServiceNow’s architecture with scalability and maintainability.

 

2. What is an application scope, and why is it important?

This question tests your understanding of modular development.

You should explain:

• What Global scope is

• What Scoped applications are

• How scope controls:

  • Table access

  • Script Include visibility

  • API exposure

• Why scoped apps are safer for upgrades and reuse

Also mention cross-scope access policies and real-world scenarios where incorrect scope design causes issues.

3. Explain the ServiceNow table structure and inheritance model

This question checks your data model understanding.

Topics to cover:

• Base tables (Task, CMDB tables)

• Table extension and inheritance

• Shared fields from parent tables

• Why extending Task is common

• How inheritance impacts:

  • Business Rules

  • ACLs

  • Reporting

Interviewers often follow up with performance-related questions here.

 

2. Client-Side Scripting (UI Behavior)

 

4. What are Client Scripts, and when should they be used?

Explain that Client Scripts:

• Run in the browser

• Improve user experience, not business logic

• Are used for validation, UI changes, and form behavior

Then break down:

• onLoad

• onChange

• onSubmit

• onCellEdit

Also explain what should NOT be done in client scripts, such as data integrity enforcement.

 

5. Difference between Client Script and UI Policy

This is a classic interview question.

Your explanation should include:

• UI Policies are declarative

• Client Scripts are imperative

• Performance considerations

• Maintainability trade-offs

• When Client Scripts are unavoidable

Interviewers appreciate answers that emphasize using UI Policies first where possible.

 

6. How does GlideAjax work?

This is a very important developer question.

Explain:

• Why client scripts cannot directly access the database

• How GlideAjax bridges client and server

• The role of Script Includes

• Why asynchronous calls matter

Avoid code here; focus on flow and design rationale.

 

3. Server-Side Scripting (Core Development Area)

7. What are Business Rules, and how do you decide when to use them?

You should discuss:

• When Business Rules execute

• Different execution timings:

  • Before

  • After

  • Async

  • Display

• Use cases for each type

Also talk about:

• Avoiding unnecessary Business Rules

• Performance impact

• Debugging complexity

This is a place where interviewers check platform maturity.

 

8. Difference between Business Rules, Script Includes, and Flow Designer

This question tests architectural decision-making.

A strong answer explains:

• Business Rules = record lifecycle logic

• Script Includes = reusable logic

• Flow Designer = event-driven workflows

• When code is preferable to flows

• When flows reduce technical debt

Avoid positioning one as “better”; focus on appropriate usage.

 

9. What is a Script Include, and how do you design one properly?

Key points to cover:

• Purpose of Script Includes

• Reusability and encapsulation

• Client-callable vs server-only

• Access modifiers

• Naming conventions

Interviewers often ask follow-ups about performance and maintainability.

 

10. Explain synchronous vs asynchronous Business Rules

Explain:

• Execution timing

• User experience impact

• When async rules are preferred

• Common mistakes developers make with async logic

This question reveals how well you understand transaction processing in ServiceNow.

 

4. Security and Access Control

11. What are ACLs, and how do they work?

Security is non-negotiable.

Your explanation should include:

• Table ACLs

• Field ACLs

• Role-based checks

• Scripted ACLs

• Evaluation order

Also mention:

• Performance considerations

• Why ACLs should be preferred over UI restrictions

 

12. Difference between ACLs and UI Policies

Interviewers want to see if you understand security vs UI control.

Explain clearly:

• UI Policies control visibility

• ACLs control access

• UI restrictions can be bypassed

• ACLs are enforced server-side

This is a foundational security concept.

 

5. Data Handling and APIs

13. What is GlideRecord, and how is it used?

This is unavoidable in developer interviews.

You should explain:

• GlideRecord as an abstraction layer

• CRUD operations

• Query building

• Encoded queries

• Performance best practices

Mention common pitfalls:

• Queries inside loops

• Not limiting results

• Ignoring indexes

 

14. What are REST APIs in ServiceNow, and how have you used them?

Cover:

• Inbound vs outbound REST

• Scripted REST APIs

• Authentication methods

• Error handling

• Real-world integration examples

Interviewers often ask follow-ups on security and payload validation.

 

6. Performance and Best Practices

15. How do you optimize performance in ServiceNow?

This question separates junior developers from experienced ones.

Topics to include:

• Avoiding unnecessary Business Rules

• Using async processing

• Query optimization

• Index usage

• Script Includes over duplicated logic

• Avoiding client-server round trips

Use practical explanations, not theory.

 

16. How do you debug issues in ServiceNow?

Discuss:

• Background Scripts

• Logs

• Script Debugger

• gs.log and gs.info

• System Diagnostics

Interviewers look for methodical debugging approaches, not trial-and-error.

 

7. Update Sets and Deployment

17. What are Update Sets, and what are their limitations?

Explain:

• Purpose of Update Sets

• What gets captured

• What does not get captured

• Best practices for naming and management

• Common migration issues

Mention scenarios where application repository or CI/CD is preferable.

 

18. How do you handle conflicts during deployment?

A strong answer covers:

• Preview issues

• Skipped records

• Manual conflict resolution

• Testing after deployment

• Rollback strategy

This shows real project experience.

 

8. Scenario-Based Questions (Very Important)

19. How would you design a custom application in ServiceNow?

Explain your approach:

• Requirement analysis

• Data model design

• Security planning

• UI design

• Business logic placement

• Testing and deployment

Interviewers want to see structured thinking, not just technical knowledge.

 

20. How do you decide whether to use code or configuration?

This is a mindset question.

Discuss:

• Platform-first approach

• Maintainability

• Upgrade safety

• Team skill levels

• Long-term ownership

This answer often leaves a strong impression.

 

Final Thoughts

ServiceNow development interviews are less about memorizing features and more about understanding why things exist and how to use them correctly.

If you:

• Understand platform fundamentals

• Write clean, reusable server-side logic

• Respect security boundaries

• Think about performance early

• Prefer configuration before code

—you are already ahead of most candidates.

[tiagomacul]

https://macul.medium.com/pesquisa-de-posts-sobre-interview-questions-de-servicenow-b75fa8660f05

[martinvirag]

is this AI generated? 

[Kahkshan Sabooh]

1. Core ServiceNow Platform Fundamentals

1. What is ServiceNow, and how does it differ from traditional web applications?

ServiceNow is a cloud-based enterprise workflow platform built on a single-instance, single-data-model architecture. Unlike traditional web apps — which are custom-built from the ground up with separate databases, frameworks, and logic layers — ServiceNow provides a unified platform where everything (data, logic, UI, security) lives together.

Key differences:

• Everything is table-driven. All data, including application metadata, lives in tables.
• It follows a configuration-first, code-second philosophy — most functionality is achieved through declarative tools before resorting to scripting.
• It ships with prebuilt process frameworks (ITSM, HR, CSM, GRC) that can be extended rather than built from scratch.
• It enforces upgrade-safe development by separating customer customizations from platform code, meaning ServiceNow upgrades don't overwrite your work if you follow best practices.
• Development is governed by application scopes, which modularize and protect customizations.

---

2. What is an application scope, and why is it important?

An application scope defines the namespace and boundaries of a ServiceNow application. It controls what a script or configuration artifact can access and modify.

• Global scope is the legacy default where everything is accessible to everything else — fine for simple customizations but risky at scale.
• Scoped applications isolate their tables, scripts, and APIs from other apps. A scoped app cannot access another app's private resources unless explicitly permitted.

Scope controls:

• Which tables a script can read/write
• Whether a Script Include is callable from other scopes
• How APIs are exposed or restricted

Why it matters:

• Scoped apps are upgrade-safe because they're clearly separated from platform code.
• They enable reuse and packaging via the Application Repository.
• Incorrect scope design (e.g., putting everything in Global) creates maintenance nightmares and security risks in multi-team environments.

Cross-scope access is handled via Cross-Scope Access Policies, where one app explicitly grants another permission to use its resources.

---

3. Explain the ServiceNow table structure and inheritance model

ServiceNow uses a relational table model with a powerful inheritance system.

• Base tables like task define common fields (number, state, assigned_to, description) shared by many processes.
• Child tables extend the base table and inherit all its fields. For example, incident, change_request, and problem all extend task.
• Inheritance is physical — child records are stored in the child table but a row also exists in the parent table, linked by sys_id.

Why extending task is common:

• You get approvals, SLAs, work notes, and assignment logic for free.
• Reports and dashboards can query across all task types.

Inheritance impacts:

• Business Rules on the parent table fire for child records too.
• ACLs on the parent apply unless overridden on the child.
• Reporting can roll up data across all child tables.

Performance implication: deeply nested inheritance chains or very wide tables (many fields) can slow queries, so table design requires careful thought.

---

2. Client-Side Scripting

4. What are Client Scripts, and when should they be used?

Client Scripts are JavaScript functions that execute in the user's browser to control form behavior. They are for UX enhancement, not business logic enforcement.

Types:

• onLoad — runs when the form loads. Use to set default values, hide fields, or pre-populate data.
• onChange — runs when a specific field value changes. Use to show/hide related fields or trigger lookups.
• onSubmit — runs before the form is submitted. Use for client-side validation warnings.
• onCellEdit — runs when a cell in a list is edited.

What NOT to do in Client Scripts:

• Don't enforce critical data integrity here — users can bypass browser-side logic.
• Don't perform heavy database lookups synchronously (use GlideAjax instead).
• Don't duplicate Business Rule logic in client scripts.

---

5. Difference between Client Script and UI Policy

  UI Policy Client Script

Type	Declarative	Imperative (code)
Use	Show/hide/mandatory fields	Complex conditional logic
Maintainability	High — no code needed	Lower — requires scripting
Flexibility	Limited to standard actions	Full JavaScript flexibility
Performance	Slightly better	Slightly heavier

Best practice: Always try UI Policies first. Only use a Client Script when UI Policy conditions are too complex or you need logic that UI Policies can't handle (e.g., manipulating field values dynamically, calling GlideAjax). This keeps the platform more maintainable and accessible to non-developers.

---

6. How does GlideAjax work?

Client Scripts run in the browser and have no direct database access. GlideAjax solves this by allowing a client script to make an asynchronous call to the server, execute a Script Include, and return a result.

The flow:

1. Client Script creates a GlideAjax object referencing a client-callable Script Include.
2. It passes parameters and defines a callback function.
3. The server executes the Script Include method and returns a value.
4. The callback function receives the response and updates the UI.

Why asynchronous matters: A synchronous call would freeze the browser until the server responds. Async calls let the user continue interacting with the form while waiting for the result — critical for performance and user experience.

Key design rule: The Script Include must have Client callable checked and extend AbstractAjaxProcessor.

---

3. Server-Side Scripting

7. What are Business Rules, and how do you decide when to use them?

Business Rules are server-side scripts that execute automatically in response to database operations (insert, update, delete, query) on a specific table.

Execution timings:

• Before — runs before the record is written. Use to modify field values before saving.
• After — runs after the record is saved. Use to trigger related record creation or notifications.
• Async — runs in a background thread after the transaction. Use for non-critical tasks like sending emails or updating audit tables — avoids slowing the user's transaction.
• Display — runs when a record is loaded for display. Use to set g_scratchpad values for client scripts.

When to use:

• Record lifecycle logic that must always fire regardless of how the record is modified (UI, API, import).

When NOT to use:

• Don't create Business Rules for every small task — each rule adds to transaction overhead.
• Avoid recursive rules (a rule that triggers itself) without careful conditions.
• Complex, reusable logic belongs in Script Includes, not Business Rules.

---

8. Difference between Business Rules, Script Includes, and Flow Designer

These three are often confused but serve distinct purposes:

• Business Rules — tightly coupled to the database record lifecycle. They fire on insert/update/delete. Best for logic that must execute as part of a record transaction.
• Script Includes — reusable libraries of server-side logic. They don't fire automatically; they're called by other scripts (Business Rules, REST APIs, Flow Designer actions). They promote DRY (Don't Repeat Yourself) design.
• Flow Designer — a low-code/no-code tool for building event-driven workflows using triggers, conditions, and actions. Best for process orchestration (approvals, notifications, multi-step workflows) and ideal for reducing scripting in business processes.

When to prefer code over flows: When logic is highly conditional, recursive, or performance-sensitive. When to prefer flows: When the process needs to be understood and maintained by non-developers, or when it involves cross-table orchestration.

---

9. What is a Script Include, and how do you design one properly?

A Script Include is a reusable server-side JavaScript library. It exists to centralize logic so it can be called from Business Rules, REST APIs, Scheduled Jobs, Flow Designer, and GlideAjax.

Design principles:

• Single responsibility — each Script Include should do one thing well.
• Client callable — only mark this if the Script Include will be called via GlideAjax; otherwise leave it unchecked for security.
• Use Class.create() pattern for object-oriented structure.
• Naming — use clear, descriptive names (e.g., IncidentUtils, UserLookupHelper).
• Keep methods small and testable.
• Avoid hardcoding sys_ids or table names — use system properties or constants.

A poorly designed Script Include with hundreds of unrelated methods becomes unmaintainable. Design for cohesion and reuse.

---

10. Explain synchronous vs asynchronous Business Rules

• Synchronous (Before/After) — execute within the same database transaction as the user's action. The user waits until these complete. If a sync rule errors, it can roll back the transaction.
• Asynchronous — execute in a background thread after the transaction commits. The user does not wait. They run via the Event Queue.

When to use async:

• Sending emails or notifications
• Updating statistical or reporting tables
• Any operation that's non-critical to the immediate transaction

Common async mistakes:

• Reading the "current" record in an async rule — by the time it runs, the record may have changed. Use previous and current carefully.
• Assuming async rules fire immediately — they may be delayed if the scheduler is busy.
• Putting critical data integrity logic in async rules — if it fails silently, data becomes inconsistent.

---

4. Security and Access Control

11. What are ACLs, and how do they work?

Access Control Lists (ACLs) are the primary security mechanism in ServiceNow. They control who can read, write, create, or delete records and fields.

Types:

• Table ACLs — control access to entire records (e.g., can a user read any incident?)
• Field ACLs — control access to specific fields on a record (e.g., can a user see the salary field?)

Evaluation:

• ACLs are evaluated server-side and cannot be bypassed through the browser.
• They evaluate in order: most specific wins (field > table).
• Checks can include roles, conditions (field value checks), and scripts (for complex logic).

Performance note: Scripted ACLs run on every record load, so keep scripts lightweight. Avoid database queries inside ACL scripts where possible.

---

12. Difference between ACLs and UI Policies

This is a critical distinction:

  ACL UI Policy

Enforced server-side	✅ Yes	❌ No
Can be bypassed via API/direct URL	❌ No	✅ Yes
Controls data access	✅ Yes	❌ No
Controls UI visibility	Indirectly	✅ Yes

UI Policies hide or make fields mandatory in the browser only. A savvy user or API call can still submit hidden fields. ACLs are the real security gate — they're enforced regardless of how data is submitted. The rule is: never rely on UI Policies for security.

---

5. Data Handling and APIs

13. What is GlideRecord, and how is it used?

GlideRecord is ServiceNow's server-side API for interacting with the database. It's the primary way to query, insert, update, and delete records programmatically.

Basic operations:

• Query: gr.addQuery(), gr.query(), then loop with gr.next()
• Insert: set fields, then gr.insert()
• Update: query a record, modify fields, then gr.update()
• Delete: gr.deleteRecord()

Best practices:

• Always use encoded queries for complex conditions (copy from list filter).
• Use setLimit() to restrict large result sets.
• Never query inside a loop (N+1 problem) — batch lookups instead.
• Use gr.setWorkflow(false) when bulk-updating to suppress Business Rules if appropriate.
• Use indexes — query on indexed fields (sys_id, number, u_indexed_field) for performance.

Common pitfall: gr.get(sys_id) is faster than addQuery('sys_id', sys_id).query() for single record lookups.

---

14. What are REST APIs in ServiceNow, and how have you used them?

ServiceNow supports both inbound and outbound REST integrations.

• Inbound REST (Table API, Scripted REST): External systems call ServiceNow. The out-of-box Table API exposes CRUD on any table. Scripted REST APIs let you define custom endpoints with specific logic, response shapes, and authentication.
• Outbound REST (REST Message): ServiceNow calls external systems. Configured via REST Message records and triggered from Business Rules, Flow Designer, or scripts.

Authentication methods: Basic auth, OAuth 2.0, API keys, mutual TLS.

Best practices:

• Always validate and sanitize inbound payloads.
• Use proper HTTP status codes in Scripted REST responses.
• Handle errors gracefully — log failures, don't expose stack traces externally.
• Use OAuth over Basic auth for production integrations.
• For high-volume integrations, consider async processing via the Import Set framework.

---

6. Performance and Best Practices

15. How do you optimize performance in ServiceNow?

Performance optimization spans client, server, and database layers:

Server-side:

• Avoid synchronous Business Rules for non-critical logic — use async.
• Move reusable logic to Script Includes to avoid redundant code execution.
• Use GlideAggregate instead of GlideRecord for count/sum operations.
• Set query limits and avoid unbounded queries.

Database:

• Query on indexed fields.
• Use encoded queries rather than building complex addQuery chains.
• Avoid queries in loops.

Client-side:

• Minimize Client Scripts — prefer UI Policies.
• Use GlideAjax asynchronously, never synchronously.
• Avoid multiple g_form.getValue() calls where one would do.

General:

• Reduce unnecessary Business Rules — audit and clean up rules with overlapping conditions.
• Use system properties and caching for frequently read configuration values.
• Monitor slow queries using the Performance Analytics and slow query logs.

---

16. How do you debug issues in ServiceNow?

A methodical debugging approach:

1. gs.log / gs.info / gs.debug — add logging to server-side scripts. View output in System Log > Application Logs.
2. Script Debugger — step through server-side scripts in real time with breakpoints. Available under System Diagnostics.
3. Background Scripts — run ad-hoc server-side code to test logic or inspect data without deploying changes.
4. JavaScript Log (browser console) — for client-side script debugging. Use jslog() or console.log().
5. System Diagnostics > Stats — check transaction times, slow queries, and memory usage.
6. Field Watcher — trace which scripts are modifying a specific field.
7. Session Debug — enable debug logging for a specific session to capture detailed output.

Good debugging is methodical: reproduce the issue consistently, isolate the layer (client vs server vs database), then narrow down with targeted logging.

---

7. Update Sets and Deployment

17. What are Update Sets, and what are their limitations?

Update Sets are containers that capture configuration changes made in a ServiceNow instance so they can be moved to other instances (e.g., Dev → Test → Prod).

What gets captured:

• Scripts, Business Rules, Client Scripts, UI Policies
• Form layouts, lists, views
• Workflows and Flow Designer flows (partially)

What does NOT get captured:

• Data (records in tables like incidents, users, companies)
• System properties (must be migrated manually or via Data Transfer)
• Some complex application components
• Attachments

Best practices:

• Use meaningful naming (e.g., PROJ-123 - Incident Routing Logic).
• One feature per Update Set — avoid "catch-all" sets.
• Always preview before committing in target instances.
• Use Application Repository (source control) for scoped app development instead of Update Sets.

---

18. How do you handle conflicts during deployment?

1. Preview the Update Set in the target instance first — this reveals conflicts before committing.
2. Review skipped records — these are records that already exist in the target and differ from the incoming version.
3. For each conflict, decide: accept incoming, keep current, or manually merge.
4. After committing, run regression tests on affected functionality.
5. Document what was manually resolved for the deployment record.
6. Have a rollback strategy — either a backup of the target instance or a reverse Update Set that undoes changes.

In mature environments, use CI/CD pipelines with the Now Platform's source control integration to automate and formalize this process.

---

8. Scenario-Based Questions

19. How would you design a custom application in ServiceNow?

A structured approach:

1. Requirements analysis — understand the process, actors, data, and integrations. Map it to existing platform capabilities before building anything custom.
2. Data model design — identify entities, extend existing tables where appropriate (especially Task for process records), and define relationships.
3. Security planning — define roles, ACLs, and data visibility rules upfront. Security is much harder to retrofit.
4. UI design — design forms and list views. Use OOB UI components before building custom ones.
5. Business logic placement — use Flow Designer for process orchestration, Script Includes for reusable logic, Business Rules for record lifecycle hooks.
6. Integration design — plan inbound/outbound APIs, authentication, and error handling.
7. Testing — unit test scripts via Background Scripts, integration test with ATF (Automated Test Framework).
8. Deployment — package in a scoped application, deploy via Application Repository or Update Sets, with proper change management.

---

20. How do you decide whether to use code or configuration?

This is a philosophy question as much as a technical one.

Prefer configuration when:

• A UI Policy, Flow Designer action, or OOB feature can do the job.
• The logic is straightforward and maintainable by non-developers.
• You want upgrade safety — configured artifacts are less likely to break on platform upgrades.

Prefer code when:

• Logic is too complex or conditional for declarative tools.
• Performance requires fine-grained control.
• You need reusable, testable components (Script Includes).

Guiding principles:

• Configuration is easier to hand off, document, and maintain across team skill levels.
• Code should be clean, scoped, and purposeful — not a workaround for not understanding the platform.
• Always ask: "Is there a platform-native way to do this?" before writing a script.
• The best ServiceNow developers know the platform well enough to avoid writing code unnecessarily.

---

These 20 answers cover the full breadth of what a ServiceNow developer interview typically tests — from platform fundamentals and scripting to security, performance, and architectural thinking.

These answers are generated by Claude.