Conquering the Interview: Your Top 10 ServiceNow Incident Management Questions Explained

Navigating the ServiceNow interview landscape can feel like a maze, especially when it comes to a foundational process like Incident Management. It’s not just about knowing definitions; it’s about understanding the ‘why’ and ‘how’ behind every concept. Interviewers want to gauge your practical knowledge, your problem-solving skills, and your ability to apply ServiceNow’s capabilities to real-world scenarios.

In this detailed guide, we’re going to dive deep into the top 10 ServiceNow Incident Management interview questions. We’ll break down the concepts, provide practical explanations, explore scripting examples, and even sprinkle in some troubleshooting tips. By the end, you’ll not only have solid answers but also a deeper understanding that will impress any interviewer.

1. The Core Difference: Incident vs. Problem & Their Relationship

This is often the very first question, and for good reason. It establishes your fundamental understanding of ITSM processes within ServiceNow.

What is an Incident in ServiceNow?

Think of an Incident as an unexpected disruption to a service or a reduction in its quality. It’s something that just broke, right now, preventing someone from doing their job. Your laptop suddenly won’t connect to the Wi-Fi? That’s an incident. The company’s main website is down? A critical incident! The goal of Incident Management is to restore the normal service operation as quickly as possible, minimizing the business impact.

Interview Relevance: Interviewers want to see that you understand the immediate, reactive nature of incidents and their primary objective: restoration.

What is a Problem in ServiceNow?

Now, imagine that same Wi-Fi issue keeps happening to you every other day, or worse, it’s affecting a whole department. That’s no longer just an incident; it’s a Problem. A problem is the underlying cause of one or more incidents. It might not be immediately obvious, and it requires a more investigative, proactive approach to identify, diagnose, and resolve the root cause. The goal here isn’t just a quick fix but preventing future occurrences.

If multiple people are experiencing the same issue simultaneously, you might still open individual incidents, but then you’d link them to a single “Parent Incident” or, more appropriately, a “Problem” that explains the widespread impact.

Interview Relevance: This question tests your ability to differentiate between symptoms (incidents) and root causes (problems), showcasing your understanding of proactive service management.

Can we create a Problem Record from an Incident?

Absolutely, and this is a crucial link in effective ITSM! If an issue is repeatedly causing incidents, or if an incident’s resolution requires a deeper investigation into its root cause, you would create a Problem record directly from that incident. This linking ensures traceability and helps the problem management team understand the impact of the underlying issue.

Practical Scenario: A user reports an incident about slow application performance. After a temporary workaround, the issue recurs a week later. The support engineer, noticing this pattern, can initiate a Problem record directly from one of these incidents to investigate the server, network, or application code for a permanent solution.

2. Navigating Resolutions: Incident to Change Management

Sometimes, fixing an incident isn’t a quick tweak; it requires a structured modification to the environment. That’s where Change Management comes in.

Can we create a Change Request from an Incident?

Yes, unequivocally! This is another vital relationship in ServiceNow. If resolving an incident requires a modification to a configuration item (CI), application code, or any part of the IT infrastructure that could introduce risk, a Change Request (CR) must be initiated. For example, if a bug in a software application is causing repeated incidents, the fix might involve deploying a new version of the software. This deployment is a change and needs to follow a formal change management process to minimize disruption.

Practical Scenario: An incident is opened because a critical server is running out of disk space. The immediate resolution might be to clear some temporary files. However, the long-term, permanent solution is to upgrade the server’s storage. This storage upgrade is a significant change that would require a Change Request, ensuring proper planning, approval, and execution to avoid further incidents.

Interview Relevance: This demonstrates your understanding of the broader ITSM lifecycle and how different processes integrate to maintain service stability and integrity.

3. Mastering Record Creation: GlideRecord Scripting

ServiceNow isn’t just about clicks; it’s also about code. GlideRecord is your go-to API for server-side database interactions.

How to Create Incident, Problem, and Change Request Records using Script?

Creating records programmatically in ServiceNow is often done using GlideRecord, which allows you to interact with the database tables. It’s a fundamental skill for any ServiceNow developer or advanced administrator.

Here’s how you’d do it for Incident, Problem, and Change Request records. The pattern is largely the same, just targeting different tables:

Creating an Incident Record using Script:

var gr = new GlideRecord('incident');
gr.initialize(); // Prepares a new, empty record for insertion
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // Sys_id of the caller user
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys_id of the Configuration Item
gr.short_description = 'Test Incident created via script';
gr.description = 'This incident was automatically generated for testing purposes.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys_id of the Assignment Group
var sysId = gr.insert(); // Inserts the record into the database and returns its sys_id
gs.info("Incident " + sysId + " created successfully.");

Creating a Problem Record using Script:

var gr = new GlideRecord('problem');
gr.initialize();
// Note: caller_id is not a standard field on the base problem table,
// but can be added via dictionary override or if problem extends incident.
// For demonstration, we'll keep common fields.
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Test Problem created via script';
gr.description = 'This problem investigates recurring antivirus issues.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
var sysId = gr.insert();
gs.info("Problem " + sysId + " created successfully.");

Creating a Change Request using Script:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.type = 'normal'; // Standard, Emergency, or Routine
gr.category = 'Software';
gr.subcategory = 'Application Upgrade';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Test Change Request for application update';
gr.description = 'This change is for deploying a new version of the XYZ application.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
// It's good practice to set other mandatory fields if they exist, like 'state' or 'requested_by'
gr.state = -5; // Example: New state for a Normal Change
var sysId = gr.insert();
gs.info("Change Request " + sysId + " created successfully.");

Interview Relevance: Demonstrates your core scripting skills, understanding of GlideRecord, and how to programmatically interact with ServiceNow data.

4. Handling Escalations: Parent-Child Incident Management & Automation

When an outage impacts many users, linking incidents is crucial for efficient management and communication.

How to close all child incidents when a parent incident is closed?

This is a common requirement to streamline incident resolution. When a major incident (often designated as a parent) is resolved, all related minor incidents (children) should ideally be closed automatically. This prevents agents from having to manually close dozens or hundreds of individual tickets.

You’d typically implement this using an After Business Rule on the Incident table.

// Business Rule Configuration:
// Table: Incident
// When: After
// Update: true
// Condition: current.state.changesTo(7) && current.parent.nil()

// Script:
if (current.state == 7 && current.parent.nil()) { // Ensure it's a parent incident being closed (state 7 usually means Closed)

    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id); // Query for all child incidents linked to this parent
    grChild.addQuery('state', '!=', 7); // Only close children that aren't already closed
    grChild.query();

    while (grChild.next()) {
        grChild.state = 7; // Set the state to Closed
        grChild.close_notes = "Closed automatically as parent incident " + current.number + " was closed.";
        grChild.update(); // Update the child incident
    }
}

Interview Relevance: Demonstrates your ability to use Business Rules for automation, understanding of parent-child relationships, and practical scripting for process efficiency.

5. Ensuring Completion: Managing Associated Tasks Before Closure

In complex incidents, problems, or changes, tasks are often assigned. It’s best practice to ensure all sub-tasks are complete before the parent record is closed.

How to prevent closing an Incident, Problem, or Change Request if associated tasks are still open?

This is a critical validation to maintain data integrity and ensure all necessary work is completed. If tasks are still open, it implies work is outstanding, and the parent record shouldn’t be considered fully resolved. This is typically implemented using a Before Business Rule or an onSubmit Client Script (though a Business Rule is preferred for server-side validation).

Example for Incident:

// Business Rule Configuration:
// Table: Incident
// When: Before
// Update: true
// Condition: current.state.changesTo(7) // Assuming 7 is the 'Closed' state

// Script:
if (current.state == 7) { // Check if the incident is being set to Closed
    var grTask = new GlideRecord('incident_task');
    grTask.addQuery('incident', current.sys_id);
    grTask.addQuery('active', true); // Check for active (open) tasks
    // Alternatively, you could check for specific states that are considered 'open'
    // grTask.addQuery('state', 'IN', '1,2'); // Assuming 1=Open, 2=Work in Progress

    grTask.query();

    if (grTask.hasNext()) { // If any active tasks are found
        gs.addErrorMessage('Cannot close this incident because there are still open associated tasks. Please close all incident tasks first.');
        current.setAbortAction(true); // Prevents the record from being saved/closed
    }
}

This same logic can be adapted for Problem Tasks (problem_task table, querying by problem field) and Change Tasks (change_task table, querying by change_request field).

Interview Relevance: Showcases your understanding of data validation, workflow enforcement, and the use of Business Rules to maintain process integrity.

6. The Foundation: Understanding Task Table & Table Extensions

ServiceNow’s architecture is built on a robust table hierarchy, and the Task table is central to ITSM.

What are some examples of task tables? What happens when you extend a table?

The Task table (task) is a foundational table in ServiceNow. It serves as a base class for many core ITSM applications because many IT processes involve managing “tasks” that need to be completed, such as Incidents, Problems, and Changes. These “child” tables inherit fields and behaviors from the parent Task table.

• Examples of tables extending the Task table:
  • Incident (incident)
  • Problem (problem)
  • Change Request (change_request)
  • Service Catalog Request (sc_request)
  • Service Catalog Item (sc_req_item)
  • Catalog Task (sc_task)

What happens when you extend a table?

When you extend a table in ServiceNow, the child table “inherits” fields, access controls, and some behaviors from the parent table. Here’s what goes down:

1. Field Inheritance: The child table automatically gets all the fields from the parent table. These inherited fields are not physically duplicated in the child table’s database schema; they are stored in the parent table. This is a huge benefit for database efficiency and consistency.
2. System Fields: Core system fields like sys_id, sys_created_on, sys_updated_by, etc., are inherited from the base sys_metadata table (and then through sys_table and task). They don’t get recreated in the child table.
3. sys_class_name Field: A crucial field, sys_class_name, is added to the parent table. This field identifies the specific table that the record belongs to. So, an Incident record stored in the Task table will have its sys_class_name set to ‘incident’. If a table extends multiple tables (e.g., Incident extends Task, which extends sys_metadata), it will only have one sys_class_name field on its highest parent (Task, in this case), indicating its specific class.
4. Performance: This architecture can be very efficient. When you query a child table, ServiceNow often performs a join operation with the parent table(s) behind the scenes to retrieve all fields.

Interview Relevance: This question assesses your understanding of ServiceNow’s underlying database architecture, object-oriented concepts, and the benefits of table extension for reusability and maintainability.

What is the relationship between Incident, Problem, and Change Management?

This ties everything together! These three processes are distinct yet deeply interconnected, forming the backbone of effective ITSM:

• Incident to Problem: An incident (a service disruption) can expose an underlying problem (the root cause). If an incident recurs or requires deep investigation, a Problem record is created from the incident.
• Problem to Change: Once a problem’s root cause is identified, the permanent fix often requires a change to the IT infrastructure (e.g., software patch, hardware upgrade). This leads to the creation of a Change Request from the Problem.
• Change to Incident/Problem (indirect): A Change Request aims to implement a solution. If a change is unsuccessful, it might cause new incidents or even exacerbate existing problems. Conversely, successful changes prevent future incidents and resolve problems.
• Incident to Change (direct): Sometimes, a simple incident fix requires a controlled change (e.g., resetting a critical system that needs specific approval). In such cases, a Change Request can be created directly from an Incident without a Problem in between.

They work together to move from reactive firefighting (Incident) to proactive root cause elimination (Problem) to controlled system modification (Change), ensuring service stability and improvement.

Interview Relevance: Demonstrates a holistic view of ITSM and how these modules collaborate to deliver robust service management.

7. Controlling the User Experience: UI Policies vs. Data Policies

Making forms user-friendly and data consistent is vital. UI and Data Policies are key tools for this.

In how many ways can we make a field mandatory, read-only, or hidden? What are UI Policies and Data Policies?

You can control field behavior in several ways in ServiceNow:

1. Dictionary Entry: For fundamental, always-on control (e.g., mandatory field from creation).
2. Dictionary Overrides: To modify dictionary settings for child tables (more on this below).
3. UI Policies: Client-side logic for dynamic form behavior.
4. Data Policies: Server-side (and optionally client-side) logic for data consistency regardless of input source.
5. Client Scripts (g_form API): For complex client-side interactions, including g_form.setMandatory(), g_form.setReadOnly(), g_form.setVisible().
6. ACLs (Access Control Lists): Primarily for security, not UI control, but can make a field appear ‘read-only’ if the user lacks write access.

What are UI Policies?

UI Policies are client-side scripts that control form behavior based on conditions. They allow you to make fields mandatory, read-only, visible/hidden, or even show/hide related lists, all without writing a single line of JavaScript (unless you enable “Run scripts”).

• Client-Side: They execute in the browser.
• Use Cases: Dynamic form adjustments, like making “Resolution Notes” mandatory only when the incident state changes to “Resolved.”
• Key UI Policy Checkboxes:
  • On Load: If checked, the UI Policy conditions and actions are evaluated when the form first loads. If unchecked, they only run when a field value changes after load.
  • Reverse if false: If checked, when the conditions are no longer met, the actions defined by the UI Policy are reversed (e.g., a field made mandatory becomes optional again). If unchecked, you need to define explicit “false” actions.
  • Global: If checked, the UI Policy applies to all views of the form. If unchecked, you can specify a particular view.
  • Inherit: If checked, the UI Policy also applies to tables that extend the current table (child tables).
  • Run scripts: Enables “Execute if true” and “Execute if false” script fields for complex client-side logic beyond simple field visibility/mandatory/read-only.

What are Data Policies?

Data Policies are primarily server-side rules that enforce data consistency across all data input sources (forms, import sets, web services, scripts, etc.). They can also apply to the client-side.

• Server-Side (and Client-Side): They ensure data integrity regardless of how the data enters ServiceNow.
• Use Cases: Ensuring that “Caller” is always mandatory for an incident, even if it’s created via an integration or script, not just the form.
• Enforce UI policies on Client: If checked, the Data Policy also applies its mandatory/read-only rules on the client-side, similar to a UI Policy.
• Can we convert a UI Policy to a Data Policy? Yes, often, by opening a UI Policy and selecting the “Convert to Data Policy” UI Action. However, there are limitations:
  • You cannot convert UI Policies that control data visibility (hide/show fields), related lists, views, or contain custom scripts. Data Policies are about mandatory/read-only enforcement, not UI manipulation.

Interview Relevance: Crucial for understanding how to manage form behavior, enforce data quality, and distinguish between client-side user experience and server-side data integrity.

8. Refining Data Input: Reference Qualifiers & Dependent Values

Guiding users to select the right data is a hallmark of a well-designed ServiceNow instance.

What are Reference Qualifiers, their types, and the differences between them?

Reference Qualifiers are powerful tools used on Reference and List type fields to filter the records displayed to the user. This ensures users only see relevant options, improving data accuracy and user experience.

There are three main types:

1. Simple Reference Qualifier:
   • Description: The most straightforward type. You define a fixed query string that applies every time the field is accessed.
   • Example: In a “Assigned To” field referencing the User table, you might only want to show active users.
     
     active=true
   • When to Use: For static filters that don’t change based on other form values.
2. Dynamic Reference Qualifier:
   • Description: Uses a pre-defined “Dynamic Filter Option” script to generate the query dynamically. This allows for more complex, reusable filtering logic without embedding JavaScript directly into the field’s dictionary entry.
   • Example: Showing only users who are members of the same assignment group as the current incident. You’d create a “Dynamic Filter Option” that contains the logic to fetch current user’s groups.
   • When to Use: When you need context-aware filtering that can be reused across multiple fields, or when the logic is too complex for a Simple qualifier but can be encapsulated.
3. Advanced Reference Qualifier (JavaScript Reference Qualifier):
   • Description: Provides the most flexibility. You write a JavaScript function that returns a query string. This function can access other fields on the form (current object), user session data, and perform complex calculations.
   • Example: Showing only configuration items (CIs) that belong to the caller’s company AND are currently ‘Operational’.
     
     javascript: 'company=' + current.caller_id.company + '^operational_status=1'
   • When to Use: For highly dynamic, context-specific filtering that depends on multiple conditions or requires server-side lookups (though try to avoid heavy server-side processing for performance).

Differences:

• Simple vs. Dynamic: Simple is fixed, Dynamic uses a pre-defined script for reusability and more complex context.
• Dynamic vs. Advanced: Dynamic leverages existing script logic (Dynamic Filter Options), while Advanced lets you write bespoke JavaScript directly in the qualifier for unique scenarios.
• Simple vs. Advanced: Simple is static; Advanced is fully dynamic and programmable.

What are Dependent Values?

Dependent values are a way to filter the choices available in one Choice field (the “dependent” field) based on the selection made in another Choice field (the “parent” field). This creates cascaded dropdowns, making forms cleaner and more intuitive.

Example:

1. Parent Field: Category (choices: Hardware, Software, Network).
2. Dependent Field: Subcategory (dependent on Category).

When you define choices for Subcategory, you link them to specific Category values.

• If Category = Hardware, Subcategory choices might be: Laptop, Desktop, Printer.
• If Category = Software, Subcategory choices might be: Operating System, Application, Database.

How to Configure: In the dictionary entry of the dependent field, you set the “Dependent field” attribute to the parent field. Then, when defining the choices for the dependent field, you specify which parent value each choice is associated with.

Interview Relevance: Demonstrates your understanding of advanced field configurations, improving usability, and ensuring data accuracy.

9. Advanced Field Personalization: Dictionary Overrides & Attributes

Sometimes, a field needs to behave differently depending on the table. Dictionary Overrides and Attributes are your tools.

What are Dictionary Overrides? What properties can be overridden?

A Dictionary Override allows a field inherited from a parent table to have a different value or behavior on a specific child table without affecting other child tables or the parent itself. This is incredibly useful for tailoring inherited fields.

Example: The ‘Priority’ field is inherited from the Task table. On the Incident table, you might want its default value to be ‘2 – High’, while on the Problem table, you might want it to be ‘4 – Low’ (as problems are less urgent than incidents). A dictionary override lets you do this.

Properties you can override:

• Default Value: Change the initial value displayed.
• Mandatory: Make it mandatory or optional.
• Read Only: Make it editable or read-only.
• Active: Activate or deactivate the field on the child table.
• Column label: Change the display name.
• Reference Qualifier: Apply a different filter to reference fields.
• Choices: For choice fields, you can add or modify choices specific to the child table.
• And many more, depending on the field type.

Interview Relevance: Shows your grasp of table inheritance and how to customize platform behavior for specific applications.

What are Attributes? Name some you have used. How to enable/disable attachment on the form using attributes?

Attributes are key-value pairs that can be set on dictionary entries to modify a field’s behavior or appearance in various contexts (e.g., forms, lists). They are like hidden settings that influence how the platform renders or processes a field.

Some common attributes:

• no_attachment: Prevents attachments from being added to records via this specific field (or globally if on a collection field).
• no_email: Excludes this field from email notifications.
• tree_picker: Displays a hierarchical picker for reference fields (useful for CMDB CIs).
• edge_encryption_enabled: Indicates if a field is encrypted.
• max_length: Overrides the default maximum length for string fields (though usually set directly).
• glide_list: For fields that allow multiple selections (e.g., Watch List).

Enabling/Disabling Attachments:

To control attachments globally for a table (e.g., the Incident table):

1. Go to the dictionary entry for the table itself (e.g., incident).
2. Find the “Attributes” field.
3. To disable attachments: Add no_attachment=true.
4. To enable attachments (or ensure they’re enabled if previously disabled): Remove the no_attachment attribute.

This applies to the entire record, not just a specific field within it. Sometimes, you’ll see this attribute on the “Collection” record of the table (the dictionary entry representing the table itself), rather than on an individual field.

Interview Relevance: Highlights your knowledge of advanced platform configuration and how to fine-tune field behaviors beyond basic UI settings.

10. Diverse Avenues: Multiple Ways to Create Records

ServiceNow offers flexibility in how data enters the system.

In how many ways can we create a record in ServiceNow?

ServiceNow is designed to integrate and automate, so there are indeed several ways to create records:

1. Via Form (Manual Entry): The most common method, where users fill out a form in the UI.
2. Record Producers (Service Catalog): Users submit a form from the Service Catalog, which then creates a record (e.g., an incident, a request, a change).
3. Email: Inbound Email Actions can parse incoming emails and create records (e.g., an email to the help desk creates an incident).
4. GlideRecord Scripting: Programmatically create records using server-side JavaScript (as demonstrated in Question 3).
5. Import Sets (Excel/CSV): Importing data from external files, often for bulk creation or migration.
6. Web Services (REST/SOAP API): External systems can create records in ServiceNow via API calls. This is fundamental for integrations.
7. Flow Designer / Workflow: Automated processes can create records as part of a larger workflow.
8. Service Portal Widgets: Custom widgets built for the Service Portal can create records using client-side and server-side scripting.

Interview Relevance: Demonstrates a comprehensive understanding of ServiceNow’s capabilities, its integration points, and how data flows into the platform from various sources.

Bonus Question: Process Flow & Data Lookup Roles

What is Process Flow?

Process flow (also known as the “Process Flow Formatter”) is a UI element that visually indicates the current stage or state of a record (like an Incident, Problem, or Change) on a form. It typically appears as a series of breadcrumbs or steps at the top of the form, guiding the user through the lifecycle of the record. It helps users quickly understand where the record stands in its workflow.

Example: For an Incident, the process flow might show “New > Assigned > In Progress > Resolved > Closed.”

What are Data Lookup Rules?

Data Lookup Rules provide a simple, codeless way to set field values based on conditions defined by other field values on a form. They operate by comparing values in a source table with values on the current record and then populating target fields. They are managed through dedicated “lookup” tables (e.g., Priority Lookup Rules, Assignment Lookup Rules).

Example: A Priority Data Lookup Rule might automatically set an incident’s Priority to “Critical” if its “Impact” is “High” and its “Urgency” is “High”. Another rule could assign an incident to a specific “Assignment Group” based on its “Category” and “Subcategory.”

Interview Relevance: These questions gauge your knowledge of practical platform features that enhance usability and automate routine tasks without custom coding.

Wrapping Up: Your Path to ServiceNow Interview Success

Phew! That was a deep dive, wasn’t it? Incident Management is more than just logging tickets; it’s a dynamic, interconnected process within the broader ServiceNow ecosystem. By mastering these top 10 (and a few bonus!) interview questions, you’re not just memorizing answers – you’re building a robust understanding of how ServiceNow truly works.

Remember, the goal in an interview isn’t just to parrot definitions. It’s to demonstrate practical application, an understanding of the ‘why,’ and how you’d leverage ServiceNow to solve real-world challenges. When discussing scripts, explain the purpose of each line. When talking about policies, highlight their impact on user experience and data integrity. Always be ready to provide a practical example.

Keep exploring, keep practicing, and go conquer that ServiceNow interview!