Mastering Scenario-Based ServiceNow Interview Questions: Your Definitive Guide

So, you’re gearing up for a ServiceNow interview, huh? You’ve probably brushed up on the core concepts, the latest release notes, and maybe even a few scripting basics. But let’s be real: knowing definitions isn’t enough anymore. Interviewers, especially for seasoned roles, want to see how you *think* and *apply* your knowledge in practical, real-world scenarios. They want to know you can troubleshoot, implement, and innovate, not just recite.

That’s where scenario-based questions come in. They’re designed to test your problem-solving skills, your understanding of ServiceNow’s architecture, and your ability to choose the “best practice” solution. This article is your comprehensive companion, dissecting common scenario-based ServiceNow interview questions, offering detailed, human-like explanations, and arming you with the insights to ace that interview.

I. Getting Started: Your ServiceNow Journey & Identity Management

1. Your ServiceNow Version Experience

Question: Which is the current version you are working on in ServiceNow? From which version did you start working?

The Gist: This is an ice-breaker, but it also tells the interviewer about your exposure and adaptability. Being up-to-date shows continuous learning, while a range of versions indicates experience across different upgrade cycles and feature sets.

Answer Example: “Currently, I’m actively working on a Washington D.C. instance, leveraging its latest features like Next Experience enhancements and updated integration capabilities. My journey with ServiceNow began back in the Rome release, and since then, I’ve had hands-on experience through upgrades and new implementations across San Diego, Tokyo, Utah, Vancouver, and now, Washington D.C.”

2. User & Group Management: The Bedrock of Security

Access control is fundamental. How you manage users, groups, and their permissions speaks volumes about your understanding of security and efficient administration.

User and Group Table Names

Question: What is the user table name? What is the group member table name?

Answer:

• User table: sys_user
• Group member table: sys_user_group
• (Bonus: Group table: sys_user_group. It seems the reference mixed user group with group member, so clarifying the group table itself is sys_user_group, and the group member table – the many-to-many relationship linking users to groups – is sys_user_grmember.)

Permissions: Users vs. Groups – Best Practices!

Question: Can we add permissions to users and groups? Which is the best practice?

The Gist: This tests your understanding of role management principles, especially scalability and maintainability.

Answer: “Absolutely, we can add roles (which represent permissions) directly to individual users and also to groups. While both are technically possible, the undeniable best practice is to assign roles to groups, not directly to individual users. This approach has several significant advantages:

• Scalability: Managing roles for hundreds or thousands of users becomes a nightmare if done individually. With groups, you assign roles once to the group, and all members inherit them.
• Maintainability: When an employee’s role changes, or they leave the organization, you simply add or remove them from the relevant groups. Their permissions are automatically updated, significantly reducing manual effort and the risk of orphaned permissions.
• Consistency: It ensures all users within a specific functional team or role have the exact same permissions.

You can manage these relationships manually through the UI or programmatically using scripts with GlideRecord.”

Scripting User, Group, and Role Assignments

Being able to script these actions demonstrates a deeper level of technical proficiency, often required for integrations, data migrations, or complex automation.

How to Create a User Account Using Script

Question: How to create user account using script?

Answer: “You can use GlideRecord to interact with the sys_user table to create a new user record programmatically. Here’s a common example:”

var userGr = new GlideRecord('sys_user');
userGr.initialize(); // Prepares a new record for insertion
userGr.user_name = 'jdoe'; // Unique user ID/login name
userGr.first_name = 'John';
userGr.last_name = 'Doe';
userGr.email = 'jdoe@example.com';
// Optional: Set password, roles, active status, etc.
// userGr.active = true;
// userGr.locked_out = false;
userGr.insert(); // Commits the new record to the database
gs.info('User ' + userGr.user_name + ' created with Sys ID: ' + userGr.sys_id);
        

How to Create a Group Using Script

Question: How to create group using script?

Answer: “Creating a group follows a similar pattern, interacting with the sys_user_group table.”

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Testing Team'; // The name of the group
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Sys ID of the manager user
newGr.email = 'testing@tcs.com';
newGr.description = 'This group is for testing purposes.';
newGr.insert();
gs.info('Group ' + newGr.name + ' created with Sys ID: ' + newGr.sys_id);
        

How to Add Permissions (Roles) to User/Group Account Using Script

Question: How to add permissions to user/group account using script?

Answer: “This is where understanding the underlying many-to-many relationship tables is crucial. When a role is added, a record is created in either sys_user_has_role (for users) or sys_group_has_role (for groups).”

For a User:

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
userRole.setValue('user', '62826bf03710200044e0bfc8bcbe5df1'); // Sys ID of the user
userRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Sys ID of the role (e.g., 'itil')
userRole.insert();
gs.info('Role assigned to user.');
        

For a Group:

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
grpRole.setValue('group', '477a05d153013010b846ddeeff7b1225'); // Sys ID of the group
grpRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Sys ID of the role
grpRole.insert();
gs.info('Role assigned to group.');
        

How to Add and Remove Group Members Using Script

Question: How to add and remove group member from group using script?

Answer: “This involves the sys_user_grmember table, which acts as the junction for the many-to-many relationship between users and groups.”

Adding a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
grMem.user = '62826bf03710200044e0bfc8bcbe5df1'; // Sys ID of the user
grMem.group = '477a05d153013010b846ddeeff7b1225'; // Sys ID of the group
grMem.insert();
gs.info('User added to group.');
        

Removing a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1'); // Query for the specific user
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // Query for the specific group
grMem.query();
if (grMem.next()) { // If the record exists
    grMem.deleteRecord(); // Delete the record
    gs.info('User removed from group.');
} else {
    gs.info('User was not a member of the specified group.');
}
        

3. User Experience and Interaction

ServiceNow User Interfaces

Question: How many user interfaces are there in Snow?

Answer: “Historically, ServiceNow has evolved its user interfaces. We’ve seen UI15, UI16, and now the contemporary ‘Next Experience’. Each iteration brought improvements in usability, performance, and modern design.”

Current User Information (Client vs. Server)

Question: How to get the current logged in user system id in the client side? How to get the current logged in user system id in the server side?

Answer: “Understanding the client-side vs. server-side context is critical for scripting.

• Client-Side: You’d use g_user.userID; (e.g., in Client Scripts, UI Policies with scripts). This gives you the user’s Sys ID.
• Server-Side: You’d use gs.getUserID(); (e.g., in Business Rules, Script Includes, Workflows).

Checking Group Membership

Question: How to check if the current logged user is the member of a particular group or not?

Answer: “On the server-side, gs.getUser().isMemberOf('group name'); is your go-to function. It returns true if the logged-in user is a member of the specified group (by name), and false otherwise.”

if (gs.getUser().isMemberOf('ITIL Group')) {
    gs.info('Current user is a member of the ITIL Group.');
} else {
    gs.info('Current user is NOT a member of the ITIL Group.');
}
        

There’s also gs.getUser().isMemberOf(groupSysID) if you prefer using the group’s Sys ID.

Impersonation

Question: What is impersonation?

Answer: “Impersonation is a powerful testing tool in ServiceNow. It allows an administrator or a user with the ‘impersonator’ role to log in as another user without needing their credentials. This is invaluable for testing access controls, UI experiences, and specific workflows from the perspective of different user roles.”

User Preferences

Question: What is user preference?

Answer: “User preferences allow individual users to customize their ServiceNow experience, such as their homepage, list layouts, date formats, or notification settings. The key thing is that these preferences are *user-specific* – they only impact that particular user and do not affect anyone else globally on the instance.”

4. Special User Types and Roles

Web Services User

Question: What is mean by web services user in the User account?

Answer: “A ‘Web Services User’ in ServiceNow is a special type of user account typically created to grant third-party applications or external systems access to the ServiceNow instance via web services (like REST or SOAP). The critical distinction is that these users are generally set up with the ‘Web service access only’ checkbox enabled, meaning they cannot log in interactively to the ServiceNow UI as a regular user. They exist purely for programmatic interaction.”

Security Admin Role

Question: Which role is required to work on access control?

Answer: “To work with Access Control Lists (ACLs), which are fundamental to platform security, you typically need the security_admin role. This role is highly privileged and often requires elevation in production instances to prevent unauthorized changes to security settings.”

User Delegation

Question: What exactly user delegation means in ServiceNow?

Answer: “User delegation in ServiceNow allows an employee to temporarily assign their tasks, approvals, or notifications to another user. This is incredibly useful when the primary user is unavailable, perhaps on vacation or leave. The delegated user gains the necessary permissions to act on behalf of the original user for the specified period and task types, ensuring business continuity.

For example, if a manager goes on holiday, they can delegate their approval responsibilities for change requests or catalog items to a team lead. This way, critical workflows don’t stall. You configure this directly from the original user’s profile under the ‘Delegates’ related list, where you can specify the delegate’s name, start/end dates, and what exactly is delegated (assignments, notifications, approvals).”

II. Core ITIL Processes: Incident, Problem, and Change Management

These three are the pillars of IT Service Management (ITSM) and frequently intertwined in real-world scenarios. Interviewers often probe your understanding of their definitions, relationships, and how to manage them.

1. Defining the ITIL Trifecta

What is an Incident?

Question: What is incident?

Answer: “An incident represents an unplanned interruption to an IT service or a reduction in the quality of an IT service. Essentially, something that *was* working, is now *not* working as expected. Its primary goal is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations.”

What is a Problem?

Question: What is problem?

Answer: “A problem is the underlying cause of one or more incidents. While an incident focuses on restoring service, a problem aims to identify, understand, and ultimately eliminate the root cause of recurring incidents. If the same issue happens repeatedly to one employee, or if multiple employees experience the same issue concurrently (leading to multiple incidents), that’s a strong indicator of an underlying problem. Often, a ‘parent incident’ is created for the first occurrence, and subsequent, related incidents are linked as ‘child incidents’.”

What is a Change Request?

Question: Can we create a change request from incident? What is the relationship between incident, problem and change management?

Answer: “Yes, absolutely! A Change Request (CR) represents the addition, modification, or removal of anything that could have a direct or indirect effect on IT services. Its purpose is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, minimizing adverse impact to service quality.

The relationship is symbiotic:

• Incident to Problem: If an incident keeps recurring, or a single incident points to a deeper issue, a Problem record is often created from that incident to investigate the root cause.
• Problem to Change: Once the root cause of a problem is identified, a Change Request is frequently raised from the Problem record to implement a permanent solution (e.g., patching a server, upgrading software).
• Incident to Change: Sometimes, an incident might immediately indicate that a change is required, even without a formal problem investigation. For example, if a critical bug is found that requires an emergency fix, a Change Request might be initiated directly from the incident to deploy that fix.

In essence, an incident is the ‘what’ (service is down), a problem is the ‘why’ (what’s causing it), and a change is the ‘how’ (how do we fix it permanently or improve things).”

2. Scripting ITIL Records

Being able to create these records programmatically is crucial for integrations, automated processes, or bulk data operations.

How to Create Incident Record Using Script

Question: How to create incident record using script?

Answer: “We use GlideRecord on the incident table, populating the necessary fields.”

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // Sys ID of the caller
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys ID of the Configuration Item
gr.short_description = 'Test record created via script';
gr.description = 'This incident was automatically generated by a script for testing purposes.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys ID of the assignment group
gr.insert();
gs.info('Incident ' + gr.number + ' created.');
        

How to Create Problem Record Using Script

Question: How to create problem record using script?

Answer: “Similar to incidents, we target the problem table.”

var gr = new GlideRecord('problem');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94';
gr.category = 'software';
gr.subcategory = 'operating_system';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Recurring OS crash after update';
gr.description = 'Users report recurring system crashes after the latest OS patch. Investigating root cause.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();
gs.info('Problem ' + gr.number + ' created.');
        

How to Create Change Request Using Script

Question: How to create change request using script?

Answer: “For change requests, we interact with the change_request table.”

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'software_release';
gr.subcategory = 'patch_deployment';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Deploy OS hotfix for critical vulnerability';
gr.description = 'Deployment of hotfix XYZ to address CVE-12345 in production servers.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.type = 'normal'; // Or 'standard', 'emergency'
gr.insert();
gs.info('Change Request ' + gr.number + ' created.');
        

3. Advanced ITIL Scenarios & Logic

These scenarios are gold for interviewers, as they require combining conceptual understanding with practical scripting in Business Rules.

Scenario 1: Parent-Child Incident Closure

Question: Write a logic for whenever a parent incident is closed, all its child incidents should also get closed.

Answer: “This is a classic use case for an After Business Rule. When the parent incident’s state changes to ‘Closed’, we need to query for its child incidents and update their state accordingly.”

// Business Rule Configuration:
// When: After
// Update: true
// Table: Incident [incident]
// Condition: current.state.changesTo(7) && current.parent.nil() // Assuming '7' is the state value for 'Closed' and it's a parent.

if (current.state == 7 && current.parent.nil()) { // Check if the current incident is closed and is a parent
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id); // Find all incidents where this incident is the 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.comments = 'Closed automatically as parent incident ' + current.number + ' was closed.';
        grChild.update(); // Update the child incident
        gs.info('Child incident ' + grChild.number + ' closed due to parent closure.');
    }
}
        

Scenario 2: Preventing Closure with Open Tasks

Question: There is an incident and that incident has associated 2 tasks. When you try to close that incident, if any incident task is open, the employee should not be able to close the incident. Similarly for problem, and change request.

Answer: “This requires a Before Business Rule to prevent the update before it’s committed. The logic involves checking for related open tasks and aborting the action if any are found.”

// Business Rule Configuration (for Incident):
// When: Before
// Update: true
// Table: Incident [incident]
// Condition: current.state.changesTo(7) // When trying to close the incident

// This logic can be adapted for Problem (problem_task) and Change (change_task)
// by changing the table name in GlideRecord.

if (current.state == 7) { // Check if the incident is being closed
    var grTask = new GlideRecord('incident_task');
    grTask.addQuery('incident', current.sys_id); // Find tasks related to this incident
    grTask.addQuery('state', '!=', 3); // Assuming '3' is the state value for 'Closed' for incident tasks
    grTask.query();

    if (grTask.hasNext()) { // If any open tasks are found
        gs.addErrorMessage('Cannot close the incident because there are open tasks. Please close all incident tasks first.');
        current.setAbortAction(true); // Prevents the incident from being closed
        gs.info('Incident ' + current.number + ' closure aborted due to open tasks.');
    }
}
        

Scenario 3: Problem Closure & Associated Incidents

Question: Whenever a problem is closed, the associated incidents will also get closed.

Answer: “This is another After Business Rule, similar to the parent-child incident closure, but this time linking problems to incidents.”

// Business Rule Configuration:
// When: After
// Update: true
// Table: Problem [problem]
// Condition: current.state.changesTo(7) // When the problem is closed

if (current.state == 7) { // If the problem is being closed
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Find incidents linked to this problem
    grIncident.addQuery('state', '!=', 7); // Only close incidents that aren't already closed
    grIncident.query();

    while (grIncident.next()) {
        grIncident.state = 7; // Set the incident state to Closed
        grIncident.close_notes = 'Incident closed automatically as its related problem ' + current.number + ' was closed.';
        grIncident.update(); // Update the incident
        gs.info('Incident ' + grIncident.number + ' closed due to problem closure.');
    }
}
        

III. Deep Dive into Tables and Fields: The Building Blocks of Your Instance

Understanding how data is structured and fields behave is crucial for any ServiceNow developer or administrator. These questions test your architectural knowledge.

1. Table Classifications

Out-of-the-Box vs. Custom Tables

Question: Give me some names of out of the box tables?

Answer: “Out-of-the-box (OOB) tables are those provided by ServiceNow by default, part of the base platform or standard applications. They don’t have custom prefixes like x_ or u_. Great examples include incident, problem, change_request, sys_user, sys_user_group, cmdb_ci, and task. Tables starting with x_ typically belong to a scoped application, while u_ indicates a custom global table.”

Base Tables

Question: What are some of the base tables?

Answer: “Base tables are those that do not extend any other table themselves but are extended by many other tables. They act as the foundational parent for a whole hierarchy of tables. Prime examples are task and cmdb_ci. The task table, for instance, is extended by Incident, Problem, Change, Service Request, etc., inheriting common fields and behaviors.”

Task Tables

Question: Give me some examples of tasks tables?

Answer: “Task tables are those that extend the base task table. This includes incident, problem, change_request, sc_req_item (Requested Item), sc_task (Catalog Task), and sysapproval_approver (Approval record).”

2. Table Creation and Extension

ACLs on Table Creation

Question: Whenever we create a table how many access controls will get created?

Answer: “By default, when you create a new table through the table wizard, ServiceNow automatically creates four Access Control Lists (ACLs) for that table: for read, write, create, and delete operations. This happens because the ‘Create access controls’ checkbox is usually checked by default. If you uncheck it, no ACLs will be created, and you’d have to create them manually to control access.”

Auto-Numbering a Field

Question: How to create number field, like incident number?

Answer: “To enable auto-numbering for a field (like ‘Incident Number’ or ‘Change Request Number’), you configure it within the table’s ‘Controls’ tab. You define a ‘Prefix’ (e.g., ‘INC’, ‘CHG’), set the ‘Number of digits’, and crucially, check the ‘Auto-number’ checkbox. This ensures that upon record insertion, a unique, sequential number is automatically generated based on your defined pattern.”

Impact of Table Extension

Question: What happens when you extend a table?

Answer: “When you extend a table (making it a child table of another), several things happen:

• Field Inheritance: The child table inherits all fields from its parent table. Importantly, these inherited fields are not physically duplicated in the child table’s database schema; they are simply accessible. This means ‘sys’ fields (like sys_id, sys_created_on, etc.) are only stored once on the parent, but available to all children.
• No New ‘sys’ Fields: The child table will not create its own set of ‘sys’ fields, as it inherits them from the parent.
• ‘Class’ Field: A new field called Class is added to the parent table. This field identifies the specific table extension (e.g., ‘incident’, ‘problem’) of a record stored in the parent table. If a parent table is extended by many children, it still only has one Class field; its value changes depending on which child table the record originated from.

Extending tables promotes code reusability and simplifies data modeling.”

3. Field Types and Properties

Common Field Types

Question: Can you give me 10 field types?

Answer: “Certainly! ServiceNow offers a rich variety of field types:

1. String (for short text)
2. Multi-line text (for longer text)
3. Reference (links to another table)
4. List (links to multiple records in another table)
5. Choice (dropdown with predefined options)
6. Email
7. Date/Time
8. Date
9. Boolean (true/false checkbox)
10. Integer
11. Journal (for chronological activity entries)
12. Attachment (for file uploads)
13. Price, Currency, HTML, URL, Decimal… and many more!

Display Fields

Question: Can we make 2 fields as display in one table?

Answer: “No, definitely not! You should only ever designate one field as the ‘Display’ field for any given table. The display value is what ServiceNow uses to represent a record in reference fields, lists, and search results. Having two display fields would lead to confusion, inconsistent behavior, and potentially incorrect data display across the platform.”

Where Tables are Stored

Question: All tables will be stored where?

Answer: “Information about all tables, including their definitions and properties, is stored in the sys_db_object table. This is essentially the meta-data table for all tables in your instance.”

Setting Default Values

Question: How to set a default value on a field?

Answer: “You can set a default value for a field directly in its dictionary entry. This value will automatically populate the field whenever a new form for that table is opened. This can be a static value, a JavaScript expression, or a system property.”

Calculated Values

Question: What is calculated value?

Answer: “A calculated value is a dictionary property that allows you to dynamically populate a field’s value based on a script or expression, typically using the current object or other field values. The value isn’t stored in the database but calculated on the fly when the record is retrieved or displayed. It’s useful for fields that are derived from other data and don’t need persistent storage, though it can impact performance if not used judiciously.”

Attributes

Question: What are attributes, name some of the attributes that you used?

Answer: “Attributes are powerful properties that you can add to a dictionary entry (a field or a table’s collection record) to modify its behavior or appearance beyond standard dictionary settings. They offer a flexible way to customize how fields function. Some commonly used attributes include:

• no_email: Prevents a field’s value from being included in email notifications.
• no_attachment: Disables attachments for a specific field or the entire table (on the collection record).
• no_add_me: Hides the ‘Add Me’ button in reference fields.
• tree_picker=true: Displays a hierarchical tree picker for reference fields.
• read_only=true: Makes the field read-only.
• max_length=X: Sets the maximum character limit for string fields.
• glide_list: Makes a string field behave like a list collector.

Collection Field

Question: What is collection field on table? How to enable/disable attachment on the form using attributes?

Answer: “Every table has a special dictionary entry of type ‘Collection’. This entry doesn’t represent a specific field but rather the table itself. Any attributes or properties applied to this ‘Collection’ entry affect the entire table’s behavior, not just one field.

To enable/disable attachments for an entire form/table, you would go to the dictionary entry for the ‘Collection’ type for that table and add or remove the no_attachment attribute. If no_attachment is present, attachments are disabled. If it’s absent, they’re typically enabled (assuming no other global settings prevent them).”

4. Table Types: Temporary, Remote, and Relationships

Temporary vs. Normal Tables

Question: What is the difference between temporary and normal table? Can we increase the retention period in the temp table?

Answer: ”

• Normal Tables: Store data permanently in the ServiceNow database. Records persist until explicitly deleted.
• Temporary Tables: Designed for transient data. They typically extend the import_set_row table, and their data is automatically purged after a short retention period, usually 7 days by default. They are often used for staging data from integrations or for temporary calculations.

Yes, you can increase the retention period for temporary tables. This is done by configuring Archive Rules or Table Rotation on the specific temporary table. Archive rules allow you to define criteria for moving or deleting old data after a specified time, effectively extending or customizing the ‘temporary’ aspect.”

Remote vs. Normal Tables

Question: What is the difference b/w remote table and normal tables?

Answer: ”

• Normal Tables: Data is stored directly within your ServiceNow instance’s database. When you query a normal table, you’re accessing data that resides locally.
• Remote Tables: Don’t store data within your ServiceNow instance. Instead, they provide a virtual connection to an external data source (like a database, an external system via an API, or a file). When you query a remote table, ServiceNow fetches the ‘live’ data from the external system at that moment. This is useful for integrating with external systems without duplicating data.

Table Relationships

Question: What is one-to-one and one-to-many table in ServiceNow?

Answer: “ServiceNow supports various relationship types:

• One-to-Many Relationship: This is the most common. One record in the ‘parent’ table can be associated with multiple records in the ‘child’ table, but each child record can only be linked to one parent.
  • Example: A User can have multiple Incidents, but each Incident is assigned to only one User (via the ‘Caller’ or ‘Assigned To’ field).
• Many-to-Many Relationship: A record in Table A can be associated with multiple records in Table B, and vice-versa. This is implemented using a ‘junction’ or ‘related list’ table that stores the pairings.
  • Example: An Incident can be associated with multiple Knowledge Articles, and a Knowledge Article can be associated with multiple Incidents. Similarly, an Incident can be associated with multiple Groups, and a Group with multiple Incidents (though the reference uses ‘Assigned Group’ as one-to-many, an incident can *involve* many groups). A better example is a user belonging to multiple groups, and a group having multiple users (sys_user_grmember is the junction table here).
• One-to-One: Less common and often achieved by extending a table or simply adding fields directly. For instance, a User has one User Preference record.

Ways to Create a Record

Question: In how many ways we can create a record in snow table?

Answer: “ServiceNow offers a multitude of ways to create records, catering to different needs:

1. ServiceNow UI Form: Manually filling out and submitting a form.
2. Record Producers: User-friendly forms in the Service Portal that create records in target tables.
3. Inbound Email Actions: Parsing incoming emails to create or update records (e.g., creating incidents from emails).
4. Scripting (GlideRecord): Programmatically creating records using server-side JavaScript.
5. Import Sets: Importing data from external sources (Excel, CSV, XML, JDBC) to create multiple records.
6. Integrations (REST/SOAP Web Services): External systems sending data to create records in ServiceNow.
7. Flow Designer / Workflow activities: Automated creation of records as part of a larger process.
8. Scheduled Jobs: Scripted jobs that run periodically to create records.

Current Object

Question: What is current object? How to set the field values on the current form?

Answer: “The current object is a server-side JavaScript object that represents the record being inserted, updated, or deleted. It holds the values of all fields on that record. It’s primarily used in Business Rules, Script Includes, and Workflow scripts.

To set field values on the current form (or record) using server-side script:

• For most field types, use: current.setValue('field_name', value); or directly current.field_name = value;
• For Reference fields, if you’re setting the value using the Sys ID, use setValue or direct assignment with the Sys ID: current.setValue('caller_id', 'sys_id_of_user'); or current.caller_id = 'sys_id_of_user';
• If you want to set a Reference field’s *display* value (and have ServiceNow resolve the corresponding Sys ID), use: current.setDisplayValue('caller_id', 'John Doe');. This is convenient when you only have the display name and need the system to find the Sys ID.

IV. Controlling Form Behavior: UI Policies, Data Policies, and Dictionary Overrides

These mechanisms are fundamental to ensuring data integrity, user experience, and enforcing business rules. Mastering their differences and appropriate use cases is key.

1. Field Control Mechanisms

Making Fields Mandatory/Read-Only

Question: In how many ways we can make a field mandatory, read only?

Answer: “You have several powerful ways to control a field’s mandatory and read-only status, each with its own scope and execution context:

1. Dictionary Properties: Directly in the field’s dictionary entry, you can check ‘Mandatory’ or ‘Read Only’. This is a global setting that applies everywhere unless overridden.
2. Dictionary Overrides: Allows a child table to have different dictionary properties (like mandatory/read-only) for an inherited field compared to its parent.
3. UI Policies: Client-side logic that can make fields mandatory, read-only, or hidden based on conditions on the form. They apply only to the UI.
4. Data Policies: Can enforce mandatory/read-only constraints at both the client-side (UI) and server-side (all data sources), ensuring data integrity regardless of how the record is created or updated.
5. Client Scripts (g_form methods): Programmatically making fields mandatory or read-only using client-side JavaScript (e.g., g_form.setMandatory('field_name', true);, g_form.setReadOnly('field_name', true);).
6. ACLs (Access Control Lists): While not primarily for mandatory/read-only, ACLs can effectively make a field read-only by denying write access.

2. Reference Qualifiers

Question: What are reference qualifiers, and their types? And explain each one in detail and what is the difference in simple and dynamic, dynamic and advanced, simple and advanced.

Answer: “Reference Qualifiers are essential tools used to restrict the data displayed in ‘Reference’ and ‘List’ type fields. They filter the available choices, ensuring users only see relevant records.

There are three main types:

Simple Reference Qualifier

• Description: This is the most straightforward type. You define a fixed encoded query string, similar to what you’d use in a list filter.
• Example: If a ‘Caller’ reference field on the Incident form should only show active users, you’d set the simple reference qualifier to active=true.
• How to Use: In the dictionary entry of the reference field, select ‘Simple’ for the Reference Qualifier, and then add your filter condition.
• Key Difference from Advanced/Dynamic: It’s static; the filter doesn’t change based on other fields or complex logic.

Dynamic Reference Qualifier

• Description: This type uses a pre-defined ‘Dynamic Filter Option’ (created via System Definition > Dynamic Filter Options). These options encapsulate a script that generates a query, allowing the filter to adapt based on system context, or even the current user’s properties.
• Example: Displaying only incidents assigned to the current user’s assignment group. You’d have a Dynamic Filter Option that runs a script to get gs.getUser().getMyGroups().
• How to Use: Create a Dynamic Filter Option first, then select ‘Dynamic’ for the Reference Qualifier in the field’s dictionary entry and choose your defined dynamic filter.
• Key Difference from Simple: It’s dynamic, but the logic is pre-packaged in a reusable filter option. It doesn’t allow for inline scripting as Advanced does.
• Key Difference from Advanced: Dynamic filters are about *reusability* of a common dynamic query, often driven by current user context. Advanced is for *ad-hoc complex, form-specific* scripting.

Advanced Reference Qualifier (JavaScript Reference Qualifier)

• Description: This is the most flexible and powerful type. You write custom JavaScript code directly in the dictionary entry to generate the query string. This allows for highly complex, context-aware filtering based on multiple fields on the current form, system properties, or intricate logic.
• Example: Filtering the ‘Configuration Item’ field to show only CIs related to the selected ‘Category’ *and* that are ‘Operational’. Or, showing users in the same department as the currently selected ‘Requester’.

  
  javascript: "category=" + current.category + "^operational_status=1"
                  

  (Note: current.category here refers to the value of the category field on the current form).

• How to Use: Select ‘Advanced’ for the Reference Qualifier and enter your JavaScript code, ensuring it returns an encoded query string.
• Key Difference from Simple: It’s fully dynamic and allows complex logic based on the form’s current state. Simple is static.
• Key Difference from Dynamic: You write the script directly in the dictionary entry, making it specific to that field. Dynamic filters are reusable components that can be applied to multiple fields.

3. Dependent Values in Dictionary

Question: What is dependent value?

Answer: “Dependent values are used to create cascaded dropdown menus, where the choices available in one field (the dependent field) are filtered based on the selection made in another field (the parent field). This dramatically improves user experience and data accuracy by presenting only relevant options.

Steps to Configure Dependent Values:

1. Identify Parent and Dependent Fields: For example, ‘Category’ (parent) and ‘Subcategory’ (dependent). Both must be Choice fields.
2. Configure the Parent Field: Ensure your parent field has its list of choices defined (e.g., Hardware, Software, Network for Category).
3. Configure the Dependent Field:
   • Go to the dictionary entry of the dependent field (e.g., Subcategory).
   • Set the Dependent Field attribute to the parent field (e.g., Category).
   • Now, when defining choices for the dependent field, you’ll see a ‘Dependent value’ column. For each subcategory choice, you link it to a specific value of the parent category.

Example:

• Parent Field: Category (Choices: Hardware, Software)
• Dependent Field: Subcategory

Subcategory Choices Definition:

With this setup, if a user selects ‘Hardware’ for Category, only ‘Laptop’ and ‘Desktop’ will appear in the Subcategory dropdown.”

4. Dictionary Overrides

Question: What are dictionary overrides? What are all the properties we can override in dictionary overrides?

Answer: “Dictionary Overrides are incredibly useful. They allow you to modify the behavior or attributes of an inherited field specifically for a child table, without affecting the parent table or other child tables. Essentially, you’re “overriding” the dictionary definition of the parent field for a particular child.

For example, the ‘Priority’ field might have a default value of ‘4’ in the base task table. However, for incidents, you might want its default to be ‘5’. A dictionary override on the incident table for the ‘Priority’ field would achieve this.

You can override many properties, including:

• Default value: Provide a different initial value.
• Read only: Make an inherited field read-only (or editable).
• Mandatory: Make an inherited field mandatory (or optional).
• Choice list: Define a different set of choices for a choice list field.
• Reference qualifier: Apply a different filter to a reference field.
• Column label: Change the display label of the field.
• Active: Make the field active or inactive on the form.

5. UI Policies vs. Data Policies: Client-Side vs. Server-Side Enforcement

UI Policies

Question: What are UI policies? What is global check box in UI policies? What is reverse if false in UI policies? What is onload check box in UI policy? What is inherit checkbox? Can you write script in UI policy? Which are all the cases where UI policy cannot be converted as data policy?

Answer: “UI Policies are client-side logic used to dynamically control the visibility, mandatory status, and read-only status of fields, and to show/hide related lists on a form, based on specific conditions. They execute in the browser.

• Global Checkbox: When checked, the UI Policy applies to all views of the form. If unchecked, you’ll be prompted to select a specific ‘View’ for the policy to apply to.
• Reverse if false: If selected, when the UI Policy conditions evaluate to ‘false’, any actions applied when the condition was ‘true’ are automatically reversed. For example, if a field was made mandatory when true, it becomes optional again when false. This saves you from writing separate UI Policies for the ‘else’ condition.
• On Load Checkbox: If checked, the UI Policy conditions and actions are evaluated and applied immediately when the form loads. If unchecked, the policy only triggers when a field value changes on the form that matches the conditions.
• Inherit Checkbox: When checked, the UI Policy will also apply to child tables of the table it’s defined on. This is useful for consistent UI behavior across extended tables.
• Scripting in UI Policy: Yes, you can write client-side JavaScript in a UI Policy by checking the ‘Run scripts’ checkbox. This allows for more complex logic that goes beyond simple field manipulation, executing scripts when the UI Policy conditions are met (e.g., displaying alerts, calling other client-side functions). You’ll have an ‘Execute if true’ and ‘Execute if false’ script block.

Cases where a UI Policy CANNOT be converted to a Data Policy:
Data Policies are more about data integrity across all sources, not just the UI. Therefore, if a UI Policy is doing any of the following, it cannot be converted:

• Controlling data visibility (e.g., hiding a field entirely).
• Controlling views.
• Controlling related lists (showing/hiding them).
• Executing client-side scripts (Data Policies run server-side).

Data Policies

Question: What are data policies? Can we convert UI policy as data policy?

Answer: “Data Policies are similar to UI Policies in that they control mandatory, read-only, and visible states of fields. However, their crucial distinction is that they enforce data integrity across all data sources, not just the UI. They run on both the client-side (forms) and server-side (imports, web services, scripts). This ensures consistency regardless of how data enters or is modified in the system.

Yes, you can convert a compatible UI Policy into a Data Policy. You’d open the UI Policy record and typically find a related link or button like ‘Convert to Data Policy’. However, as mentioned, this is only possible if the UI Policy isn’t performing actions specific to the client-side UI (like hiding fields or running client scripts).”

6. Other Form Elements

Application Menus

Question: What are application menus?

Answer: “Application Menus (or Applications) are the top-level categories in the ServiceNow navigation pane (e.g., ‘Incident’, ‘Service Catalog’, ‘System Definitions’). They organize related modules (links to lists, forms, or other pages) and make them accessible to end-users based on their roles. We create modules *within* application menus to expose our forms and lists.”

Process Flow

Question: What is process flow?

Answer: “The process flow (also known as a ‘process formatter’ or ‘stage formatter’) is that visual indicator at the top of a record form (like Incident, Problem, Change) that shows the current state or stage of the record in a workflow. It provides a quick, intuitive glance at where the record stands in its lifecycle, helping users understand the progress of a task or request.”

Data Lookup Rules

Question: What are data lookup roles?

Answer: “Data Lookup Rules (often configured in ‘Data Lookup Definitions’) are a declarative way to populate field values on a form based on the values of other fields, without writing any code. They use a lookup table to match conditions and set values. For example, you could define a Data Lookup Rule that automatically sets the ‘Priority’ of an incident based on its ‘Impact’ and ‘Urgency’ values, saving agents manual effort and ensuring consistency.”

V. Conclusion: Beyond the Answers

Navigating ServiceNow interview questions, especially the scenario-based ones, requires more than just memorization. It demands a deep understanding of the platform’s architecture, best practices, and the ability to articulate your thought process. Remember, the interviewer isn’t just looking for the right answer, but also for *how* you arrive at it, your considerations for scalability, performance, and maintainability.

Keep practicing, keep building, and stay curious about new features and best practices. Your journey in ServiceNow is one of continuous learning, and demonstrating that passion will set you apart. Good luck!