My current focus is on the Washington DC release. It’s the latest one, and it’s always exciting to explore the new features and enhancements it brings to the platform. I’m always keen to stay updated with the newest functionalities.

Interview Relevance: This question assesses your familiarity with the current landscape of ServiceNow. Be honest and mention the version you’re most comfortable with, or the one your current organization is using. If you’re not on the absolute latest, you can mention the version you are on and express your interest in learning the newest release.

I’ve had the opportunity to work with ServiceNow across several releases, starting from Rome. Since then, I’ve progressed through San Diego, Tokyo, Utah, Vancouver, and now, as mentioned, Washington DC. This progression has given me a solid understanding of how the platform has evolved over time.

Interview Relevance: This question gauges your experience and how long you’ve been actively involved with ServiceNow. It also shows your ability to adapt to platform upgrades.

Absolutely, you can add permissions to both users and groups in ServiceNow. Permissions are primarily managed through roles. You can assign roles directly to users or, more commonly and effectively, assign them to groups. Users then inherit the roles assigned to the groups they are a member of.

Best Practice: The recommended best practice is to manage permissions via groups. This approach significantly simplifies administration. When an employee joins or leaves an organization, you primarily manage their group memberships. If an employee leaves and is removed from a group, all the roles associated with that group are automatically removed from the user. This prevents orphaned roles and ensures security compliance. You can achieve this through manual assignment or scripting using GlideRecord.

Interview Relevance: This probes your understanding of ServiceNow’s security model and best practices for administration. Demonstrating knowledge of group-based role assignment shows maturity in your approach.

The table name for users in ServiceNow is sys_user.

Interview Relevance: A fundamental question to ensure you know the core tables.

The table that links users to groups is called sys_user_grmember.

Interview Relevance: Similar to the user table, this checks your knowledge of core relationship tables.

You can create a user account programmatically using a GlideRecord script. Here’s a practical example:

var userGr = new GlideRecord('sys_user');
userGr.initialize(); // Prepares a new record
userGr.username = 'jdoe'; // Sets the username
userGr.firstname = 'John'; // Sets the first name
userGr.lastName = 'Doe'; // Sets the last name
userGr.email = 'jdoe@example.com'; // Sets the email address
userGr.insert(); // Inserts the new record into the sys_user table

gs.info('User jdoe created successfully.'); // Optional: log success
            

Interview Relevance: This demonstrates your scripting ability within ServiceNow, which is crucial for automation and custom development.

Similar to creating users, you can create groups using GlideRecord. Here’s how:

var newGr = new GlideRecord('sys_user_group');
newGr.initialize(); // Prepare a new group record
newGr.name = 'IT Support - Tier 1'; // Set the group name
// The manager field is a reference to the sys_user table. Ensure you use a valid sys_id.
// You can find a user's sys_id by right-clicking their name in a form and selecting "Copy sys_id".
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Example sys_id for a manager
newGr.email = 'itsupporttier1@example.com'; // Set the group email
newGr.description = 'Handles initial IT support requests.'; // Add a description
newGr.insert(); // Insert the new group record

gs.info('Group IT Support - Tier 1 created successfully.');
            

Interview Relevance: Again, this tests your scripting skills and understanding of how to manipulate core ServiceNow data.

Adding permissions (roles) involves interacting with the tables that manage user-role and group-role relationships.

Adding a Role to a User:

When a role is added to a user, a record is created in the sys_user_has_role table. You can add a role to a user with a script like this:

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
// Replace '62826bf03710200044e0bfc8bcbe5df1' with the actual sys_id of the user
userRole.setValue('user', '62826bf03710200044e0bfc8bcbe5df1');
// Replace '2831a114c611228501d4ea6c309d626d' with the actual sys_id of the role
userRole.setValue('role', '2831a114c611228501d4ea6c309d626d');
userRole.insert();
gs.info('Role added to user.');
            

Adding a Role to a Group:

When a role is added to a group, a record is created in the sys_group_has_role table. You can add a role to a group with a script:

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
// Replace '477a05d153013010b846ddeeff7b1225' with the actual sys_id of the group
grpRole.setValue('group', '477a05d153013010b846ddeeff7b1225');
// Replace '2831a114c611228501d4ea6c309d626d' with the actual sys_id of the role
grpRole.setValue('role', '2831a114c611228501d4ea6c309d626d');
grpRole.insert();
gs.info('Role added to group.');
            

Interview Relevance: This question dives deeper into scripting and your understanding of how ServiceNow manages permissions at a granular level.

User delegation in ServiceNow allows one user to perform tasks and act on behalf of another user within the organization. This is incredibly useful when the primary user is unavailable, such as during vacations, leaves, or extended absences.

The delegated user gains the necessary permissions to access resources and execute tasks that would normally be available to the original user. For instance, if an employee is on holiday, they can delegate their approval responsibilities for certain workflows to a colleague. This ensures that critical business processes continue smoothly without any interruption.

How it’s configured: The original user can configure delegation by navigating to their user record, scrolling down to the “Delegates” related list, and clicking “New.” Here, they can specify the delegate (the person they want to delegate to), set the start and end dates for the delegation, and crucially, choose which specific permissions they want to delegate (e.g., approvals, notifications, assignments).

Interview Relevance: This tests your knowledge of features that support business continuity and operational efficiency within ServiceNow.

Managing group memberships is a common task, and scripting can automate it.

Adding a Group Member:

To add a user to a group, you’ll insert a record into the sys_user_grmember table.

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
// Provide the sys_id of the user and the group
grMem.user = '62826bf03710200044e0bfc8bcbe5df1'; // User's sys_id
grMem.group = '477a05d153013010b846ddeeff7b1225'; // Group's sys_id
grMem.insert();
gs.info('User added to group.');
            

Removing a Group Member:

To remove a user from a group, you first need to query for the existing membership record and then delete it.

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1'); // User's sys_id
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // Group's sys_id
grMem.query();
if (grMem.next()) {
    grMem.deleteRecord(); // Delete the found record
    gs.info('User removed from group.');
} else {
    gs.info('User not found in the specified group.');
}
            

Interview Relevance: Demonstrates practical scripting skills for user and group administration.

ServiceNow has evolved its user interface over time. Historically, we’ve seen:

• UI15 (an older, but still sometimes encountered interface)
• UI16 (the more modern classic interface)
• Now Experience UI / Next Experience UI (the latest, sleek, and more intuitive interface).

The Next Experience UI is the focus for current development and user adoption due to its enhanced user experience and modern design principles.

Interview Relevance: Shows awareness of the platform’s UI evolution and current trends.

A web services user in ServiceNow is a special type of user account that is granted access solely for third-party applications to connect and interact with ServiceNow programmatically. These users do not have the ability to log into the ServiceNow graphical user interface (GUI) as a regular end-user would.

Their purpose is to facilitate integrations, data synchronization, and automated workflows between ServiceNow and other systems using web service protocols (like REST or SOAP). They are typically assigned specific roles that grant them access to the necessary APIs and data, but not to the user interface itself.

Interview Relevance: This question checks your understanding of ServiceNow’s integration capabilities and security considerations for system-to-system communication.

On the client-side (within client scripts, UI policies, or UI scripts), you can access the current logged-in user’s sys_id using the global JavaScript variable g_user.

Specifically, it’s accessed as:

var currentUserId = g_user.userID;
gs.log('Current user ID (client-side): ' + currentUserId); // For client scripts, use g_scratchpad or console.log for debugging
            

Interview Relevance: Essential for client-side scripting where you need to reference the current user for actions or conditions.

On the server-side (within business rules, script includes, or workflow scripts), you use the gs (GlideSystem) object to get the current user’s sys_id.

var currentUserId = gs.getUserID();
gs.info('Current user ID (server-side): ' + currentUserId);
            

Interview Relevance: Crucial for server-side logic where you need to identify the user performing an action or needing access.

On the server-side, you can use the gs.getUser() object combined with the isMemberOf() method.

// Replace 'ITIL User' with the actual name of the group
var isMember = gs.getUser().isMemberOf('ITIL User');

if (isMember) {
    gs.info('The current user is a member of the ITIL User group.');
} else {
    gs.info('The current user is NOT a member of the ITIL User group.');
}
            

For client-side, you’d typically use g_user.hasRole() if checking for roles, or pass group membership information to the client via the g_scratchpad object from a server-side script.

Interview Relevance: This is a common requirement for implementing role-based or group-based access control and logic.

To create, modify, or manage Access Control Lists (ACLs) in ServiceNow, you need the security_admin role.

Interview Relevance: Demonstrates understanding of ServiceNow’s security administration and the principle of least privilege.

Impersonation in ServiceNow is a powerful feature that allows an administrator or a user with appropriate permissions (typically impersonator role) to log in and act as another user. This is primarily used for testing purposes, troubleshooting user-specific issues, or verifying that a user has the correct access and permissions.

When impersonating, you see the platform exactly as the user you’re impersonating would see it, allowing for accurate replication of their experience and issues.

Interview Relevance: Shows your understanding of how to effectively debug and test ServiceNow configurations from a user’s perspective.

User preferences in ServiceNow are settings that an individual user can configure to personalize their experience on the platform. These preferences are unique to each user and do not affect other users’ experiences.

Examples include:

• Personalizing list layouts (columns displayed, sorting order).
• Setting default form views.
• Configuring notification preferences.
• Language settings.

When a user changes a preference, it’s stored in their user record (specifically in related tables like sys_user_preference) and only impacts their own view and interaction with ServiceNow.

Interview Relevance: Highlights your understanding of user personalization and the distinction between user-specific and global settings.

An incident in ServiceNow is essentially an unplanned interruption to an IT service or a reduction in the quality of an IT service. If an employee can’t access their email, their printer stops working, or a critical application is unresponsive, these are all examples of incidents.

The primary goal of incident management is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations, thus ensuring that the best possible levels of service quality and availability are maintained. When such an interruption occurs, a user typically creates an incident ticket to get support.

Interview Relevance: This is a foundational ITSM concept. A clear, concise definition is expected.

A problem in ServiceNow is the underlying cause of one or more incidents. If the same incident is repeatedly occurring for the same employee, or if similar incidents are happening to multiple employees concurrently, it suggests a persistent underlying issue.

The purpose of problem management is to identify the root cause of these recurring incidents and provide a permanent solution or a workaround to prevent them from happening again. In cases where multiple incidents stem from the same root cause, one problem record is created, and all those incidents are linked to it as ‘child incidents’ or ‘incident children’ of that problem.

Interview Relevance: Differentiates between a temporary disruption (incident) and its root cause (problem).

Yes, absolutely. This is a standard practice in ServiceNow ITSM. If a support engineer is working on an incident and realizes that the issue is recurring or has a broader impact, they can create a linked problem record directly from the incident form.

This action typically involves a UI action or workflow that creates a new problem ticket and automatically associates the current incident with it. This is a key part of the incident-to-problem transition when root cause analysis is required.

Interview Relevance: Tests your understanding of the ITSM processes and how different modules interact.

Yes, you can indeed create a change request directly from an incident. This is a common workflow when resolving an incident requires a modification to the IT infrastructure or a deployed application.

For example, if an incident is caused by a misconfiguration, the support engineer might initiate a change request to correct that configuration. The incident provides the context and justification for the change, and the change request outlines the steps to implement the solution. This linkage ensures traceability and proper management of the change process.

Interview Relevance: Demonstrates understanding of how incidents can trigger proactive changes to improve service stability.

Creating incident records via script is a common requirement for automation. Here’s a script using GlideRecord:

var gr = new GlideRecord('incident');
gr.initialize(); // Prepare a new incident record
// Assigning a caller. Ensure '86826bf03710200044e0bfc8be5d94' is a valid sys_id for a user.
gr.caller_id = '86826bf03710200044e0bfc8be5d94';
gr.category = 'inquiry'; // e.g., 'incident' or 'request'
gr.subcategory = 'antivirus'; // Specific type of issue
// Assigning a Configuration Item (CI). Ensure 'affd3c8437201000deeabfc8bcbe5dc3' is a valid sys_id for a CI.
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Test incident created via script for performance monitoring.';
gr.description = 'This is a test incident to verify script functionality and impact on response times.';
// Assigning to a group. Ensure 'a715cd759f2002002920bde8132e7018' is a valid sys_id for an assignment group.
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert(); // Save the new incident record

gs.info('Incident created successfully with number: ' + gr.number);
            

Interview Relevance: Shows practical scripting skills for automating the creation of ITSM records.

Creating problem records via script follows a similar pattern to incident creation:

var gr = new GlideRecord('problem');
gr.initialize(); // Prepare a new problem record
gr.caller_id = '86826bf03710200044e0bfc8be5d94'; // Caller who reported the issue
gr.category = 'system failure'; // Example category
gr.subcategory = 'server'; // Example subcategory
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Affected CI
gr.short_description = 'Root cause analysis for recurring server issues in production.';
gr.description = 'Investigating the underlying cause of intermittent server reboots impacting multiple services.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Assignment group responsible for problem resolution
gr.insert(); // Save the new problem record

gs.info('Problem created successfully with number: ' + gr.number);
            

Interview Relevance: Demonstrates your ability to automate the creation of problem records for proactive issue resolution.

Creating change requests via script is common for automated deployments or scheduled maintenance:

var gr = new GlideRecord('change_request');
gr.initialize(); // Prepare a new change request record
gr.category = 'normal'; // Types: normal, standard, emergency
gr.subcategory = 'software'; // e.g., 'patching', 'upgrade', 'deployment'
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Affected CI
gr.short_description = 'Scheduled maintenance: Apply security patch to web servers.';
gr.description = 'Applying the latest security patch to all production web servers to address CVE-XXXX-XXXX.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Assignment group for change implementation
// Setting planned start and end dates for the change
gr.start_date = new GlideDateTime(); // Current date/time
gr.end_date = new GlideDateTime();
gr.end_date.addDays(1); // Example: schedule for 24 hours from now
gr.insert(); // Save the new change request record

gs.info('Change Request created successfully with number: ' + gr.number);
            

Interview Relevance: Shows your ability to script change management processes, which are critical for IT stability.

This is a perfect use case for an After Business Rule. The logic is to trigger when an incident’s state changes to ‘Closed’ and if it has a parent field populated (meaning it’s not a top-level incident).

Business Rule: Close Child Incidents on Parent Closure

• Table: Incident [incident]
• When to run: After update
• Order: 100 (or a suitable order to run after state updates)
• Condition: current.state.changesTo(7) && !current.parent.nil() (Assuming state 7 is ‘Closed’. Adjust if your closed state value is different. `!current.parent.nil()` ensures it’s a child.)
• Advanced: Checked

// Business Rule Script (After update on Incident)
if (current.state == 7) { // Check if the state is Closed (adjust state value if needed)
    // Find and update all child incidents
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id); // Query for incidents where 'parent' field matches the current incident's sys_id
    grChild.query();

    while (grChild.next()) {
        // Only update if the child incident is not already closed
        if (grChild.state != 7) {
            grChild.state = 7; // Set the state to Closed
            grChild.work_notes = 'Closed automatically because parent incident ' + current.number + ' was closed.';
            grChild.update(); // Update the child incident record
        }
    }
}
            

Interview Relevance: Demonstrates practical application of business rules for automating ITSM workflows and ensuring data integrity.

This scenario is best handled by a Before Business Rule. It will run before the incident is updated and can abort the action if certain conditions aren’t met.

Business Rule: Prevent Closing Incident with Open Tasks

• Table: Incident [incident]
• When to run: Before update
• Order: 100 (or a low number to run early)
• Condition: current.state.changesTo(7) (Assuming state 7 is ‘Closed’. This triggers the check only when attempting to close.)
• Advanced: Checked

// Business Rule Script (Before update on Incident)

// Check for open Incident Tasks
var grTask = new GlideRecord('incident_task');
grTask.addQuery('incident', current.sys_id); // Link to the current incident
grTask.addQuery('state', '!=', 3); // Assuming state 3 is 'Closed' for incident tasks. Adjust if necessary.
grTask.query();

if (grTask.hasNext()) {
    gs.addErrorMessage('Cannot close the incident because there are open incident tasks.');
    current.setAbortAction(true); // Abort the update operation
}

// Add similar checks for Problem (linked Problem Tasks) and Change Request if needed.
// For Change Requests, you'd check 'change_task' table.
// For Problems, you might check 'problem_task' table.
            

Interview Relevance: Shows understanding of how to enforce business rules and prevent invalid data states using business rules and `setAbortAction()`.

This can be implemented using an After Business Rule on the Problem table.

Business Rule: Close Incidents on Problem Closure

• Table: Problem [problem]
• When to run: After update
• Order: 100
• Condition: current.state.changesTo(7) (Assuming state 7 is ‘Closed’ for problems.)
• Advanced: Checked

// Business Rule Script (After update on Problem)
if (current.state == 7) { // If the problem is being closed
    // Find all incidents linked to this problem
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Query incidents where problem_id matches the current problem's sys_id
    grIncident.addQuery('state', '!=', 7); // Ensure we only close incidents that are not already closed. Adjust state value if needed.
    grIncident.query();

    while (grIncident.next()) {
        grIncident.state = 7; // Set the state to Closed
        grIncident.work_notes = 'Closed automatically because the parent problem ' + current.number + ' was closed.';
        grIncident.update(); // Update the incident record
    }
}
            

Interview Relevance: Demonstrates how to automate cross-module dependencies and ensure consistent data states across ITSM processes.

These three modules form the backbone of IT Service Management, and their relationships are crucial for efficient IT operations:

• Incident Management: Deals with restoring normal service operation as quickly as possible and minimizing the adverse impact on business operations. When a user reports an issue, an incident is created.
• Problem Management: Focuses on identifying the root cause of one or more incidents. If incidents are recurring, the problem management process is triggered to find and resolve the underlying issue, preventing future incidents. An incident can lead to the creation of a problem.
• Change Management: Manages all changes to the IT infrastructure in a controlled way to minimize disruption to IT services. If a problem’s root cause is identified and requires a permanent fix that involves altering the IT environment (e.g., patching software, reconfiguring hardware), a change request is initiated.

The flow often looks like this:

Incident (service disruption) -> Problem (investigate root cause of recurring incidents) -> Change Request (implement fix for the root cause of the problem).

It’s also possible for an Incident to directly trigger a Change Request if the resolution requires an immediate, approved modification.

Interview Relevance: This is a core ITSM question. A clear understanding of these relationships is essential.

Out-of-the-box tables in ServiceNow are those that are delivered by default with the platform and are not created by customers or partners. They typically have names starting with a prefix (though historically, some core ones didn’t have prefixes, or had prefixes that are now deprecated). Tables created in scoped applications usually start with x_ or u_. Here are some common OOB tables:

• incident
• problem
• change_request
• sc_req_item (Requested Item)
• alm_asset (Asset)
• cmdb_ci (Configuration Item – base table for CIs)
• sys_user (User)
• sys_user_group (Group)
• sys_audit (Audit History)
• sys_attachment (Attachments)

Interview Relevance: Shows you know where to find core data and understand the difference between platform-provided and custom tables.

Base tables in ServiceNow are tables that do not extend any other table but are extended by many other tables. They serve as foundational structures for other records. Examples include:

• task: This is a fundamental base table for many ITSM-related records like Incidents, Problems, Changes, and Tasks. It contains common fields like short description, description, state, assignment group, assigned to, etc.
• cmdb_ci: This is the base table for the Configuration Management Database (CMDB). All Configuration Items (CIs) extend from this table, providing a common structure for all IT assets and services.
• sys_security_role: The base table for defining roles.

Interview Relevance: Understanding base tables is key to comprehending table inheritance and how data is structured and shared across different modules.

The task table is a parent table that many other records extend from. Examples of tables that extend from task include:

• incident
• problem
• change_request
• sc_task (Catalog Task)
• std_change_producer (Standard Change Producer)
• pm_task (Project Task)

These tables inherit fields from the task table, ensuring consistency in how work items are managed.

Interview Relevance: Reinforces the concept of table inheritance and its application in ITSM.

When you create a new table in ServiceNow and the checkbox for “Create ACLs” (or similar wording) is checked during table creation, four default ACLs are automatically generated. These are typically:

• Create ACL (allows creating new records)
• Read ACL (allows reading records)
• Write ACL (allows updating records)
• Delete ACL (allows deleting records)

These default ACLs often grant access to roles like admin and sometimes itil, depending on the platform version and configuration. If you uncheck this option, no default ACLs will be created, and you’ll need to manually define all access controls.

Interview Relevance: Shows understanding of how ServiceNow enforces security and the default security settings for new tables.

To create a number field that auto-generates unique, sequential numbers (like incident numbers), you need to configure it as an Auto-Number field. When creating or editing a field in the Dictionary Entry:

1. Go to the Control tab.
2. Check the Auto-number checkbox.
3. Configure the Prefix (e.g., ‘INC’ for incidents).
4. Specify the Number of digits (e.g., 7 or 8 for incident numbers).

ServiceNow then manages the sequence and ensures unique numbering for each record created in that table.

Interview Relevance: Demonstrates knowledge of field types and how unique identifiers are generated.

When you extend a table in ServiceNow, you’re essentially creating a child table that inherits fields and configurations from a parent table. Here’s what happens:

• Inheritance: All fields from the parent table are automatically available in the child table. You don’t need to recreate them.
• System Fields: Standard system fields (like sys_created_on, sys_updated_on, sys_id, sys_mod_count, etc.) are not recreated in the child table. They are inherited from the parent.
• ‘Class’ Field: A field called class is created in the parent table. This field stores the sys_id of the table that the record actually belongs to. For example, if you have an incident record (which extends task), the ‘task’ table’s ‘class’ field for that record would point to the ‘incident’ table’s sys_id. This is how ServiceNow keeps track of the actual record type.
• Single Class Field: If a table extends multiple other tables (which is less common and generally discouraged), it still only has one ‘class’ field in its highest parent that points to its actual type.

Interview Relevance: Understanding table extension is crucial for comprehending ServiceNow’s data model and inheritance structure.

Certainly! ServiceNow supports a wide variety of field types to cater to different data needs. Here are 10 common ones:

1. String: For text input (single line or multi-line).
2. Integer: For whole numbers.
3. Decimal: For numbers with decimal points.
4. Boolean: For true/false values (checkboxes).
5. Date: For storing dates.
6. Date/Time: For storing dates and times.
7. Reference: To link to a record in another table (e.g., linking an incident to a user).
8. List: To allow selection of multiple records from another table (e.g., adding multiple watchers to an incident).
9. Choice: For dropdown lists with predefined options.
10. Journal: For accumulating comments or work notes, displaying a history of entries.
11. Attachment: To allow users to attach files to a record.

Interview Relevance: Demonstrates knowledge of ServiceNow’s data modeling capabilities.

The key difference lies in data retention:

• Normal Tables: Data stored in normal tables is intended to be permanent and is retained until explicitly deleted. These are your everyday operational tables like incident, change_request, sys_user.
• Temporary Tables (e.g., Import Set Rows): These tables are designed for transient data. For instance, the import_set_row table stores data temporarily during an import process. This data typically has a limited retention period, often around 7 days by default, after which it’s automatically purged. They often extend from tables like import_set_row to manage this lifecycle.

Interview Relevance: Shows understanding of different data storage mechanisms and their use cases, particularly in data integration.

Yes, you can extend the retention period for temporary data, often through Archive Rules. While the default retention is usually for a limited time (e.g., 7 days for import set rows), you can configure archive rules to retain this data for longer if necessary for audit or historical analysis purposes. However, it’s important to consider the storage implications and business justification for retaining temporary data long-term.

Interview Relevance: Demonstrates knowledge of data lifecycle management and configuration options.

The distinction is about where the data resides and how it’s accessed:

• Normal Tables: Data for normal tables is stored directly within your ServiceNow instance’s database. When you query these tables, you’re accessing data physically stored on your ServiceNow instance.
• Remote Tables: These are not tables in the traditional sense where data is stored locally. Instead, they are defined in ServiceNow but fetch their data from an external system in real-time. When you query a remote table, ServiceNow makes a call to the configured external data source to retrieve the live data. This is often used for integrating with other systems without duplicating data.

Interview Relevance: Shows awareness of ServiceNow’s data integration capabilities, specifically for real-time external data access.

These terms describe how records in different tables relate to each other:

• One-to-Many Relationship: This is the most common type. In this relationship, one record in Table A can be related to multiple records in Table B, but each record in Table B is related to only one record in Table A.
  • Example: Users and Incidents. One user (Table A) can have many incidents (Table B) associated with them. However, each incident (Table B) is typically assigned to only one user (Table A).
• Many-to-Many Relationship: In this relationship, one record in Table A can be related to multiple records in Table B, AND one record in Table B can be related to multiple records in Table A. This is typically implemented using a ‘many-to-many’ table (also called a join table or intermediary table).
  • Example: Incidents and Groups. An incident (Table A) can be assigned to or affected by multiple groups (Table B). A group (Table B) can also be assigned multiple incidents (Table A). The sys_user_group table and its relationship to other tables via the sys_user_grmember table (or specific task assignment tables) illustrates this.
• One-to-One Relationship: Less common and often achieved through a reference field where only one record can be selected. A record in Table A is related to at most one record in Table B, and vice-versa.
  • Example: A dedicated ‘User Preferences’ table that stores user-specific settings. Each user record might have a reference to exactly one preference record.

Interview Relevance: Crucial for understanding how data is linked and related within the ServiceNow platform and for designing integrations.

There are several ways to create records in ServiceNow tables:

1. Form: Directly via a standard form interface by filling out fields.
2. UI Action/UI Page: Clicking a custom button or link that triggers a script to create a record.
3. Record Producer: A catalog item that creates a record in a specific table when submitted.
4. Email: Inbound email actions can create records based on incoming emails.
5. Script (GlideRecord): Programmatically using server-side scripting, as shown in previous examples.
6. Import Sets/Data Sources: Loading data from external files (like Excel, CSV) or other systems.
7. Web Services: Creating records via REST or SOAP APIs from external applications.
8. Workflows/Flow Designer: Automated record creation as part of a business process.

Interview Relevance: Demonstrates your understanding of the various data input methods available in ServiceNow.

You can control field behavior (mandatory, read-only, visible) using several mechanisms:

• Dictionary Properties: On the field’s Dictionary Entry (e.g., checking “Mandatory” or “Read only” on the field definition). This is a global setting for that field.
• Dictionary Overrides: To change the behavior of a field from its parent table in a child table (e.g., making a field mandatory in Incident but not in Task).
• UI Policies: Client-side logic executed on form load and based on field changes. They can make fields mandatory, read-only, visible, hide them, set values, etc.
• Data Policies: Similar to UI Policies but can run on both the client and server sides, enforcing data consistency. They can also make fields mandatory, read-only, or visible.
• Client Scripts: Using JavaScript (e.g., g_form.setMandatory('field_name', true);, g_form.setReadOnly('field_name', true);, g_form.setVisible('field_name', true);) to control behavior dynamically based on complex logic.

Interview Relevance: Shows your ability to use different tools to control form behavior and data integrity.

ServiceNow allows you to set only one field as the ‘Display’ field for a table. This field is used in reference fields pointing to that table to show a more user-friendly identifier than just the sys_id.

If you try to set a second field as ‘Display’, it will either prompt you that you can only have one or overwrite the previous ‘Display’ field. The primary reason is to avoid confusion and ensure a consistent, predictable representation of records when they are referenced elsewhere. For example, the sys_user table’s display field is typically ‘Name’.

Interview Relevance: Demonstrates understanding of reference fields and how display values improve user experience.

All table definitions in ServiceNow, including custom tables and out-of-the-box tables, are stored in the sys_db_object table. This table contains metadata about each table in the system, such as its name, label, and extension details.

Interview Relevance: A technical detail about ServiceNow’s metadata repository.

You can set a default value for a field in several ways:

• Dictionary Entry: On the field’s Dictionary Entry, there’s a “Default value” field. This value will be populated automatically when a new record is created for that table. For example, setting a default value of ‘New’ for the ‘State’ field on an incident.
• UI Policy: A UI Policy can set a default value for a field when the form loads or under certain conditions.
• Client Script (OnLoad): An OnLoad client script can also use g_form.setDefaultValue('field_name', 'your_default_value'); to set a value when the form loads.
• Business Rule (Before Insert): A server-side business rule that runs before insert can also set default values.

Interview Relevance: Shows how to pre-populate forms for user convenience and consistency.

The current object is a server-side JavaScript object available in server-side scripts (like Business Rules, Script Includes, Workflow Scripts). It represents the record that is currently being processed by the script.

When a Business Rule runs on an update, current refers to the record after it has been updated. When it runs on insert, current refers to the new record being inserted. You use the current object to read field values from the record and to set new values before committing the changes.

Interview Relevance: Fundamental to server-side scripting in ServiceNow.

On the server-side, using the current object:

• current.setValue('field_name', value);: This is the standard way to set a field value. For reference fields, you must provide the sys_id of the referenced record as the value.
• current.setDisplayValue('field_name', value);: This method sets the value using its display value. For reference fields, you provide the human-readable display value (e.g., the user’s name), and ServiceNow will look up the corresponding sys_id. This is often more convenient when the display value is readily available.

On the client-side, you use the g_form object:

• g_form.setValue('field_name', value);: Similar to server-side `setValue`. For reference fields, provide the sys_id.
• g_form.setDisplayValue('field_name', value);: Similar to server-side `setDisplayValue`. Provide the display value.

Interview Relevance: Shows practical scripting skills for manipulating record data.

Reference Qualifiers are essential tools for filtering the records that appear in a reference field or a list collector. They ensure that users can only select relevant records, improving data accuracy and usability.

There are three primary types of Reference Qualifiers:

1. Simple Reference Qualifier

Description: This is the most straightforward type. It uses a basic query (similar to what you’d use in a filter builder) to restrict the available choices in a reference field. It’s static in nature.

Example: If you have a reference field pointing to the sys_user table, you might use a simple reference qualifier to show only active users (active=true) or users in a specific department.

How to Use: You configure this directly in the Dictionary Entry for the reference field. You click the lock icon next to the “Reference qual” field and enter your query conditions (e.g., active=true^department=IT).

Difference from Dynamic/Advanced: It’s static. It doesn’t take context from other fields on the form during runtime.

2. Dynamic Reference Qualifier

Description: Dynamic reference qualifiers allow you to filter reference fields based on the values of other fields on the current form. They use “Dynamic Filter Options” which are pre-configured server-side scripts or logical definitions.

Example: Displaying only devices (CIs) that are part of the same “Application Service” as the incident being created. Or, showing only users who are members of the same assignment group as the incident.

How to Use: You first define a “Dynamic Filter Option” (under System Definition > Dynamic Filter Options). Then, in the Dictionary Entry of the reference field, you select “Dynamic” as the type and choose your created Dynamic Filter Option.

Difference from Simple: It’s dynamic and context-aware. It can adapt its filtering based on other fields’ values on the form.

Difference from Advanced: It’s more structured and uses pre-defined components (Dynamic Filter Options), making it easier to manage for common dynamic scenarios without writing explicit JavaScript for each qualifier.

3. Advanced Reference Qualifier (JavaScript Reference Qualifier)

Description: This type offers the most flexibility by allowing you to write custom JavaScript code directly in the reference qualifier. This enables complex filtering logic that can involve multiple tables, intricate conditions, and dynamic calculations.

Example: Filtering a list of “Affected CIs” on an incident to show only CIs that are either directly managed by the “Assignment Group” of the incident, or that are dependencies of CIs managed by that group, and also have a “Support Group” matching the caller’s department.

How to Use: In the Dictionary Entry, select “Advanced” for the reference qualifier type and enter your JavaScript code in the “Reference qual” field. The script must return a query string that the system can use to filter the reference table.

Example JavaScript:

javascript: 'assignment_group=' + current.assignment_group + '^state=active';
// Or for more complex logic, you might call a Script Include.
// javascript: new MyCustomFilter().getValidUsers(current.sys_id);
            

Difference from Simple: It’s programmable and can handle far more complex logic than a simple query.

Difference from Dynamic: While dynamic can be context-aware, advanced allows for true custom logic and interaction with multiple data points, often requiring a deeper understanding of JavaScript and ServiceNow’s API.

Interview Relevance: This is a crucial question for any ServiceNow developer or administrator, showing a deep understanding of data filtering and UI control.

Dependent values in ServiceNow, often referred to as dependent fields or cascaded dropdowns, are a way to filter the available choices in one field (the dependent field) based on the selection made in another field (the parent field).

How it Works:

This is configured at the Dictionary level for the dependent field. When you set up a field to be dependent on another:

1. Parent Field: This field has a set of choices (e.g., Category).
2. Dependent Field: This field’s choices are filtered based on the parent field’s selection (e.g., Subcategory, which depends on Category).

You link the choices together. For example, if the Category is ‘Hardware’, the Subcategory dropdown might only show ‘Laptop’, ‘Desktop’, ‘Printer’. If the Category changes to ‘Software’, the Subcategory choices would then update to ‘Operating System’, ‘Application’, etc.

Configuration:

In the Dictionary Entry of the dependent field (e.g., Subcategory), you set the “Dependent field” attribute to the name of the parent field (e.g., “Category”). Then, within the “Choices” related list for the dependent field, you define the values and their corresponding dependent values.

Example:

Parent: Country (e.g., USA, Canada, India)

Dependent: State/Province (depends on Country)

Choices for State/Province:

• Value: California, Dependent value: USA
• Value: Texas, Dependent value: USA
• Value: Ontario, Dependent value: Canada
• Value: Quebec, Dependent value: Canada
• Value: Maharashtra, Dependent value: India

When a user selects ‘USA’ for Country, the State/Province dropdown will only show ‘California’ and ‘Texas’.

Interview Relevance: Essential for creating intuitive and user-friendly forms by guiding users through selections.

A calculated value field in ServiceNow is a field whose value is not entered directly by a user but is automatically computed based on a formula or logic defined within its Dictionary Entry. This is achieved by using a “Calculation” attribute or by defining a specific script.

How it Works:

• Dictionary Calculation: For simple arithmetic operations, you can use formulas in the Dictionary Entry’s “Calculation” field. For example, if you have fields like ‘Quantity’ and ‘Unit Price’, you could set the ‘Total Price’ field’s calculation to Quantity * Unit_Price.
• Scripting: For more complex logic that might involve referencing other fields, related records, or executing custom functions, you can use a script in the Dictionary Entry (often via a Script Include called by a Business Rule or a calculated field with script).

Use Cases:

• Calculating age from a date of birth.
• Calculating the total cost of items.
• Determining a priority score based on multiple factors.
• Calculating days until a due date.

The value of a calculated field is automatically updated when any of the fields involved in its calculation change.

Interview Relevance: Shows understanding of how to create dynamic fields that derive their values automatically, reducing manual effort and errors.

Attributes in ServiceNow are special key-value pairs that can be added to a field’s Dictionary Entry to modify or enhance its behavior and appearance without writing explicit script for every instance. They are a powerful way to customize field functionality.

Attributes are added in the “Attributes” field on the Dictionary Entry form.

Here are some common attributes and their uses:

• no_email: Prevents the system from sending email notifications when this field is updated.
• no_attachment: Disables the attachment functionality for a specific form or field.
• no_add_me: Used on List Collectors or Reference fields to prevent users from adding themselves to the selected list/reference.
• tree_picker: Changes the UI of a reference field to display a tree-like structure for selection, commonly used for categories or hierarchical data.
• ref_auto_completer=true: Enables auto-completion for a reference field, suggesting entries as the user types.
• ref_ac_columns=column1,column2: Specifies which columns to display in the auto-completion suggestion list.
• ref_ac_columns_search=true: Allows searching within the specified auto-completion columns.
• is_date: Marks a field as a date field (though the field type itself usually handles this).
• readonly: Makes the field read-only (similar to setting the “Read only” attribute in the Dictionary).
• mandatory: Makes the field mandatory (similar to setting the “Mandatory” attribute in the Dictionary).

Interview Relevance: Demonstrates knowledge of efficient field customization techniques.

In ServiceNow’s table definition, a “collection field” is not a traditional field type like ‘String’ or ‘Integer’. Instead, it refers to the Dictionary entry that represents the table itself, rather than a specific field within that table.

When you create a table, ServiceNow automatically creates a Dictionary Entry for that table. This entry is sometimes referred to as the “collection field” for that table. Changes made to this specific Dictionary Entry (like adding attributes or checking certain properties) apply to the entire table, not a single field. For example, attributes like no_attachment applied to the table’s collection entry will disable attachments for all records in that table.

Interview Relevance: Understanding table metadata and how to configure table-level settings.

You can enable or disable attachments for a form or table by using an attribute on the table’s collection field (its own Dictionary Entry).

• To Disable Attachments: Add the attribute no_attachment to the Attributes field in the Dictionary Entry of the table itself. This will hide the attachment paperclip icon and prevent users from attaching files to any record of that table.
• To Enable Attachments: By default, attachments are enabled for most tables. If you had previously disabled them using no_attachment, you would simply remove that attribute to re-enable them.

Interview Relevance: Practical application of attributes for controlling form features.

Dictionary Overrides are a powerful ServiceNow feature that allows you to modify the properties of a field in a child table without altering the parent table’s definition. This is essential for tailoring fields to specific module requirements.

Purpose: When a child table extends a parent table, it inherits all fields. However, you might need a field to behave differently in the child table. For example, a field might be optional in the parent but mandatory in a child table, or its default value might need to change.

Properties you can override: You can override many properties of a field, including:

• Default value: Change the pre-populated value for a field.
• Mandatory: Make a field required in the child table when it’s optional in the parent.
• Read-only: Make a field read-only in the child table.
• Display: Change which field is the display value (though typically only one display field per table is allowed).
• Max length: Increase or decrease the maximum character limit for a String field.
• Attributes: Add or remove attributes.
• Reference qualifier: Apply a different reference qualifier.
• Help tag and Help text: Modify the help information.
• Choice list specification: Change the choices available.

Example: The priority field might have a default value of ‘4’ in the parent task table. In the incident table (a child of task), you might override the priority field to have a default value of ‘5’ and make it mandatory. The original definition in the task table remains unchanged.

Interview Relevance: Crucial for understanding how to customize fields for different modules without breaking inheritance or affecting other parts of the platform.

Application Menus in ServiceNow are top-level navigation items in the platform’s left-hand navigation menu (the navigator). They group together related modules, allowing users to easily find and access different functionalities.

When you create a custom application or use a scoped application, you’ll typically define an application menu. Under this application menu, you can then create Modules, which are the actual links to lists, forms, or other views within that application.

Example: ServiceNow’s “Self-Service” application menu contains modules like “My Incidents,” “My Requests,” etc. Similarly, the “Incident” application menu contains modules like “Open,” “All,” “New,” “On Hold,” etc.

Interview Relevance: Shows understanding of how users navigate the ServiceNow platform and how applications are structured.

A Process Flow (or Flow Designer flow) in ServiceNow is a visual representation of a multi-step business process. It’s a way to design, automate, and monitor complex workflows that involve various tasks, approvals, and integrations.

Essentially, it’s a series of actions that occur in a specific order to achieve a particular outcome. Process flows can be used for anything from onboarding a new employee to automating the deployment of a new service.

ServiceNow’s Flow Designer is the primary tool for building these visual workflows. It provides a drag-and-drop interface to define triggers, actions, conditions, and integrations.

Interview Relevance: Demonstrates knowledge of ServiceNow’s workflow automation capabilities.

Data Lookup Rules in ServiceNow allow you to automatically populate fields on a form based on the values entered in other fields on the same form. They are typically used to simplify data entry and ensure consistency.

They work by defining a set of conditions and corresponding values to be set.

Example:

• Trigger Field: Country
• Target Field: Timezone

Lookup Rule:

• If Country is ‘United States’, set Timezone to ‘America/Los_Angeles’.
• If Country is ‘Canada’, set Timezone to ‘America/Toronto’.

When the user selects ‘United States’ for the Country, the Timezone field will automatically populate with ‘America/Los_Angeles’.

Data Lookups are configured under System Policy > Rules > Data Lookup Rules.

Interview Relevance: Shows how to automate data entry and improve user experience.

UI Policies are client-side scripts that dynamically change the behavior of form fields. They are a more modern and user-friendly alternative to traditional client-side JavaScript for many common form manipulation tasks.

UI Policies can perform actions such as:

• Making fields mandatory.
• Making fields read-only.
• Making fields visible or hidden.
• Setting field values.
• Showing or hiding related lists.

They are triggered based on conditions evaluated when the form loads (On Load) or when certain field values change. They offer a no-code/low-code way to manage form behavior.

Interview Relevance: Essential for understanding client-side form customization.

The “Global” checkbox on a UI Policy determines whether the UI Policy will apply to all views or only to specific views.

• If “Global” is checked: The UI Policy will be active and evaluated on all views of the form. This is the most common setting.
• If “Global” is unchecked: You will be prompted to specify which views the UI Policy should apply to. This is useful when you need different form behaviors for different user interfaces or configurations of the same form.

Interview Relevance: Shows understanding of how to control the scope of UI Policies.

The “Reverse if false” checkbox in a UI Policy is a powerful option that controls what happens to the UI Policy’s actions when the UI Policy’s conditions are no longer met (i.e., when the condition evaluates to false).

• If checked: When the UI Policy’s conditions evaluate to false, all actions defined in the UI Policy will be reversed. For example, if a field was made mandatory when the condition was true, checking “Reverse if false” means that field will become optional again when the condition is false. Similarly, if a field was hidden, it will become visible.
• If unchecked: When the UI Policy’s conditions evaluate to false, the actions are simply not applied. Any previous state of the fields remains as it was.

It’s crucial for managing dynamic form states where you want behaviors to toggle on and off smoothly.

Interview Relevance: Demonstrates nuanced understanding of UI Policy behavior and control.

The “On Load” checkbox in a UI Policy dictates whether the UI Policy’s conditions and actions are evaluated and applied immediately when the form initially loads.

• If “On Load” is checked: The UI Policy’s conditions are evaluated as soon as the form opens, and its actions are executed if the conditions are met. This is common for setting initial field visibility, mandatory status, or default values when a record is first displayed or created.
• If “On Load” is unchecked: The UI Policy’s actions are not applied when the form initially loads. The actions will only be triggered later, based on changes to other fields on the form (e.g., when a user changes a value in a specific field that meets the UI Policy’s conditions).

Interview Relevance: Important for understanding when UI Policy logic executes.

The “Inherit” checkbox on a UI Policy allows the UI Policy to be applied to tables that extend the table on which the UI Policy is defined. In essence, it enables the UI Policy to cascade down to child tables.

• If checked: The UI Policy will also be evaluated and applied to child tables that inherit from the current table.
• If unchecked: The UI Policy will only apply to the table it is defined on.

This is particularly useful for ensuring consistent UI behavior across a hierarchy of tables, like applying common UI rules to all tables that extend the task table.

Interview Relevance: Shows understanding of how UI policies interact with table inheritance.

Yes, you absolutely can write scripts within a UI Policy. To do so, you need to enable the “Run scripts” checkbox.

When you enable “Run scripts” for a UI Policy, you get sections for both “OnApplyScript” and “OnReverseScript”. These allow you to execute custom JavaScript code client-side when the UI Policy’s conditions are met (OnApplyScript) or when they are no longer met (OnReverseScript, if “Reverse if false” is checked).

This capability makes UI Policies very powerful, allowing for complex client-side logic that goes beyond simple field manipulations.

Interview Relevance: Demonstrates the advanced capabilities of UI Policies and your ability to extend them with scripting.

Yes, you can often convert a UI Policy into a Data Policy. ServiceNow provides a convenient way to do this.

To convert, you typically navigate to the UI Policy and look for an option or button that says something like “Convert to Data Policy” or a similar action. Clicking this will generate a new Data Policy based on the conditions and actions defined in your UI Policy. This is beneficial because Data Policies can run on both the client and server sides, ensuring data consistency across all entry points.

Interview Relevance: Shows awareness of ServiceNow’s tools for managing and migrating business logic.

While conversion is often possible, there are scenarios where a UI Policy’s functionality cannot be directly replicated or converted into a Data Policy. These typically involve UI-specific behaviors:

• Controlling Data Visibility/Display: UI Policies are primarily for controlling whether a field is visible or hidden on the UI. Data Policies are focused on data integrity and don’t typically manage field visibility directly.
• Controlling Views: UI Policies can sometimes influence which views are shown or how they behave, which is purely a UI concern.
• Controlling Related Lists: Showing/hiding related lists on a form is a UI action that Data Policies don’t handle.
• Controlling Script Execution for UI Actions: If the UI Policy relies heavily on client-side scripting for complex UI manipulations that aren’t related to data validation or mandatory/read-only states, that script might not translate directly.
• Controlling Form Tabs/Sections: Similar to visibility, manipulating the order or display of form tabs or sections is a UI-specific function.

In such cases, you might need to maintain the UI Policy for UI-specific behavior and create a Data Policy for data integrity aspects, or reimplement the logic using client scripts.

Interview Relevance: Demonstrates a deep understanding of the differences between UI and Data Policies and their respective scopes.

Data Policies in ServiceNow are server-side scripts that enforce data policies on records regardless of the client or user interface they are accessed from. They are used to make fields mandatory, read-only, or control their visibility based on certain conditions.

The key advantage of Data Policies is that they operate on the server, ensuring data integrity no matter how the data is entered – whether through a form, an import, an email, or an API. This contrasts with UI Policies, which primarily operate on the client-side and might not be applied if data is entered via server-side processes.

Data Policies can enforce:

• Mandatory fields
• Read-only fields
• Display/Hide fields (though their primary strength is data integrity, they can influence what’s presented)

They are configured with conditions and actions, similar to UI Policies, but with a stronger focus on data governance.

Interview Relevance: Crucial for understanding data integrity and governance in ServiceNow.