Decoding the CMDB: Essential Scenario Questions for ServiceNow Professionals

The Configuration Management Database (CMDB) is the backbone of effective IT Service Management (ITSM) within ServiceNow. It’s not just a repository of IT assets; it’s a dynamic map that informs incident resolution, problem management, change control, and even strategic decision-making. For anyone working with ServiceNow, a deep understanding of CMDB concepts and practical application is crucial. This article delves into common scenario-based questions that often surface in interviews and day-to-day operations, providing detailed, human-like explanations to solidify your knowledge.

Understanding Your ServiceNow Environment

Before diving into complex scenarios, it’s essential to understand the foundation of your ServiceNow instance. These initial questions are often icebreakers but reveal your familiarity with the platform’s evolution and current state.

1. Which is the current version you are working on in ServiceNow?

Answer: “I’m currently working on the Washington DC release, which is the latest stable version available. I’ve also had extensive experience with previous releases like Rome, San Diego, Tokyo, Utah, and Vancouver.”

Interview Relevance: Shows you’re up-to-date with the platform and have a historical perspective. Knowing the latest features and changes is a plus.

2. From which version you started working?

Answer: “My ServiceNow journey began with the Rome release. Since then, I’ve actively worked through San Diego, Tokyo, Utah, Vancouver, and now Washington DC.”

Interview Relevance: Similar to the above, this helps interviewers gauge your experience trajectory and how well you’ve adapted to platform updates over time.

User and Group Management: The Foundation of Access Control

Permissions and user management are fundamental to any IT system. In ServiceNow, how you manage users, groups, and their access directly impacts security and operational efficiency. Understanding these concepts is key to implementing best practices.

3. Can we add permissions to users and groups? Which is the best practice?

Answer: “Absolutely, yes. In ServiceNow, permissions are primarily managed through roles. You can assign roles directly to individual users or to groups. The best practice, and I can’t stress this enough, is to manage permissions primarily through groups. When you assign roles to a group, any user who is a member of that group automatically inherits those roles. This dramatically simplifies administration. For instance, when an employee leaves the organization or changes roles, you simply remove them from the relevant groups, and their permissions are revoked automatically. This minimizes the risk of orphaned access and streamlines onboarding/offboarding processes. We can add these roles manually through the UI or programmatically using scripts with GlideRecord.”

Troubleshooting: If permissions aren’t being inherited, double-check that the user is indeed an active member of the group, and verify that the group itself has the required roles assigned. Also, ensure there are no conflicting Access Control Lists (ACLs) overriding the intended permissions.

4. What is the user table name?

Answer: The user table in ServiceNow is named sys_user.

5. What is the group member table name?

Answer: The table that links users to groups, indicating membership, is called sys_user_grmember.

6. How to create a user account using a script?

Answer: We can create a user account programmatically using a GlideRecord object. Here’s a typical example:

    var userGr = new GlideRecord('sys_user');
    userGr.initialize(); // Prepares a new record
    userGr.username = 'jdoe';
    userGr.firstname = 'John';
    userGr.lastName = 'Doe';
    userGr.email = 'jdoe@example.com';
    userGr.active = true; // Essential to make the user active
    userGr.insert(); // Inserts the new user record
    gs.info('User ' + userGr.username + ' created successfully.');
    

Troubleshooting: If the user isn’t created, check for duplicate usernames or email addresses, ensure all mandatory fields are populated, and verify your script has the necessary permissions.

7. How to create a group using a script?

Answer: Creating a group via script is also straightforward with GlideRecord:

    var newGr = new GlideRecord('sys_user_group');
    newGr.initialize();
    newGr.name = 'New Project Team';
    // Assigning a manager requires the sys_id of a user record
    newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Replace with actual sys_id
    newGr.email = 'new.project.team@example.com';
    newGr.description = 'This group manages the new project initiatives.';
    newGr.insert();
    gs.info('Group ' + newGr.name + ' created successfully.');
    

Troubleshooting: Ensure the manager’s sys_id is correct and the user exists. Check for duplicate group names.

8. How to add permissions (roles) to a user/group account using a script?

Answer: When you assign a role to a user, a record is created in the sys_user_has_role table. For groups, it’s the sys_group_has_role table.

For Users:

    var userRole = new GlideRecord('sys_user_has_role');
    userRole.initialize();
    userRole.user = '62826bf03710200044e0bfc8dc3'; // sys_id of the user
    userRole.role = '2831a114c611228501d4ea6c309d626d'; // sys_id of the role
    userRole.insert();
    gs.info('Role added to user.');
    

For Groups:

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

Troubleshooting: Always use the sys_id for both users/groups and roles. Verify the existence of the user, group, and role before attempting to assign.

9. What exactly does user delegation mean in ServiceNow?

Answer: User delegation in ServiceNow allows one user to perform tasks and access resources on behalf of another user. This is incredibly useful for scenarios where a user might be on leave, vacation, or otherwise unavailable. The delegated user effectively steps into the shoes of the original user for specified tasks, ensuring business continuity. For example, an employee going on vacation can delegate their pending approval tasks to a colleague. This feature can be configured under the original user’s account, where you can specify the delegate, the duration (start and end dates), and the exact permissions granted – such as handling assignments, notifications, or approvals. It’s a powerful tool for maintaining workflow efficiency without interruption.

Interview Relevance: Demonstrates understanding of business continuity features and practical application in managing user availability.

10. How to add and remove group members from a group using a script?

Answer: This involves manipulating the sys_user_grmember table.

Adding a Group Member:

    var grMem = new GlideRecord('sys_user_grmember');
    grMem.initialize();
    grMem.user = '62826bf03710200044e0bfc8dc3'; // 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', '62826bf03710200044e0bfc8dc3'); // sys_id of the user
    grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // sys_id of the group
    grMem.query();
    if (grMem.next()) {
        grMem.deleteRecord();
        gs.info('User removed from group.');
    } else {
        gs.info('User not found in the specified group.');
    }
    

Troubleshooting: Always verify that both the user and group exist and that the user is not already a member before attempting to add. For removal, ensure the query correctly identifies the specific membership record.

ServiceNow User Interfaces and Special User Types

Understanding how users interact with ServiceNow and different types of user accounts is vital for both administration and development.

11. How many user interfaces are there in ServiceNow?

Answer: ServiceNow has evolved its user interfaces over time. Historically, we had UI15 and UI16. The current standard and recommended interface is the Next Experience UI (often referred to as the Polaris interface), which offers a more modern, streamlined, and responsive user experience.

Interview Relevance: Shows awareness of UI evolution and the current platform standard.

12. What is meant by a web services user in the User account?

Answer: A web services user account in ServiceNow is specifically designed for system-to-system integrations. These users are not intended for direct login into the ServiceNow UI. Instead, they are used by external applications or services to authenticate and interact with ServiceNow via its web services APIs (like REST or SOAP). This allows for secure data exchange and automation between ServiceNow and other platforms without human intervention. Key characteristics include the inability to log in via the standard UI and typically having specific roles tailored for API access.

Troubleshooting: If an integration is failing with a web services user, check the user’s active status, ensure they have the correct roles (e.g., rest_api_explorer, soap_query), and verify the authentication credentials being used by the external system.

Client-Side vs. Server-Side Scripting: Getting User Information

Distinguishing between client-side and server-side scripting is fundamental in ServiceNow. Knowing how to retrieve user information in each context is a common requirement.

13. How to get the current logged-in user’s system ID on the client-side?

Answer: On the client-side (e.g., in client scripts, UI policies, or UI actions), you can access the current user’s sys_id using the global JavaScript object g_user:

    var currentUserId = g_user.userID;
    alert('Your User ID is: ' + currentUserId);
    

Troubleshooting: Ensure you are in a client-side context. If g_user is undefined, you might be in a server-side script.

14. How to get the current logged-in user’s system ID on the server-side?

Answer: On the server-side (e.g., in business rules, script includes, or workflow scripts), you use the gs (GlideSystem) object:

    var currentUserId = gs.getUserID();
    gs.info('The current user\'s ID is: ' + currentUserId);
    

Troubleshooting: If gs.getUserID() returns an empty string or an unexpected ID, ensure the script is running in a context where a user is logged in or impersonating another user. Background scripts run as the system user by default.

15. How to check if the current logged-in user is a member of a particular group?

Answer: Again, this depends on the context. The gs object is used server-side:

    // Server-side example
    var groupName = 'ITIL Users'; // Or sys_id of the group
    if (gs.getUser().isMemberOf(groupName)) {
        gs.info('User is a member of ' + groupName);
    } else {
        gs.info('User is NOT a member of ' + groupName);
    }
    

On the client-side, you can use g_user.hasRole('role_name') or, more directly for group membership, you might need to use a Script Include called from the client script.

Troubleshooting: Ensure the group name or sys_id is correct. Case sensitivity might be an issue depending on how the group name is referenced.

Security and Access Control

Controlling who can see and do what within ServiceNow is paramount. Access Control Lists (ACLs) and security roles are the primary mechanisms.

16. Which role is required to work on Access Control (ACLs)?

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

Interview Relevance: This is a direct question about security administration and demonstrates awareness of privileged roles.

17. What is impersonation?

Answer: Impersonation is a powerful feature in ServiceNow that allows an administrator or a user with appropriate roles (like admin or itil with impersonation permissions) to temporarily “log in” as another user. This is invaluable for testing purposes, troubleshooting user-specific issues, or verifying that a user has the correct permissions and sees the interface as expected. When impersonating, you essentially experience ServiceNow from that user’s perspective, including their roles, groups, preferences, and potentially even their tailored UI views. It’s crucial to remember to “stop impersonating” once your testing is complete.

Troubleshooting: If impersonation fails, ensure the user you are trying to impersonate is active and that your own role has the necessary ‘Impersonate’ permission enabled.

18. What is a user preference?

Answer: User preferences in ServiceNow are settings that an individual user can configure to personalize their experience on the platform. These preferences are specific to that user and do not affect other users. Examples include setting their default language, preferred date/time format, list column layouts, or even form banner colors. When a user changes a preference, it’s stored in their user profile and only impacts their view and interactions. This allows for a highly customized user experience without needing administrative intervention for each personalization.

Troubleshooting: If a user’s preferences aren’t saving, check for client-side errors in the browser console or potential JavaScript conflicts on the form.

Incident, Problem, and Change Management: The Core ITSM Processes

These three processes are interconnected and form the bedrock of IT Service Management. Understanding their definitions, relationships, and how they are managed is essential.

19. What is an incident?

Answer: An incident is defined as any event that interrupts or reduces the quality of a standard IT service. Think of it as something that breaks unexpectedly and prevents an employee from performing their job. For example, if an employee’s email suddenly stops working, or their VPN connection fails, that’s an incident. The primary goal of incident management is to restore normal service operation as quickly as possible, minimizing the impact on business operations. This is typically achieved by logging the incident, categorizing it, assigning it to the appropriate support team, and resolving it.

Troubleshooting: Poorly categorized incidents can lead to extended resolution times. Ensure your incident categorization scheme is well-defined and support teams are trained to use it effectively.

20. What is a problem?

Answer: A problem is the underlying root cause of one or more incidents. If you see the same incident reoccurring frequently for the same user, or if multiple users report similar issues, it signals a potential problem. Unlike incidents, which focus on rapid restoration, problem management aims to identify the root cause of recurring incidents and find a permanent solution or workaround to prevent them from happening again. If a single incident is reported multiple times by different users, it might be treated as a significant incident, with one parent incident and others linked as children. Closing the parent incident often closes the associated child incidents.

Troubleshooting: The relationship between incident and problem needs clear definition. If problems aren’t being effectively identified and resolved, incidents will continue to flood the service desk.

21. Can we create a problem record from an incident?

Answer: Yes, absolutely. This is a standard practice. When a support engineer is working on an incident and identifies that the issue is recurring or has a deeper underlying cause, they can create a problem record directly from the incident form. This establishes a clear link, allowing the problem management team to investigate the root cause without the immediate pressure of restoring service. The incident can then be linked to the problem, ensuring that when the problem is resolved, all associated incidents are also addressed.

Interview Relevance: Shows understanding of the interconnectedness of ITSM processes.

22. Can we create a change request from an incident?

Answer: Yes, we can. If, during the investigation or resolution of an incident, it becomes apparent that a permanent fix requires a change to the IT infrastructure or application, a change request can be initiated directly from the incident. This is a crucial workflow. For example, if a software bug is causing repeated incidents, the resolution might involve deploying a patch. This deployment would be managed as a change request, ensuring that the change is properly planned, approved, and implemented without causing further disruption. This linkage ensures that the resolution of an incident can trigger necessary proactive improvements.

Troubleshooting: Ensure that the incident fields that populate the change request (like configuration item, affected service) are accurate to streamline the change creation process.

Scripting for ITSM Records

Automating the creation of core ITSM records is a common development task. Understanding how to use GlideRecord for these purposes is essential.

23. How to create an incident record using a script?

Answer: Using GlideRecord on the incident table:

    var gr = new GlideRecord('incident');
    gr.initialize();
    gr.caller_id = '86826bf03710200044e0bfc8be5d94'; // sys_id of the caller
    gr.category = 'inquiry';
    gr.subcategory = 'antivirus';
    // Link to a Configuration Item (CI) if applicable
    gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // sys_id of the CI
    gr.short_description = 'Test record created via script';
    gr.description = 'This is a detailed description for the test incident.';
    gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group
    gr.insert();
    gs.info('Incident created with number: ' + gr.number);
    

Troubleshooting: Ensure all referenced sys_ids (caller, CI, assignment group) are valid. Check for any business rules or ACLs that might prevent creation or require additional fields.

24. How to create a problem record using a script?

Answer: Similar to incidents, using GlideRecord on the problem table:

    var gr = new GlideRecord('problem');
    gr.initialize();
    gr.caller_id = '86826bf03710200044e0bfc8bcbe5dc3'; // sys_id of the caller
    gr.category = 'application';
    gr.subcategory = 'performance';
    gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // sys_id of the CI
    gr.short_description = 'Investigate recurring login issue';
    gr.description = 'Multiple users reporting slow login times since the last update.';
    gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group
    gr.insert();
    gs.info('Problem created with number: ' + gr.number);
    

Troubleshooting: Verify the sys_ids of referenced records. Check if any mandatory fields specific to the problem table are missing.

25. How to create a change request using a script?

Answer: Using GlideRecord on the change_request table:

    var gr = new GlideRecord('change_request');
    gr.initialize();
    gr.category = 'normal'; // Or 'standard', 'emergency'
    gr.subcategory = 'software';
    gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // sys_id of the CI
    gr.short_description = 'Deploy security patch for XYZ application';
    gr.description = 'This change request is to deploy the latest security patch to mitigate identified vulnerabilities.';
    gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group
    // Example of setting planned start/end dates
    var startDate = new GlideDateTime();
    startDate.addDays(1); // Schedule for tomorrow
    gr.requested_by = gs.getUserID(); // Example: current user requests it
    gr.planned_start_date = startDate;
    gr.insert();
    gs.info('Change Request created with number: ' + gr.number);
    

Troubleshooting: Ensure the change type (normal, standard, emergency) is appropriate and that associated fields like planned dates are correctly populated. Check for required approval workflows.

Automating ITSM Workflows with Business Rules

Business rules are server-side scripts that run automatically based on record events (insert, update, delete, query). They are powerful for automating complex logic and maintaining data integrity.

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

Answer: This can be achieved with an After Business Rule on the incident table.

Business Rule Configuration:

• Table: Incident
• When to run: After Update
• Filter Conditions: State changes to ‘Closed’ (assuming ‘7’ is the state for Closed) AND Parent is empty.
• Advanced Tab:

    (function executeRule(current, previous /*, gsd*/) {

        // Check if the incident is closing and it's a parent incident (has no parent itself)
        if (current.state.changesTo(7) && (previous.state != 7 || previous.state == null) && current.parent == '') {
            gs.info('Parent incident ' + current.number + ' is closing. Closing associated child incidents.');

            var grChild = new GlideRecord('incident');
            grChild.addQuery('parent', current.sys_id);
            grChild.query();

            while (grChild.next()) {
                // Only close children that are not already closed
                if (grChild.state != 7) {
                    grChild.state = 7; // Set the state to Closed
                    grChild.update(); // Update the child incident
                    gs.info('Child incident ' + grChild.number + ' marked as Closed.');
                }
            }
        }

    })(current, previous, gsd);
    

Troubleshooting: Ensure the state value (‘7’) is correct for your instance’s ‘Closed’ state. The `previous.state != 7 || previous.state == null` condition prevents this rule from running if the incident was already closed and is being updated again.

Interview Relevance: Demonstrates practical scripting skills for ITSM process automation and understanding of business rule execution.

27. 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 an Before Business Rule on the incident table.

Business Rule Configuration:

• Table: Incident
• When to run: Before Update
• Filter Conditions: State changes to ‘Closed’ (or any state that signifies closure).
• Advanced Tab:

    (function executeRule(current, previous /*, gsd*/) {

        // Check if the incident state is changing to a closed state
        if (current.state.changesTo(7) && previous.state != 7) { // Assuming 7 is the 'Closed' state
            var grTask = new GlideRecord('incident_task');
            grTask.addQuery('incident', current.sys_id);
            // Check for tasks that are NOT in a closed state. You'll need to know the sys_id for 'Closed' state in incident_task.
            // Common states: 1=Open, 2=Work in Progress, 3=Closed. Adjust if your instance differs.
            grTask.addQuery('state', '!=', 3);
            grTask.query();

            if (grTask.hasNext()) {
                gs.addErrorMessage('Cannot close the incident. There are open incident tasks associated with this incident.');
                current.setAbortAction(true); // Prevents the incident from being updated (closed)
            }
        }

    })(current, previous, gsd);
    

This logic needs to be replicated for problem and change_request tables, checking their respective related task tables (e.g., problem_task, change_task).

Troubleshooting: Ensure the state value for ‘Closed’ in the task tables is correct. The `current.setAbortAction(true)` is crucial here as it stops the save operation.

Interview Relevance: Demonstrates understanding of data validation and preventing invalid state transitions.

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

Answer: This can be implemented using an After Business Rule on the problem table.

Business Rule Configuration:

• Table: Problem
• When to run: After Update
• Filter Conditions: State changes to ‘Closed’ (assuming ‘7’ is the state for Closed).
• Advanced Tab:

    (function executeRule(current, previous /*, gsd*/) {

        // Check if the problem is closing and it's not already closed
        if (current.state.changesTo(7) && previous.state != 7) {
            gs.info('Problem ' + current.number + ' is closing. Closing associated incidents.');

            var grIncident = new GlideRecord('incident');
            // Link incidents to the problem using the 'problem_id' field
            grIncident.addQuery('problem_id', current.sys_id);
            // Ensure we only close incidents that are not already closed
            grIncident.addQuery('state', '!=', 7); // Assuming 7 is the 'Closed' state for incidents
            grIncident.query();

            while (grIncident.next()) {
                grIncident.state = 7; // Set the state to Closed
                grIncident.update(); // Update the incident
                gs.info('Associated incident ' + grIncident.number + ' marked as Closed.');
            }
        }

    })(current, previous, gsd);
    

Troubleshooting: Verify that the problem_id field is correctly populated on the incidents you expect to be closed. Confirm the state value for ‘Closed’ in the incident table.

Interview Relevance: Practical application of automating workflow based on record state changes.

The Relationship Between Incident, Problem, and Change

29. What is the relationship between incident, problem, and change management?

Answer: The relationship is sequential and symbiotic, forming a crucial ITSM lifecycle:

• Incident: This is the reactive part. When a service breaks or an employee can’t work, they log an incident. The goal is rapid restoration of service.
• Problem: If the same incident, or similar ones, keeps happening, it indicates an underlying problem. Problem management is proactive; it investigates the root cause of recurring incidents to prevent them. An incident might lead to the creation of a problem record.
• Change: Once the root cause of a problem is identified, the solution often involves a modification to the IT environment – perhaps a software patch, a configuration update, or a hardware replacement. This modification is managed as a change request. A problem resolution often triggers a change.

In essence: Incidents report issues, Problems diagnose the cause, and Changes implement the fix. This flow ensures not only that immediate disruptions are resolved but also that the underlying causes are addressed to improve overall service stability.

Interview Relevance: Demonstrates a holistic understanding of ITIL/ITSM principles and how they are implemented in ServiceNow.

ServiceNow Data Model: Tables and Relationships

Understanding ServiceNow’s data model is fundamental to development and administration. This includes knowing about out-of-the-box tables, base tables, and how tables extend each other.

30. Give me some names of out-of-the-box tables.

Answer: Out-of-the-box (OOB) tables are those provided by ServiceNow that do not start with x_ (custom scoped applications) or u_ (global scope custom tables). Some common examples include:

• incident
• problem
• change_request
• cmdb_ci (Configuration Item base table)
• sys_user (User table)
• sys_user_group (Group table)
• task (Base table for tasks)
• sys_audit (Audit trail)

Interview Relevance: Shows familiarity with common ServiceNow tables and the naming conventions for custom tables.

31. What are some of the base tables?

Answer: Base tables are tables that do not extend any other table but are extended by many other tables. They often represent core concepts in ServiceNow. Key examples include:

• task: This is the foundational table for any record that represents a task to be performed (e.g., Incident, Problem, Change Request, Catalog Task). It provides common fields like state, assignment group, assigned to, due date, etc.
• cmdb_ci: This is the base table for all Configuration Items (CIs) in the CMDB. All specific CI types (like servers, applications, databases) extend this table.
• cmdb: The root table for the entire CMDB.

Troubleshooting: Understanding base tables is crucial for inheritance. Changes to a base table’s fields or behavior can have a widespread impact on all tables that extend it.

32. Give me some examples of task tables.

Answer: As mentioned, tables that extend the task base table inherit its common fields and functionalities. Examples include:

• incident
• problem
• change_request
• sc_task (Service Catalog Task)
• std_change_task (Standard Change Task)
• planned_task

Interview Relevance: Reinforces understanding of table inheritance and the common data model for tasks.

33. Whenever we create a table, how many access controls (ACLs) will get created?

Answer: By default, when you create a new table in ServiceNow (and the “Create ACLs” checkbox is checked during table creation), four default ACLs are automatically generated. These provide basic read, write, create, and delete access for the admin role. If you uncheck that box, no ACLs are created automatically, and you would need to build them all manually.

Troubleshooting: Always review the generated ACLs to ensure they meet your security requirements. You might need to create more specific ACLs for different roles or conditions.

Field Types and Table Creation

Understanding how to define fields and tables is fundamental to customizing ServiceNow.

34. How to create a number field, like incident number?

Answer: When creating a table, or modifying an existing one, you can define a field to be an auto-number type. For fields like incident.number, you navigate to the table’s definition, add a new field, and select the Number field type. Within the field’s properties, under the Control tab, you’ll find options to set a Prefix (e.g., INC for Incident), define the Number of digits (e.g., 7 for INC0000001), and crucially, check the Auto number checkbox. ServiceNow then automatically generates unique sequential numbers based on these settings.

Troubleshooting: Ensure the prefix and number of digits are set appropriately to avoid collisions and maintain readability. If auto-numbering is not working, check if any scripts are interfering or if the sequence has been disrupted.

35. What happens when you extend a table?

Answer: When you extend a table (e.g., extending the task table to create the incident table), the child table inherits all the fields and behaviors of the parent table. This means you don’t have to redefine fields like short_description, state, or assigned_to in the child table. They are automatically available. ServiceNow also creates a special field called class (or similar, depending on context) in the parent table. This field stores the actual type of the record (e.g., ‘incident’, ‘problem’). This allows ServiceNow to correctly interpret and display the record even if it originates from a child table.

Troubleshooting: If a field from the parent table isn’t appearing on the child form, ensure it’s not being hidden by a UI Policy or ACL, and verify the table extension is correctly configured.

36. Can you give me 10 field types?

Answer: ServiceNow offers a wide variety of field types to cater to different data requirements. Here are 10 common ones:

1. Reference: Links to another record in a different table (e.g., linking an incident to a Configuration Item).
2. String: For text input, with options for single-line or multi-line.
3. List: Allows selection of multiple records from another table (e.g., attaching multiple files).
4. Choice: A dropdown list of predefined options.
5. Email: Specifically formatted for email addresses, enabling mailto: links.
6. Date/Time: For capturing both date and time.
7. Date: For capturing only the date.
8. Boolean: A true/false (checkbox) field.
9. Integer: For whole numbers.
10. Journal: For adding comments or work notes, often with an audit trail.
11. Attachment: For uploading files.

Interview Relevance: Shows practical knowledge of data modeling and field capabilities.

37. What is the difference between temporary and normal tables?

Answer: The main difference lies in data persistence:

• Normal Tables: Store data permanently. Once data is inserted, it remains until explicitly deleted. These are used for core operational data like users, incidents, and configuration items.
• Temporary Tables: Store data for a limited duration, typically 7 days. They are often used for staging data during import processes or for transient information that doesn’t need to be kept long-term. They usually extend the import_set_row table, which manages this temporary storage and cleanup.

38. Can we increase the retention period in temporary tables?

Answer: Yes, you can. While temporary tables typically have a default retention of 7 days, you can extend this period by configuring Archive Rules. This allows you to specify how long data should be retained before being moved to an archive table or purged, offering flexibility for specific use cases.

39. What is the difference between remote tables and normal tables?

Answer:

• Normal Tables: Store data directly within the ServiceNow instance’s database. When you query a normal table, you’re retrieving data that resides locally.
• Remote Tables: Store data outside the ServiceNow instance but are integrated so they appear as if they are part of ServiceNow. When you query a remote table, ServiceNow makes a call to the external data source to retrieve live data. This is often used for federated data or integrating with external systems without replicating the data.

40. What are one-to-one and one-to-many table relationships in ServiceNow?

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

• One-to-Many Relationship: This is the most common type. It means 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: A User (Table A) can have multiple Incidents (Table B) logged against them. Each incident is typically assigned to one user (the caller), but that user can have many incidents.
• Many-to-Many Relationship: This occurs when 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 usually implemented using a “glue” or “join” table.
  • Example: Incidents (Table A) can be assigned to multiple Groups (Table B), and a Group can be assigned to multiple Incidents. The sys_group_has_role or a similar linking table would facilitate this. (Note: While ‘many-to-many’ is a concept, ServiceNow often uses many-to-many relationships to link entities, for example, users and groups via sys_user_grmember).

Interview Relevance: Crucial for understanding data modeling and how related lists and lookups work.

Record Creation and Field Manipulation

There are multiple ways to get data into ServiceNow, and controlling how fields behave is key to user experience.

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

Answer: ServiceNow offers several ways to create records:

1. Form: The standard UI method, filling out a form.
2. GlideRecord: Server-side scripting (e.g., in Business Rules, Script Includes) for programmatic creation.
3. Record Producer: A catalog item that generates a record on a specified table.
4. Email: Inbound email actions can create records based on incoming emails.
5. Excel Sheet (Import Sets): Using data imports to load records from CSV or Excel files.
6. REST API / SOAP API: External systems can create records programmatically.
7. UI Actions: Custom buttons/links can trigger record creation scripts.

Interview Relevance: Shows awareness of various integration and automation possibilities.

42. In how many ways can we make a field mandatory or read-only?

Answer: There are several methods:

• Dictionary Properties: You can set a field as mandatory or read-only directly in its dictionary entry.
• Dictionary Overrides: For fields in child tables, you can override the parent table’s dictionary entry to make it mandatory or read-only.
• UI Policies: Client-side scripts that make fields mandatory, read-only, visible, or hidden based on conditions. They are executed on load and dynamically as form data changes.
• Data Policies: Similar to UI Policies but can run on both the client and server sides, enforcing data consistency regardless of the data source.
• g_form.setMandatory(fieldName, true/false): Client-side JavaScript used in UI Policies, UI Actions, or client scripts to dynamically set mandatory status.
• g_form.setReadOnly(fieldName, true/false): Client-side JavaScript to dynamically set read-only status.

Troubleshooting: UI Policies and Data Policies can sometimes conflict. UI Policies are client-side only, while Data Policies can be client and server. Dictionary settings are the baseline.

43. Can we make 2 fields as ‘display’ in one table?

Answer: No, you should not make more than one field as ‘display’ in a table. The ‘display’ attribute on a field is used for reference fields to show a meaningful label instead of just the sys_id. ServiceNow’s architecture is designed to use only one display value per table to avoid ambiguity and confusion when referencing records from other tables.

Interview Relevance: Tests understanding of fundamental ServiceNow data model constraints.

44. All tables will be stored where?

Answer: All table definitions in ServiceNow are stored in the sys_db_object table.

Interview Relevance: A direct question about the platform’s internal metadata storage.

45. How to set a default value on a field?

Answer: There are several ways to set default values:

• Dictionary Entry: The most common way is to set a Default value directly in the field’s dictionary definition.
• UI Policies: You can use a UI Policy to set a default value for a field when a form loads, based on certain conditions.
• Data Policies: Similar to UI Policies, but can also run server-side.
• Business Rules: An ‘On Display’ or ‘Before Insert’ business rule can set default values.
• Client Scripts: Using g_form.setValue() in an ‘OnLoad’ client script.

Troubleshooting: Dictionary default values are the most basic. UI policies and client scripts offer conditional defaults, while business rules can enforce server-side defaults.

Advanced Field Configuration: Qualifiers, Attributes, and Overrides

Delving deeper into field behavior customization.

46. What is the current object?

Answer: The current object is a server-side object available in server-side scripts (like Business Rules and Workflow scripts). It represents the current record that is being processed (e.g., the record being inserted, updated, or displayed). You use it to get and set field values on that record.

47. How to set field values on the current form?

Answer: On the server-side, using the current object:

• current.setValue('field_name', value);: Use this for most field types. For reference fields, the value should be the sys_id of the referenced record.
• current.setDisplayValue('field_name', value);: This is primarily used for reference fields. It sets the *display value* rather than the underlying sys_id. For example, you could set a user’s name instead of their sys_id, and ServiceNow would handle mapping it back to the correct sys_id.

On the client-side, you use g_form.setValue('field_name', value);.

Troubleshooting: For reference fields, using setValue with the sys_id is generally more robust than setDisplayValue unless you’re certain about the display value’s uniqueness and format.

48. What are reference qualifiers, and their types? Explain each one in detail and what is the difference between simple and dynamic, dynamic and advanced, simple and advanced.

Answer: Reference qualifiers are used to filter the records that appear in a reference or list field’s dropdown, ensuring users select only relevant items. This significantly improves data accuracy and user experience.

Three Types of Reference Qualifiers:

1. Simple Reference Qualifier

   Description: This is the most basic type, using standard query conditions (like AND, OR, WHERE clauses) to filter records. You define a fixed query directly in the reference qualifier field.

   Example: Displaying only ‘Active’ users in a reference field that points to the sys_user table.

   How to Use: In the reference field’s dictionary entry, under the ‘Reference Specification’ tab, you’ll find the ‘Reference Qualifer’ field. You can enter conditions here.

   Example Condition: active=true^department=IT

2. Dynamic Reference Qualifier

   Description: This type leverages pre-defined ‘Dynamic Filter Options’ (created under System Definition > Dynamic Filter Options). These options allow for more context-aware filtering that can adapt based on the form’s current data. They are like reusable query snippets.

   Example: Displaying only CIs that belong to the same ‘Support Group’ as the current incident’s assignment group.

   How to Use: You first create a Dynamic Filter Option that defines the filtering logic. Then, in the reference field’s dictionary entry, you select this Dynamic Filter Option from a dropdown.

3. Advanced Reference Qualifier (JavaScript Reference Qualifier)

   Description: This is the most powerful type, allowing you to use custom JavaScript code to dynamically filter records. This is ideal for complex filtering logic that depends on multiple fields on the form, user context, or server-side logic.

   Example: Filtering a list of tasks to show only those assigned to the currently logged-in user or tasks associated with a specific project status.

   How to Use: In the reference field’s dictionary entry, select ‘Advanced’ for the reference qualifier. Then, enter your JavaScript code.

   Example JavaScript: javascript: 'assignment_group=' + g_form.getValue('assignment_group') + '^priority=1'; (This example assumes you are in a client script context. For server-side or more complex scenarios, the script might look different).

Differences:

• Simple vs. Dynamic: Simple is static and fixed. Dynamic uses predefined, reusable filter logic that can be selected from a list. Dynamic is more maintainable for repeated complex queries.
• Dynamic vs. Advanced: Dynamic uses pre-configured filter options. Advanced allows you to write custom JavaScript, offering ultimate flexibility for highly specific or complex logic.
• Simple vs. Advanced: Simple uses basic AND/OR conditions. Advanced uses full JavaScript, enabling programmatic control, calculations, and access to other scriptable objects.

Troubleshooting: Always test your reference qualifiers thoroughly. For ‘Advanced’ qualifiers, ensure the JavaScript syntax is correct and that it executes without errors in the intended context (client or server).

Interview Relevance: This is a core concept for controlling data relationships and UI behavior. A detailed explanation showcases strong technical understanding.

49. What is a dependent value?

Answer: Dependent values in a dictionary entry are used to create cascaded dropdowns. This means the choices available in one field (the dependent field) are filtered based on the selection made in another field (the parent field). This is a common UI pattern for organizing choices and ensuring logical selections.

Steps to Configure Dependent Values:

1. Identify Parent and Dependent Fields: Determine which field will control the choices of another. (e.g., ‘Category’ as parent, ‘Subcategory’ as dependent).
2. Configure the Parent Field: Ensure the parent field has a defined set of choices.
3. Configure the Dependent Field: In the dependent field’s dictionary entry, find the ‘Dependent Field’ attribute and set it to the name of the parent field.
4. Define Choices: For each choice in the dependent field, you can specify which parent choice it should appear under. This is done within the Choice list configuration for the dependent field.

Example:

• Parent: Category (Choices: Hardware, Software, Network)
• Dependent: Subcategory (Dependent on Category)
  • If Category = Hardware: Choices are Laptop, Desktop, Printer.
  • If Category = Software: Choices are Operating System, Application, Database.
  • If Category = Network: Choices are Router, Switch, Firewall.

When a user selects ‘Hardware’ for Category, the Subcategory dropdown will only show Laptop, Desktop, and Printer.

Troubleshooting: Ensure the ‘Dependent Field’ attribute is correctly set and that the choices in the dependent field are properly linked to the parent field’s choices.

50. What is a calculated value?

Answer: A calculated value is a field whose value is automatically determined by a formula or expression involving other fields. This is configured directly in the field’s dictionary entry using the ‘Calculated value’ checkbox and defining a script. When the record is saved or displayed, the script runs, and the result populates the field. This is useful for fields that derive their value from existing data without direct user input.

Example: A ‘Total Price’ field calculated by multiplying ‘Quantity’ and ‘Unit Price’.

Troubleshooting: Ensure the script logic is correct and that it handles potential errors (like division by zero or invalid data types) gracefully.

51. What are attributes? Name some of the attributes that you have used.

Answer: Attributes are special keywords added to dictionary entries (fields or tables) to modify or enhance their behavior. They are typically added in the ‘Attributes’ field of a dictionary entry.

Common Attributes:

• no_email: Prevents the system from sending email notifications for changes to this field.
• no_attachment: Disables attachments for this field (or entire table if on collection).
• no_add_me: Removes the “Add Me” button from this field’s reference qualifier.
• tree_picker: Displays a reference field as a tree structure instead of a simple list.
• ref_auto_completer=...: Configures auto-completion for reference fields.
• glide_date_time: Formats a field as a date/time picker.
• max_len=...: Sets a maximum length for string fields.

Troubleshooting: Attributes are case-sensitive. Ensure they are correctly spelled and placed in the appropriate dictionary entry.

52. What is a collection field on a table?

Answer: A “collection field” in the context of a table’s dictionary entry actually refers to the entry that represents the table itself, rather than a specific field on the table. When you create a table, ServiceNow automatically creates a dictionary entry for that table. Any attributes or properties (like the read-only checkbox or attributes like no_attachment) applied to this collection entry affect the entire table, not a single field. For example, applying no_attachment to the table’s collection entry will disable attachments for all records of that table.

53. How to enable/disable attachments on the form using attributes?

Answer: You can disable attachments on a form by adding the no_attachment attribute to the collection field of the table. This is done within the dictionary entry for the table itself. If you want to enable attachments, you would remove this attribute or ensure it’s not present.

54. What are dictionary overrides? What properties can we override in dictionary overrides?

Answer: A dictionary override allows you to modify the definition of a field that exists in a parent table for a specific child table. This is incredibly useful for customizing behavior without altering the base OOB table. You can override almost any property defined in the original dictionary entry, including:

• Default value
• Mandatory status
• Read-only status
• Display status (though typically only one display field per table is allowed)
• Max length
• Choice list configuration (e.g., changing choices or making them dependent)
• Reference qualifiers
• Attributes
• Help text

Example: The priority field might have a default value of 4 in the task table, but you can use a dictionary override on the incident table to change its default value to 5 and make it mandatory.

Troubleshooting: Ensure the field you are overriding exists in the parent table and that the override is applied to the correct child table.

Navigating ServiceNow: Application Menus, Processes, and Policies

Understanding how users access functionality and how system behavior is controlled.

55. What are application menus?

Answer: Application menus (also known as modules) are navigational links that appear in the left-hand navigation menu of ServiceNow. They group related lists, forms, or reports under a parent application (like “Incident,” “Problem,” or a custom application). When a user clicks an application menu item, it typically takes them to a list view of records or a specific form. They are crucial for organizing and making ServiceNow’s functionalities easily accessible to end-users.

Troubleshooting: If a user can’t see a particular form or list, check if the corresponding application menu and module are correctly configured and if the user has the necessary roles to access it.

56. What is a process flow?

Answer: A process flow (or flow designer flow, or visual workflow) visually represents the sequence of steps or states a record goes through during its lifecycle. It provides users with a clear indication of where they are in a process and what the next steps are. For example, in an incident, a process flow might show states like ‘New’, ‘In Progress’, ‘On Hold’, and ‘Resolved’. This visual aid helps users understand the workflow and guides them through the required actions.

57. What are data lookup rules?

Answer: Data lookup rules are used to automatically populate field values on a form based on the values of other fields on the same form. They are configured in a separate table (sys_data_lookup) and allow you to create “if-then” logic for data population. For example, if a user selects a specific ‘Country’ on a form, a data lookup rule could automatically populate the ‘State/Province’ field with a relevant default value. They are a powerful tool for reducing manual data entry and ensuring data consistency.

Troubleshooting: Ensure the lookup rules are correctly defined with the right source and target fields and that the matching conditions are accurate.

58. What are UI policies?

Answer: UI Policies are client-side scripts that dynamically change the behavior of form elements based on conditions. They are used to make fields mandatory, read-only, visible, or hidden, and to show or hide related lists. UI Policies are executed when a form loads and can also be triggered by changes to field values on the form. They provide a more user-friendly way to manage form behavior compared to writing custom client scripts for every scenario.

Interview Relevance: A fundamental tool for client-side form customization.

59. What is the ‘global’ checkbox in UI policies?

Answer: When the ‘Global’ checkbox is checked on a UI Policy, it means that the UI Policy will apply to all views of the form it’s associated with. If unchecked, you would need to specify which views the UI Policy should apply to. Checking ‘Global’ simplifies management for policies that should consistently affect all user experiences with that form.

Troubleshooting: If a UI Policy isn’t working as expected, check if it’s set to Global or if the correct view is specified.

60. What is ‘Reverse if false’ in UI policies?

Answer: The ‘Reverse if false’ option dictates what happens to the UI Policy’s actions when the UI Policy’s condition evaluates to false. If checked, the actions performed when the condition was true will be reversed. For example, if a field was made mandatory when the condition was true, checking ‘Reverse if false’ would make it optional again when the condition becomes false. This is useful for toggling field properties dynamically.

Troubleshooting: Use this thoughtfully; it can simplify logic but also lead to unexpected behavior if not carefully considered.

61. What is the ‘On Load’ checkbox in a UI policy?

Answer: The ‘On Load’ checkbox determines whether the UI Policy’s conditions and actions are evaluated and applied immediately when the form is loaded. If checked, the policy runs as soon as the form appears. If unchecked, the UI Policy’s actions will only trigger when a specific field’s value changes on the form or when other defined conditions are met dynamically. This allows for policies that only activate based on user interaction rather than initial load.

62. What is the ‘Inherit’ checkbox?

Answer: When the ‘Inherit’ checkbox is checked on a UI Policy, it means that the same UI Policy will be applied to any child tables that extend the table on which the UI Policy is defined. This is a powerful way to ensure consistent form behavior across tables that share a common parent and inherit its structure.

Troubleshooting: Be mindful of unintended consequences when inheriting UI Policies. Test thoroughly on child tables.

63. Can you write script in a UI policy?

Answer: Yes, you can! Within a UI Policy, you can enable the ‘Run scripts’ checkbox in the UI Policy Actions. This allows you to associate client-side JavaScript with specific UI Policy actions. This script will execute when the UI Policy’s conditions are met and the associated action is triggered, enabling more complex client-side manipulations beyond basic visibility, mandatory, or read-only settings.

Troubleshooting: Ensure the ‘Run scripts’ checkbox is enabled for both the UI Policy and the specific UI Policy Action where you want to add script. Also, be aware of the context (client-side only).

64. Can we convert a UI policy as a data policy?

Answer: Yes, ServiceNow provides a convenient way to convert UI Policies into Data Policies. You can open the UI Policy and find an option (often a related link or button) like “Convert this to a Data Policy”. This process can save time and effort when you need to enforce data consistency on both client and server.

65. Which are all the cases where a UI policy cannot be converted as a data policy?

Answer: While most UI Policy functionalities can be converted, there are specific scenarios where direct conversion isn’t possible or appropriate:

• Controlling Data Visibility (client-side only): If a UI Policy’s primary purpose is to hide or show fields (client-side only) without affecting data integrity, it might not directly translate to a data policy, which focuses more on data validation and enforcement.
• Controlling Views: UI Policies can sometimes influence view switching or display elements specific to views. Data Policies generally do not have this capability.
• Controlling Related Lists: Showing or hiding related lists dynamically is typically a UI Policy function, not a Data Policy one.
• Controlling Scripts (client-side specific logic): Complex client-side scripts within UI Policies that perform actions beyond data validation (e.g., manipulating UI elements in ways not related to data) might not be directly convertible.

In these cases, you might need to re-evaluate the requirements and implement them using Data Policies for server-side logic and potentially other client-side scripting for UI-specific behavior.

66. What are Data policies?

Answer: Data Policies are server-side (and can have client-side execution) rules used to enforce data consistency and integrity across all data sources in ServiceNow. They make fields mandatory, read-only, or visible based on defined conditions, regardless of whether the data is entered via a form, imported, or accessed via API. This ensures that data standards are maintained uniformly, preventing orphaned or inconsistent data. Unlike UI Policies, which are purely client-side, Data Policies provide a more robust enforcement mechanism by operating on the server.

Interview Relevance: Understanding the distinction and synergy between UI Policies and Data Policies is crucial for robust data governance.

By thoroughly understanding these scenario-based questions, you’ll be well-equipped to demonstrate your expertise in ServiceNow’s CMDB, ITSM processes, scripting capabilities, and data management principles. This knowledge is invaluable for both passing technical interviews and excelling in your day-to-day role.