Mastering ServiceNow UI Action Scenario Questions: Your Comprehensive Guide

Navigating the complexities of ServiceNow often involves understanding how different components interact, especially when it comes to user interface actions and data manipulation. For many ServiceNow professionals, particularly those in administrator, developer, or support roles, acing technical interviews is a crucial step. A significant portion of these interviews revolves around practical scenarios and your ability to demonstrate a deep understanding of ServiceNow’s architecture and best practices. This article dives into common UI action scenario questions, offering not just answers but also practical explanations, real-world examples, and interview relevance to help you shine.

Understanding the ServiceNow Ecosystem

Before we jump into specific questions, it’s important to establish a baseline understanding of your environment. Knowing your current ServiceNow version and your journey through past releases provides context for your experience and the features you’re familiar with.

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

Answer: Washington DC – the latest one.

Human Touch: When asked this, a confident answer like “I’m currently working with the Washington DC release, which is the latest major version” shows you’re up-to-date. You can also add a brief mention of a key feature you’ve been leveraging in that release if appropriate and you’re comfortable discussing it.

Interview Relevance: This question assesses your current exposure to the platform’s features and potential. Companies often prefer candidates who are familiar with recent releases, as they are more likely to be aware of new functionalities and best practices.

2. From which version did you start working?

Answer: Rome, San Diego, Tokyo, Utah, Vancouver, Washington DC.

Human Touch: A response like, “My ServiceNow journey began with the Rome release, and I’ve since worked through San Diego, Tokyo, Utah, Vancouver, and I’m now on Washington DC,” paints a clear picture of your progression and evolving experience on the platform. It highlights your dedication to staying current.

Interview Relevance: This question gauges the breadth and depth of your experience. A longer list indicates more time spent on the platform, exposure to multiple upgrade cycles, and adaptation to evolving features and methodologies.

User and Group Management: The Foundation of Access Control

Effective access control is paramount in any IT system. In ServiceNow, this is managed through users, groups, and roles. Understanding how these elements interact and how to manage them programmatically is fundamental.

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

Answer: Yes, we can add roles to users and groups manually or via scripting using GlideRecord. The best practice is to grant permissions via groups. This way, when an employee leaves the organization, removing them from the relevant group automatically revokes all their associated roles and permissions. This streamlines user lifecycle management and enhances security.

Human Touch: “Absolutely, permissions in ServiceNow are primarily managed through roles. While you can assign roles directly to users, the industry-standard best practice is to assign roles to groups. This makes managing user access significantly more efficient. For instance, if a team needs access to a specific module, you create a group, assign the necessary roles to that group, and then add users to the group. When someone joins or leaves that team, you simply add or remove them from the group, and their permissions update automatically. It’s a cleaner, more scalable approach.”

Interview Relevance: This is a critical question about security and administration. Demonstrating an understanding of best practices shows you can design robust and manageable security models.

4. What is the user table name?

Answer: sys_user

Interview Relevance: A basic but important question to ensure you know the core tables of the platform.

5. What is the group member table name?

Answer: sys_user_grmember

Troubleshooting: If you forget this table name, think about the relationship: a *user* is a *member* of a *group*. This logical connection can help you recall or deduce sys_user_grmember.

Interview Relevance: Tests your knowledge of core tables related to user and group relationships.

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

Answer: By using GlideRecord as follows:

var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username = 'jdoe';
userGr.firstname = 'John';
userGr.lastName = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.insert();

Human Touch: “Creating users programmatically is a common requirement for automation. We typically use a GlideRecord operation on the sys_user table. You initialize a new record, populate the essential fields like username, first name, last name, and email, and then call insert() to create the record.”

Interview Relevance: Assesses your scripting abilities and understanding of basic CRUD (Create, Read, Update, Delete) operations in ServiceNow.

7. How to create a group using a script?

Answer: By using GlideRecord as follows:

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Testing Group'; // More descriptive name
// Ensure the manager sys_id is valid for your instance
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1';
newGr.email = 'testing@tcs.com';
newGr.description = 'This is a test group created via script.';
newGr.insert();

Human Touch: “Similar to creating users, creating groups is done via GlideRecord on the sys_user_group table. You’d initialize a new record and then set properties like the group’s name, a manager (using their sys_id), an email address, and a description before inserting it.”

Troubleshooting: Always ensure you’re using valid sys_ids for fields like ‘manager’. If the script fails, check the system logs for specific error messages related to invalid references.

Interview Relevance: Demonstrates your ability to script administrative tasks, essential for automation and bulk operations.

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

Answer:
When you add a permission (role) to a user, a record in the sys_user_has_role table is created. We can add a role to a user via script as follows:

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize(); // Good practice to initialize for a new record
userRole.setValue('user', 'sys_id_of_user'); // Replace with actual user sys_id
userRole.setValue('role', 'sys_id_of_role'); // Replace with actual role sys_id
userRole.insert();

For groups: When we add a permission to a group, a record is created inside the sys_group_has_role table. We can add a role to a group via script as follows:

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize(); // Good practice to initialize for a new record
grpRole.setValue('group', 'sys_id_of_group'); // Replace with actual group sys_id
grpRole.setValue('role', 'sys_id_of_role'); // Replace with actual role sys_id
grpRole.insert();

Human Touch: “Adding roles is handled through intermediate tables. To give a user a role, you’d insert a record into sys_user_has_role, linking the user and the role sys_ids. For groups, it’s the sys_group_has_role table, serving the same purpose. Remember, using setValue() is clear, but you can also set these directly like userRole.user = 'some_sys_id';.”

Troubleshooting: Ensure the sys_ids for both the user/group and the role are correct. An invalid role sys_id will prevent the assignment. Always check your instance for the correct role name and its corresponding sys_id.

Interview Relevance: This demonstrates your understanding of how roles are managed under the hood and your scripting capability to automate permission assignments.

9. What exactly does user delegation mean in ServiceNow?

Answer: User delegation allows one user to perform tasks and access resources on behalf of another user within an organization. This is typically used when the original user is unavailable, such as during vacation or leave. The delegated user gains the necessary permissions to act on behalf of the original user for specific tasks like approvals, notifications, or assignments during a defined period. This ensures business continuity.

Human Touch: “User delegation is a really useful feature for ensuring that critical work doesn’t stop when someone is out of office. It allows a designated colleague to step in and handle things like approving requests or responding to notifications as if they were the original user. You can configure it by going to the original user’s record, scrolling down to the ‘Delegates’ related list, and specifying who the delegate is, the date range, and what specific actions they can perform on your behalf.”

Interview Relevance: Shows your understanding of features that support business continuity and user management workflows.

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

Answer:
Adding a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize(); // Initialize for a new record
grMem.user = 'sys_id_of_user'; // Replace with actual user sys_id
grMem.group = 'sys_id_of_group'; // Replace with actual group sys_id
grMem.insert();

Removing a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', 'sys_id_of_user'); // Specify the user to remove
grMem.addQuery('group', 'sys_id_of_group'); // Specify the group
grMem.query();
if (grMem.next()) {
    grMem.deleteRecord(); // Delete the found record
}

Human Touch: “Managing group memberships is a core administrative task. To add a member, you create a new record in the sys_user_grmember table, linking the user and group via their sys_ids. To remove someone, you query this same table for the specific user-group combination and then delete the resulting record. It’s important to ensure you’re deleting the correct record to avoid unintended consequences.”

Troubleshooting: When removing a user, if grMem.next() returns false, it means the user is not currently a member of that group, so no action is needed. Double-check the sys_ids and the table name (sys_user_grmember).

Interview Relevance: Assesses your ability to script user management tasks, a common requirement for automating onboarding/offboarding processes.

User Interface and User Experience in ServiceNow

ServiceNow offers multiple ways to interact with its platform, and understanding these different interfaces is key to providing a seamless user experience.

11. How many user interfaces are there in ServiceNow?

Answer: UI15, UI16, and the Next Experience UI.

Human Touch: “ServiceNow has evolved its user interface over time. We have the older UI15 and UI16, and the modern, responsive interface known as the Next Experience UI. Most current implementations are either on UI16 or have transitioned to the Next Experience UI, which offers a more contemporary look and feel.”

Interview Relevance: Shows awareness of the platform’s evolution and current UI trends. This can be relevant if the role involves UI customization or user experience improvements.

Web Services and System Access

Integrating ServiceNow with other systems often involves understanding how external applications interact with the platform.

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

Answer: A web services user is an account specifically created to allow third-party applications to connect to ServiceNow for data exchange (e.g., via REST or SOAP). These users are not intended for manual login into the ServiceNow instance as a regular end-user and typically have specific, limited roles.

Human Touch: “When you have an external application that needs to pull data from or push data into ServiceNow, you often create a dedicated ‘web services user’. This account is configured with specific credentials and roles that grant it the necessary permissions for API calls, but it won’t have the ability to log into the standard ServiceNow interface. It’s all about secure, programmatic integration.”

Interview Relevance: Crucial for understanding integration patterns and security for system-to-system communication.

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

A fundamental concept in ServiceNow development is the distinction between client-side and server-side scripting. Understanding how to access the current user’s information in both contexts is vital.

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

Answer: g_user.userID;

Human Touch: “On the client-side, for example, within a Client Script, you can easily access the current user’s sys_id using the global variable g_user.userID. This is commonly used to dynamically set fields or control UI elements based on who is logged in.”

Interview Relevance: Tests your knowledge of client-side scripting and global objects.

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

Answer: gs.getUserID();

Human Touch: “For server-side scripting, such as in Business Rules, Script Includes, or Workflow activities, you use the GlideSystem API. The method to get the current user’s sys_id is gs.getUserID().”

Interview Relevance: Tests your knowledge of server-side scripting and the GlideSystem API.

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

Answer: gs.getUser().isMemberOf('group name'); // Returns true if part of the specified group, false otherwise.

Human Touch: “This is a very common check in server-side scripts. You can use gs.getUser().isMemberOf('GroupName'). It’s straightforward and returns a boolean value, making it easy to use in conditional logic within your scripts.”

Troubleshooting: Ensure you are using the exact ‘Name’ of the group, not its sys_id, for this method. Case sensitivity might also be a factor depending on your ServiceNow instance configuration.

Interview Relevance: Demonstrates understanding of user context and conditional logic in server-side scripting.

Security and Access Control Lists (ACLs)

Security is paramount, and Access Control Lists (ACLs) are ServiceNow’s primary mechanism for enforcing data access policies.

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

Answer: security_admin

Interview Relevance: A fundamental question about security administration in ServiceNow. Knowing this role is essential for anyone working with ACLs.

17. What is impersonation?

Answer: Impersonation allows an administrator or a user with specific roles to temporarily log in and act as another user. This is invaluable for testing, troubleshooting, and understanding user-specific issues without needing their credentials.

Human Touch: “Impersonation is a powerful tool for support and testing. It lets you ‘become’ another user for a short period, seeing the platform exactly as they would. This is incredibly helpful for diagnosing issues they might be experiencing or for testing how certain configurations or permissions affect their experience.”

Interview Relevance: Shows your understanding of administrative tools for troubleshooting and testing.

User Preferences and Customization

ServiceNow allows users to tailor their experience to some extent.

18. What is a user preference?

Answer: User preferences are settings that individual users can configure to personalize their ServiceNow experience. These settings, such as theme, list column visibility, or form layout, only affect the specific user who made the changes and do not have a global impact.

Human Touch: “Think of user preferences as your personal settings within ServiceNow. For example, you can choose which columns appear on a list view, or adjust certain display settings. These changes are unique to your user account and don’t affect how anyone else sees the platform. It’s all about letting users tailor their workspace to their liking.”

Interview Relevance: Demonstrates understanding of user-level customization capabilities.

ITSM Processes: Incident, Problem, and Change Management

These three modules are the backbone of ServiceNow’s IT Service Management (ITSM) capabilities. Understanding their definitions, relationships, and how they interact is crucial.

19. What is an Incident?

Answer: An incident is a disruption to a standard IT service that degrades the quality of service. It’s typically reported by an end-user and requires a quick resolution to restore normal service operation as soon as possible.

Human Touch: “An incident is basically something that’s broken or not working as expected for an end-user. It’s about restoring service quickly. For example, if your email client suddenly stops working, that’s an incident that needs to be addressed immediately to get you back online.”

Interview Relevance: Core ITSM knowledge. Understanding incidents is fundamental for any role involving support or service delivery.

20. What is a Problem?

Answer: A problem is the underlying cause of one or more incidents. The goal of problem management is to identify the root cause of recurring or potential incidents and to prevent them from happening again. If the same issue affects multiple users simultaneously, it’s often handled as a problem with multiple incidents linked to it.

Human Touch: “While an incident is about fixing something that’s broken *right now*, a problem is about finding out *why* it broke, especially if it keeps happening. If many users are suddenly unable to access a specific application, that’s a major incident. The team would then investigate to find the root cause, which would be the ‘problem’. Fixing the problem prevents future incidents of that type. Sometimes, multiple incidents are grouped under a single problem.”

Interview Relevance: Differentiates between reactive (incident) and proactive (problem) IT management, showing a deeper understanding of ITSM.

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

Answer: Yes, if an issue is repeatedly occurring and a root cause analysis is needed, a problem record can be created from an incident.

Human Touch: “Absolutely. If a support agent is dealing with an incident and realizes this isn’t an isolated issue – perhaps they’ve seen similar reports or suspect a recurring underlying cause – they can easily raise a problem record directly from the incident form. This kicks off the process of root cause identification.”

Interview Relevance: Demonstrates understanding of the workflow between incident and problem management.

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

Answer: Yes, when a support engineer identifies that a change in the system (software, hardware, etc.) is required to resolve an incident or prevent future incidents, they can initiate a change request from the incident.

Human Touch: “Definitely. If resolving an incident requires making a modification to the IT infrastructure – like deploying a patch, reconfiguring a server, or updating an application – the incident can be used as the trigger to create a change request. This ensures that the change is properly documented, assessed, approved, and implemented.”

Interview Relevance: Shows understanding of how incidents can drive proactive changes, linking incident and change management.

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

Answer: Using GlideRecord as follows:

var gr = new GlideRecord('incident');
gr.initialize();
// Assigning a user (caller_id) requires their sys_id
gr.caller_id = '86826bf03710200044e05d94'; // Replace with actual caller sys_id
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
// Assigning a CI (cmdb_ci) requires its sys_id
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Replace with actual CI sys_id
gr.short_description = 'Test record created via script';
gr.description = 'This incident was generated programmatically for testing purposes.';
// Assigning an assignment group requires its sys_id
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Replace with actual group sys_id
gr.insert();

Human Touch: “Creating incidents programmatically is common for integrations or automated alerts. You’d use GlideRecord on the incident table, initialize a new record, and then populate fields like the caller, category, short description, and assignment group, referencing them by their sys_ids. Finally, call insert().”

Troubleshooting: Ensure all referenced sys_ids (caller, CI, assignment group) are valid and belong to the correct record types. Incorrect sys_ids are a frequent cause of script failures when creating records.

Interview Relevance: Assesses your scripting capabilities for core ITSM processes.

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

Answer: Using GlideRecord as follows:

var gr = new GlideRecord('problem');
gr.initialize();
// Assigning a caller requires their sys_id
gr.caller_id = '86826bf03710200044e05d94'; // Replace with actual caller sys_id
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
// Assigning a CI requires its sys_id
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Replace with actual CI sys_id
gr.short_description = 'Test problem record created via script';
gr.description = 'This problem was generated programmatically.';
// Assigning an assignment group requires its sys_id
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Replace with actual group sys_id
gr.insert();

Human Touch: “Similar to incidents, you can create problem records with GlideRecord on the problem table. The process involves initializing, populating essential fields like caller, category, and short description, and then inserting the record. Keep in mind that problem management often involves linking related incidents, which is typically done after the problem is created.”

Troubleshooting: The same troubleshooting advice for incident creation applies here: verify all sys_ids.

Interview Relevance: Reinforces your scripting skills for ITSM processes.

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

Answer: Using GlideRecord as follows:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'inquiry'; // Common categories are 'Normal', 'Standard', 'Emergency'
gr.subcategory = 'antivirus'; // Adjust as per your change categories
// Assigning a CI requires its sys_id
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Replace with actual CI sys_id
gr.short_description = 'Test change request created via script';
gr.description = 'This change request was generated programmatically.';
// Assigning an assignment group requires its sys_id
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Replace with actual group sys_id
// For change requests, you might also need to set type, risk, etc.
// gr.type = 'normal';
// gr.risk = 'low';
gr.insert();

Human Touch: “Creating change requests via script follows the same GlideRecord pattern on the change_request table. Beyond basic fields, change requests often require specifying the change type (Normal, Standard, Emergency), risk assessment, and potentially other fields crucial for the change management process. Make sure to populate these as needed.”

Troubleshooting: Change requests have more complex field requirements than incidents or problems. Ensure you are setting essential fields like `type` and potentially `assignment_group` and `cmdb_ci` correctly, as these can impact the change’s lifecycle and workflow.

Interview Relevance: Demonstrates your ability to script complex ITSM processes, including change management.

Automation and Business Rules: Driving Workflows

Business Rules are the workhorses for automating actions based on record changes. Understanding how to leverage them for process automation is key.

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

Answer: Write an After Business Rule on the Incident table.

// Business Rule: Close Child Incidents
// Table: Incident
// When: After
// Update: true
// Condition: current.state.changesTo(7) // Assuming 7 is the value for 'Closed' state

if (current.state == 7 && current.parent == '') { // Check if it's a parent incident being closed
    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
        }
    }
}

Human Touch: “This is a classic automation scenario. You’d create an ‘After Business Rule’ on the incident table. The rule triggers when the ‘State’ field changes to ‘Closed’ (assuming ‘7’ represents closed). Inside the rule, we query for all incidents where the ‘Parent’ field matches the sys_id of the currently closing incident. For each found child, we set its state to ‘Closed’ and update it. It’s important to only update children that aren’t already closed to avoid unnecessary updates.”

Troubleshooting:

• State Values: Ensure the state value (e.g., 7 for Closed) is correct for your instance. You can check this in the Dictionary entry for the ‘State’ field on the Incident table.
• Parent Field: The logic assumes parent incidents have an empty ‘Parent’ field. Verify this is true for your setup.
• Infinite Loops: Be cautious with ‘After’ rules. If a child update were to trigger another rule that incorrectly modified the parent, you could face an infinite loop. Ensure your conditions are precise.

Interview Relevance: This question tests your understanding of Business Rules, their execution context (before/after, update/insert), and how to script relational record updates.

27. There is an incident with 2 associated tasks. When closing the incident, if any incident task is open, the user should not be able to close the incident. Similarly for problem and change request.

Answer: Use a Before Business Rule on the Incident, Problem, and Change Request tables.

For Incident (using incident_task):

// Business Rule: Prevent Incident Closure with Open Tasks
    // Table: Incident
    // When: Before
    // Operations: Update
    // Condition: current.state.changesTo(7) // Assuming 7 is Closed state

    var grTask = new GlideRecord('incident_task');
    grTask.addQuery('incident', current.sys_id);
    // Assuming state '3' is Closed for incident_task. Adjust if necessary.
    grTask.addQuery('state', '!=', 3);
    grTask.query();

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

Human Touch: “This is a crucial validation requirement. For incidents, you’d implement a ‘Before Business Rule’ on the Incident table. This rule runs *before* the incident state is updated to ‘Closed’. Inside the rule, we query the incident_task table for any tasks linked to the current incident. If we find any task that is *not* in a closed state, we display an error message to the user using gs.addErrorMessage() and then use current.setAbortAction(true) to stop the incident from being closed. You would create similar rules for Problem and Change Request, querying their respective task tables (e.g., problem_task, change_task).

Troubleshooting:

• Task Table Names: Ensure you’re querying the correct task table (incident_task, problem_task, change_task).
• State Values: Verify the correct state values for ‘Closed’ in the task tables.
• Conditions: The condition on the Business Rule (e.g., current.state.changesTo(7)) should precisely capture when closure is attempted.

Interview Relevance: Tests your understanding of ‘Before’ Business Rules for validation, setAbortAction(), and querying related records.

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

Answer: Write an After Business Rule on the Problem table.

// Business Rule: Close Associated Incidents on Problem Closure
    // Table: Problem
    // When: After
    // Update: true
    // Condition: current.state.changesTo(7) // Assuming 7 is Closed state

    if (current.state == 7) { // If the problem is being closed
        var grIncident = new GlideRecord('incident');
        grIncident.addQuery('problem_id', current.sys_id); // Link by problem_id
        grIncident.addQuery('state', '!=', 7); // Find incidents not already closed
        grIncident.query();

        while (grIncident.next()) {
            grIncident.state = 7; // Set the incident state to Closed
            grIncident.update(); // Update the incident
        }
    }

Human Touch: “Similar to closing parent incidents, this requires an ‘After Business Rule’ on the Problem table. When a problem’s state changes to ‘Closed’, this rule will find all incidents linked to that problem (using the problem_id field) and update their state to ‘Closed’ as well. This ensures that once the root cause is addressed and the problem is resolved, all related disruptions are also marked as closed.”

Troubleshooting:

• Field Names: Ensure the field linking incidents to problems is correctly identified (typically problem_id on the incident table).
• State Values: Confirm the state value for ‘Closed’ in the incident table.
• Recursive Logic: Be mindful if closing an incident then triggers another rule that could affect the problem. Use the ‘After’ context carefully.

Interview Relevance: Reinforces understanding of ‘After’ Business Rules and managing relationships between ITSM records.

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

Answer:

• Incident: Addresses immediate service disruptions to restore normal service operation quickly. Focuses on symptoms.
• Problem: Investigates the root cause of recurring or potential incidents to prevent future occurrences. Focuses on the cause.
• Change: Manages planned modifications to the IT environment, often initiated by findings from Problem Management or as a resolution for Incidents. Focuses on planned alterations.

The typical flow: A user reports an Incident. If it’s recurring or severe, a Problem record is created to find the root cause. The solution to the problem might involve implementing a planned modification, leading to a Change Request. Once the change is successfully implemented, it can resolve the original problem and prevent future incidents.

Human Touch: “Think of it as a response cycle. An Incident is the urgent fix – ‘The service is down, let’s get it back up!’ A Problem is the detective work – ‘Why did it go down, and how do we stop it from happening again?’ A Change is the action taken based on that detective work – ‘We need to update this server to prevent it from failing.’ They’re interconnected: incidents can highlight problems, and problems often lead to changes.”

Interview Relevance: A foundational question for ITSM. It tests your ability to articulate the purpose and flow of these core processes.

ServiceNow Data Model and Table Management

Understanding how tables are structured, their relationships, and how they extend one another is crucial for effective development and administration.

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

Answer: Tables that do not start with x_ or u_ are generally considered out-of-the-box (OOB). Examples include: incident, problem, change_request, sc_req_item, cmdb_ci, sys_user, sys_group.

Human Touch: “Out-of-the-box tables are those provided by ServiceNow itself. You can identify them by their prefixes – they typically don’t start with x_ (for scoped apps) or u_ (for global custom tables). So, core tables like incident, problem, user (sys_user), and group (sys_user_group) are all OOB.”

Interview Relevance: Tests your familiarity with common ServiceNow tables and the naming conventions for custom vs. OOB elements.

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. Key examples include task and cmdb_ci. The cmdb_ci table is the foundation for the Configuration Management Database.

Human Touch: “Base tables are like the root of a family tree in ServiceNow’s table hierarchy. They don’t inherit fields from anywhere else, but tons of other tables inherit from them. The task table is a perfect example – incidents, problems, and change requests all extend it, inheriting common fields like ‘assigned to’, ‘state’, ‘opened’, etc. Similarly, cmdb_ci is the base for all Configuration Items.”

Interview Relevance: Demonstrates an understanding of table inheritance and the platform’s data architecture.

32. Give me some examples of task tables.

Answer: Tables that extend the task base table. Examples include: incident, problem, change_request, sc_task (Service Catalog Task), ப்படுகின்றன_task (Knowledge Article Task), approval_group (though this is more complex).

Human Touch: “When a table extends the task table, it inherits common fields and behaviors. So, incident, problem, and change_request are all prime examples. They all have fields like ‘assigned to’, ‘state’, ‘priority’, ‘opened’, and ‘due date’ because they inherit them from the task parent. This inheritance is a powerful concept for consistency.”

Interview Relevance: Further probes your understanding of table inheritance and common ITSM table relationships.

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

Answer: By default, 4 ACLs are created when you create a table if the ‘Create security rules’ checkbox is checked during table creation. If you uncheck it, no ACLs are created automatically.

Human Touch: “When you create a new table in ServiceNow, there’s a checkbox, typically labeled something like ‘Create security rules’. If you leave that checked, ServiceNow automatically generates four basic ACLs: read, write, create, and delete. These provide a starting point for access control. If you uncheck it, you’re responsible for defining all ACLs manually, which is sometimes done for highly specialized tables.”

Interview Relevance: Tests your knowledge of table creation defaults and the interplay between table creation and security configuration.

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

Answer: When creating or configuring a table, go to the ‘Control’ tab. You can specify a ‘Prefix’ (e.g., INC) and set the ‘Number of digits’ for the sequence. Ensure the ‘Auto number’ field is checked.

Human Touch: “For fields like the incident number, which need to be unique and sequentially generated, you configure ‘auto numbering’ at the table level. When defining your table or its dictionary entry, you’ll find options to set a prefix (like ‘INC’ for incident) and the desired number of digits. ServiceNow then manages a counter for this table to generate unique numbers automatically for each new record.”

Interview Relevance: Crucial for understanding how ServiceNow generates unique identifiers for records.

35. What happens when you extend a table?

Answer: When you extend a table (e.g., creating a child table that inherits from a parent), the child table automatically inherits all fields from the parent. System fields (like sys_created_on, sys_updated_on) are not duplicated in the child table; they reside in the parent. A field called ‘Class’ is created in the parent table to indicate the specific child table type of a record. A table extending multiple tables will still only have one ‘Class’ field in its top-most parent.

Human Touch: “Extending a table is like creating a specialized version of an existing one. The child table automatically gets all the fields from its parent. This is great for reusability. For example, incident extends task. It gets all the task fields plus its own unique ones. Importantly, the system fields like timestamps stay with the parent. ServiceNow uses a ‘Class’ field on the parent table to know which specific child table a given record belongs to. If a table has multiple layers of inheritance, the ‘Class’ field points to the actual child table, not just the immediate parent.”

Interview Relevance: Tests your understanding of ServiceNow’s object-oriented approach to database design and table inheritance.

36. Can you give me 10 field types?

Answer: Reference, String, List, Choice, Email, Date/Time, Date, Boolean, Integer, Journal, Attachment.

Human Touch: “ServiceNow offers a rich variety of field types to suit different data needs. Some common ones include: Reference (to link to another record), String (for text), List (multiple references), Choice (dropdown), Email, Date/Time, Date, Boolean (true/false), Integer (whole numbers), Journal (for audit trails/comments), and Attachment.”

Interview Relevance: Assesses your basic knowledge of data modeling and field types available in ServiceNow.

37. What is the difference between a temporary and a normal table?

Answer: Temporary tables (often related to import sets) store data for a limited period, typically 7 days, and usually extend the import_set_row table. Normal tables store data permanently until explicitly deleted.

Human Touch: “The key difference is data retention. ‘Normal’ tables are for your persistent data, like incidents or users, which stays there until you remove it. ‘Temporary’ tables, commonly used during data imports (like via Import Sets), are designed to hold data only for a short duration – often around 7 days – before being automatically purged. They are extensions of tables like import_set_row.”

Interview Relevance: Important for understanding data lifecycle management, especially in the context of integrations and imports.

38. Can we increase the retention period in a temporary table?

Answer: Yes, by using archive rules or potentially through specific system properties if applicable, although the primary design intent is short-term storage.

Human Touch: “While temporary tables are designed for short-term storage, you can influence their retention. For example, if you need to keep import set data for longer than the default, you might look into archive rules or ensure your import process doesn’t prematurely clean up the related temporary tables. However, it’s generally best practice to use permanent tables for data intended for long-term retention.”

Interview Relevance: Shows you understand how to manage data retention policies, even for temporary data structures.

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

Answer: Remote tables (often via Virtual Task Board or other integrations) fetch and display live data from an external source without storing it directly in the ServiceNow instance’s database. Normal tables store their data locally within ServiceNow.

Human Touch: “A ‘normal’ table, like incident, stores all its data directly within your ServiceNow instance’s database. A ‘remote’ table, on the other hand, is more like a window. It displays data that’s actually residing in an external system, and ServiceNow fetches that data in real-time when you access it. You’re not duplicating the data; you’re just viewing it live from its original source. This is often used for integrations where you want to show related information from another system without a full data import.”

Interview Relevance: Crucial for understanding data integration strategies and how ServiceNow can interact with external data sources.

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

Answer:

• One-to-Many: 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 can have many Incidents, but each Incident is assigned to one User). This is the most common relationship, often implemented using a Reference field on Table B pointing to Table A.
• Many-to-Many: One record in Table A can be related to multiple records in Table B, and vice-versa. (Example: Incidents and Groups. An Incident can be assigned to multiple groups, and a Group can be assigned to multiple Incidents). This is typically implemented using a separate ‘join’ table (like sys_user_grmember for users and groups).

Human Touch: “In ServiceNow, relationships between tables are key. A one-to-many relationship is very common: think of a User and their Incidents. One user can open many incidents, but each incident is typically opened by just one user. This is usually handled by a Reference field on the ‘many’ side (Incident) pointing to the ‘one’ side (User). A many-to-many relationship is where things get more complex. For example, an Incident might be assigned to multiple support groups, and a support group handles many incidents. To model this, ServiceNow often uses an intermediate table – like the sys_user_grmember table for users and groups – to create that many-to-many link.”

Interview Relevance: Tests your understanding of relational database concepts and how they apply to ServiceNow’s data model.

Form and Field Configuration

Customizing forms and fields is a daily task for administrators. Understanding how to control field behavior and data presentation is essential.

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

Answer:

• Forms: Manually filling out a form.
• Record Producers: User-friendly forms that create records, often from the Service Portal.
• Email: Inbound email actions can create records.
• GlideRecord Scripting: Programmatically creating records in scripts (Business Rules, Script Includes, etc.).
• Import Sets/Data Import: Importing data from Excel, CSV, or other sources.
• Web Services/APIs: Creating records via REST or SOAP calls from external systems.
• UI Actions: Buttons or links that can create related records.

Human Touch: “There are quite a few ways! The most common is directly on a form. You can also use Record Producers, which are designed for self-service and create a more guided experience. For automated scenarios, inbound email actions can create tickets, and of course, server-side scripting using GlideRecord is powerful for bulk creation or integration. Data imports from files like Excel are also standard, and external systems can create records via APIs.”

Interview Relevance: Shows you understand various methods of data input and creation within ServiceNow.

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

Answer:

• Dictionary Properties: Setting the ‘Mandatory’ or ‘Read only’ checkbox directly on the field’s dictionary entry.
• Dictionary Overrides: Overriding these properties for a specific table if the field is inherited.
• UI Policies: Client-side scripting to conditionally make fields mandatory, read-only, or visible.
• Data Policies: Server-side and client-side scripting for conditional mandatory/read-only enforcement.
• Client Scripts: Using g_form.setMandatory(true/false) or g_form.setReadOnly(true/false).
• Access Control Lists (ACLs): Can enforce read/write access at a more granular level, effectively making fields read-only for certain roles.

Human Touch: “There are several layers. The most basic is directly on the field’s dictionary entry itself, setting ‘Mandatory’ or ‘Read only’. If it’s an inherited field, you’d use a Dictionary Override for that specific table. Then, for dynamic control based on conditions, UI Policies (client-side) and Data Policies (client and server-side) are your go-to tools. And of course, Client Scripts offer the most flexibility with g_form.setMandatory() and g_form.setReadOnly(). ACLs can also indirectly make fields read-only by restricting write access.”

Troubleshooting: UI Policies and Client Scripts can sometimes conflict. Always test thoroughly to ensure the desired behavior, especially when multiple UI policies or scripts affect the same fields. Data Policies provide a more robust, server-side guarantee.

Interview Relevance: Demonstrates a comprehensive understanding of form personalization and data validation mechanisms.

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

Answer: No, you should not make 2 fields ‘display’. Only one field can be marked as ‘Display’ per table. This field is used for unique identification of records in reference fields and search results. Making more than one field ‘display’ can lead to confusion and incorrect behavior in lookup/reference fields.

Human Touch: “Technically, ServiceNow only allows you to check the ‘Display’ attribute for one field on any given table. This is intentional. The ‘Display’ field is used system-wide in things like reference lookups and search results to show a human-readable identifier for a record. If you had multiple ‘display’ fields, the system wouldn’t know which one to prioritize, leading to confusion. So, you pick the most appropriate single field, usually the name or identifier.”

Interview Relevance: Tests understanding of a specific but important dictionary attribute and its implications.

44. All tables will be stored where?

Answer: Information about all tables in ServiceNow is stored in the sys_db_object table.

Human Touch: “The metadata about every table in your ServiceNow instance – its name, label, fields, structure, and so on – is itself stored in a table called sys_db_object. It’s like a system catalog for all your database objects.”

Interview Relevance: Shows knowledge of ServiceNow’s system tables and internal architecture.

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

Answer: Default values can be set in the field’s dictionary entry. When a new record is created and the form is opened, if the field doesn’t have a value already, it will be populated with the defined default value.

Human Touch: “Setting a default value is straightforward. You do it directly in the field’s dictionary entry. For example, you could set the default value of the ‘State’ field on a new incident to ‘New’. This ensures that every time a new incident record is created, it automatically starts with that value, saving users a click.”

Interview Relevance: Basic but essential form configuration skill.

46. What is the current object?

Answer: The current object is a GlideRecord object representing the record that is currently being processed on the server-side. It’s used within server-side scripts (like Business Rules) to get and set values on the record that triggered the script.

Human Touch: “On the server-side, the current object is your handle to the record you’re currently working with. If a Business Rule fires because an incident was updated, current represents that specific incident record. You use it like current.setValue('short_description', 'New value'); or var caller = current.caller_id; to interact with the data.”

Interview Relevance: Fundamental concept for server-side scripting. You *must* know what current is.

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

Answer:

• `current.setValue(‘field_name’, value);`: Sets the raw value. For reference fields, you must provide the sys_id as the value.
• `current.setDisplayValue(‘field_name’, value);`: Sets the display value. For reference fields, you provide the human-readable value (e.g., ‘John Doe’ instead of a sys_id), and ServiceNow finds the corresponding sys_id.

Human Touch: “To set values on the record using the current object server-side, you have two main methods. setValue() is for the underlying system value. So, for a reference field like ‘Caller’, you’d pass the Caller’s sys_id. setDisplayValue() is more user-friendly; you can pass the display text (e.g., ‘John Doe’), and ServiceNow will handle finding the correct sys_id for you. This is particularly useful for reference and choice fields.”

Troubleshooting: Using setValue() with a display name for a reference field will likely fail. Always use the sys_id unless using setDisplayValue().

Interview Relevance: Tests your practical scripting knowledge for manipulating record data.

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 displayed in Reference and List type fields, ensuring users select only relevant data. There are three main types:

• Simple Reference Qualifier:
  • Description: The most basic type, allowing you to define a fixed query condition directly in the reference field’s dictionary entry.
  • Example: To show only ‘Active’ users in a ‘User’ reference field, you’d set the condition: active=true.
  • How to Use: Enter the query string in the ‘Reference qualifier’ field on the dictionary entry.
• Dynamic Reference Qualifier:
  • Description: Uses a dynamically generated query, often based on the context of the form or other field values. This is achieved by creating ‘Dynamic Filter Options’ (System Definition > Dynamic Filter Options).
  • Example: Displaying only users belonging to the same department as the caller of an incident.
  • How to Use: Create a Dynamic Filter Option, then select it from the ‘Reference qualifier’ dropdown on the dictionary entry.
• Advanced Reference Qualifier (JavaScript Reference Qualifier):
  • Description: Allows for complex filtering using JavaScript code. This offers the most flexibility for dynamic and context-aware filtering based on intricate logic.
  • Example: Filtering incidents to show only those assigned to the current user’s assignment group AND having a priority less than 3.
  • How to Use: Select ‘Advanced’ in the Reference Qualifier field and write JavaScript code that returns a query string. Example: javascript: 'assignment_group=' + current.assignment_group + '^priority<3'; (Note: `current` is available in server-side advanced qualifiers).

Differences:

• Simple vs. Dynamic: Simple uses static conditions; Dynamic uses pre-defined, context-aware filter definitions.
• Dynamic vs. Advanced: Dynamic relies on pre-configured filter options. Advanced uses custom JavaScript, offering greater power and complexity for unique scenarios.
• Simple vs. Advanced: Simple is static and basic; Advanced is dynamic and code-driven, handling much more complex logic.

Human Touch: “Reference qualifiers are essential for making reference fields user-friendly by showing only relevant records. A simple one is like adding a basic `WHERE` clause: `active=true`. A dynamic qualifier uses a pre-defined filter option that can adapt, perhaps based on the logged-in user. An advanced qualifier is pure JavaScript; you write custom code to construct the query, giving you maximum control for very specific filtering needs.”

Troubleshooting: When using advanced qualifiers, ensure your JavaScript syntax is correct and that the `current` object (if used) is available in that context. Syntax errors in advanced qualifiers can prevent the reference field from loading at all.

Interview Relevance: A very common and important question that tests your understanding of data filtering and UI customization.

49. What is a dependent value?

Answer: Dependent values are used in dictionary entries to create cascaded dropdowns. The available choices in one field (the dependent field) are filtered based on the selection made in another field (the parent field).

Steps to Configure:

1. Identify the parent and dependent fields (e.g., Category -> Subcategory).
2. Configure choices for the dependent field, linking each choice to a specific parent field value.
3. In the dependent field’s dictionary entry, set the ‘Dependent Field’ attribute to the name of the parent field.

Example: For Category and Subcategory, if you select ‘Hardware’ in Category, the Subcategory dropdown will only show options like ‘Laptop’, ‘Desktop’, etc. If you select ‘Software’, it might show ‘Operating System’, ‘Application’.

Human Touch: “Dependent values are how you create those linked dropdown menus, like selecting a ‘Category’ and then having the ‘Subcategory’ options dynamically update. You define the relationship in the dictionary – you tell the Subcategory field, ‘Your choices depend on what’s selected in the Category field.’ Then, you map specific subcategory options to each category choice. It significantly improves data entry accuracy and user experience.”

Interview Relevance: Demonstrates knowledge of form design and improving data input efficiency.

50. What is a calculated value?

Answer: A calculated value is a field whose value is not directly entered but is computed based on other fields using a formula or script defined in the field’s dictionary entry. This is often done using the ‘Calculation’ attribute on the dictionary entry.

Human Touch: “When you need a field to automatically derive its value from other fields – for example, calculating a ‘Total Price’ by multiplying ‘Quantity’ and ‘Unit Price’ – you use a calculated field. You define the formula or a simple script directly in the field’s dictionary entry, and ServiceNow computes it whenever the source fields change. It’s a server-side calculation.”

Interview Relevance: Tests understanding of how to create fields that automatically derive their data.

51. What are attributes, and name some of the attributes you have used?

Answer: Attributes are special keywords applied to dictionary entries (fields) or table collection entries that modify their behavior or appearance on the UI.
Common Attributes:

• no_email: Disables email notifications for changes to this field.
• no_attachment: Prevents attachments from being added to records of this table.
• ref_auto_completer=none: Disables the auto-complete feature for reference fields.
• tree_picker: Displays a reference field as a tree structure.
• display=true: Marks the field as the display value for the table.
• readonly: Makes the field read-only.
• mandatory=true: Makes the field mandatory.

Human Touch: “Attributes are like hidden superpowers for your fields. You add them to the dictionary entry, and they change how the field behaves. For example, no_email stops notifications for that specific field, no_attachment on the table prevents any attachments, and tree_picker gives you a nice hierarchical view for reference fields. There are many, many more!”

Interview Relevance: Shows practical knowledge of how to customize field behavior beyond basic settings.

52. What is a collection field on a table?

Answer: A dictionary entry with the ‘Collection’ type represents the table itself, not a specific field on the table. Attributes or properties applied to this entry affect the entire table (e.g., enabling attachments, setting table-level attributes). This entry is automatically created when a table is created.

Human Touch: “When you create a table, ServiceNow also creates a special dictionary entry for that table itself – this is the ‘collection’ entry. Think of it as the table’s own properties. Attributes applied here, like no_attachment=true, apply to the entire table, meaning no records in that table can have attachments. It’s distinct from field-level attributes.”

Interview Relevance: Understanding the table’s own dictionary entry is key to managing table-level configurations.

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

Answer: To disable attachments for a table, add the attribute no_attachment=true to the collection field (the dictionary entry for the table itself) in the dictionary.

Human Touch: “To control attachments at the form level for an entire table, you use the no_attachment attribute. You add this attribute to the table’s ‘collection’ dictionary entry. Setting it to true will disable the attachment icon and functionality for all records of that table.”

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

54. What are dictionary overrides, and what properties can be overridden?

Answer: Dictionary overrides allow you to change the behavior or attributes of a field in a child table without altering the original field definition in the parent table. You can override properties such as the default value, display status, mandatory flag, read-only status, choice list, reference qualifier, and many other dictionary attributes.

Human Touch: “Dictionary overrides are incredibly useful when dealing with table inheritance. Let’s say the ‘Priority’ field in the base ‘Task’ table has a default value of ‘4’. If for the ‘Incident’ table, you want the default priority to be ‘5’, you create a dictionary override for the ‘Priority’ field on the ‘Incident’ table. This lets you customize inherited fields on a per-table basis. You can override almost any dictionary attribute: default values, mandatory status, choice lists, reference qualifiers, and much more.”

Interview Relevance: Critical for understanding how to customize inherited fields and maintain a clean OOB configuration.

ServiceNow Navigation and UI Configuration

Understanding how users navigate the platform and how to organize content is important for user adoption.

55. What are application menus?

Answer: Application menus (often referred to as modules) are entries in the left-hand navigation menu. They allow users to access specific forms, lists, reports, or dashboards within an application. They are created under System Definition > Application Menus.

Human Touch: “Application menus, or modules, are the items you see in the left-hand navigation pane. For example, under ‘Incident’, you might have modules like ‘Open Incidents’, ‘All Incidents’, or ‘My Work’. They’re the primary way users get to the different views and functionalities within ServiceNow applications.”

Interview Relevance: Basic navigation and UI organization knowledge.

56. What is a process flow?

Answer: A process flow (or flow designer, visual task board) visually represents the stages or steps in a particular workflow or process. It helps users understand where they are in a process and what the next steps are.

Human Touch: “A process flow is like a visual roadmap for a workflow. On a record form, it might show you icons or steps representing ‘New’, ‘In Progress’, ‘On Hold’, ‘Resolved’, ‘Closed’. It gives users a clear indication of the current status and guides them through the expected sequence of actions. ServiceNow uses this in various places, including Visual Task Boards and some core ITSM forms.”

Interview Relevance: Understanding how to visualize and guide users through complex processes.

57. What are data lookup rules?

Answer: Data lookup rules (found under System UI > Data Lookup Rules) allow you to automatically populate field values on a record based on matching values in other fields. For instance, when a user is selected, their department or location might be automatically populated into corresponding fields on the same form.

Human Touch: “Data lookup rules are a clever way to pre-populate fields based on other data. Imagine selecting a ‘Caller’ on an incident form. A data lookup rule could automatically fill in their ‘Department’ and ‘Location’ based on that caller’s record. It’s a great way to reduce manual data entry and ensure consistency. You define matching criteria between fields and specify which fields to populate.”

Interview Relevance: Demonstrates knowledge of data automation and form efficiency tools.

UI Policies vs. Data Policies

These are two powerful tools for controlling form behavior and data integrity, but they operate differently.

58. What are UI policies?

Answer: UI Policies are client-side scripts used to dynamically change form behavior (making fields mandatory, read-only, visible/invisible) based on certain conditions. They run in the browser.

Human Touch: “UI Policies are client-side tools. They’re like mini-scripts that run in the user’s browser to change how a form looks or behaves in real-time. You can use them to make a field mandatory only if another field has a certain value, or to hide fields that aren’t relevant. They offer immediate visual feedback to the user.”

Interview Relevance: Core UI customization knowledge.

59. What is the global checkbox in UI policies?

Answer: When checked, the UI Policy will apply to all views of the form. If unchecked, you can specify which view(s) the UI Policy should apply to.

Human Touch: “The ‘Global’ checkbox on a UI Policy determines its scope. If it’s checked, that UI Policy will try to apply its logic to the form no matter which view the user is looking at. If it’s unchecked, you can then specify particular view names, meaning the policy only runs when the user is in one of those designated views. This gives you fine-grained control over where your UI policies take effect.”

Interview Relevance: Understanding scope and view-specific configurations.

60. What is “Reverse if false” in UI policies?

Answer: If checked, the actions defined in the UI Policy will be reversed when the UI Policy’s conditions evaluate to false. For example, if a field was made mandatory when the condition was true, it will become optional again when the condition is false.

Human Touch: “This is a really handy feature for UI Policies. When ‘Reverse if false’ is checked, it means that whatever changes the UI Policy makes (like making a field mandatory or visible) will be undone if the condition that triggered it is no longer met. For instance, if a field is mandatory when ‘Status’ is ‘Open’, checking ‘Reverse if false’ ensures that field becomes optional again if the ‘Status’ changes to ‘Closed’.”

Interview Relevance: Shows understanding of conditional logic and dynamic form behavior.

61. What is the “On Load” checkbox in UI policy?

Answer: When checked, the UI Policy’s conditions and actions are evaluated and applied as soon as the form loads. If unchecked, the UI Policy actions only trigger when specific field changes occur on the form that meet the policy’s conditions.

Human Touch: “The ‘On Load’ checkbox dictates when a UI Policy first checks its conditions. If it’s checked, the policy runs the moment the form opens, setting up the UI as per its rules. If it’s unchecked, the policy only kicks in when something on the form changes that matches its conditions. This is useful if you only want UI changes to happen dynamically rather than setting the initial state of the form.”

Interview Relevance: Understanding UI policy execution timing and initial form state control.

62. What is the “Inherit” checkbox?

Answer: When checked, the UI Policy will also apply to child tables that extend the table on which the UI Policy is defined.

Human Touch: “The ‘Inherit’ checkbox is crucial for managing UI Policies across an inheritance hierarchy. If you have a UI Policy on a parent table (like task) and you check ‘Inherit’, that same UI Policy will automatically be applied to all child tables that extend it (like incident, problem, etc.). This saves you from having to recreate the same policies multiple times.”

Interview Relevance: Demonstrates understanding of how UI Policies interact with table inheritance.

63. Can you write script in a UI policy?

Answer: Yes, you can write scripts within a UI Policy by enabling the “Run scripts” checkbox within the UI Policy Actions. This allows for more complex client-side logic.

Human Touch: “Absolutely. While UI Policies are largely declarative, they do have the capability for scripting. Within the UI Policy Actions, you’ll find a ‘Run scripts’ checkbox. If you enable that, you can write client-side JavaScript to perform more advanced actions that aren’t covered by the standard UI Policy actions.”

Interview Relevance: Shows you know how to extend UI Policy functionality with custom scripting.

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

Answer: Yes, you can convert a UI Policy into a Data Policy. There’s typically a button or option within the UI Policy form itself (e.g., “Convert to Data Policy”) to facilitate this conversion.

Human Touch: “Yes, ServiceNow provides a convenient way to convert UI Policies into Data Policies. If you have a UI Policy that handles mandatory or read-only logic and you want that logic to be enforced server-side as well, you can often find a ‘Convert to Data Policy’ link or button directly on the UI Policy form. This helps ensure data integrity across all interfaces.”

Interview Relevance: Understanding migration paths and tool equivalencies.

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

Answer: UI Policies that control UI-specific behaviors that don’t directly translate to data integrity cannot be fully converted. This includes:

• Controlling data visibility (e.g., making a field visible/invisible). Data Policies enforce data *integrity*, not UI presentation.
• Controlling views.
• Controlling related lists.
• Complex scripting that relies purely on client-side DOM manipulation or browser events not replicable server-side.

Human Touch: “While many UI Policies can be converted, there are limitations. Data Policies are primarily about data integrity (is it mandatory, is it read-only). If your UI Policy’s main job is to hide a field based on a condition, make a related list appear, or manage form views, those actions don’t have a direct equivalent in a Data Policy because they’re purely presentation layer. Complex client-side scripts that interact directly with the browser’s DOM might also be problematic to convert.”

Interview Relevance: Highlights the distinction between client-side UI control and server-side data governance.

66. What are data policies?

Answer: Data Policies enforce data integrity by making fields mandatory or read-only based on conditions. They operate on both the client-side (for immediate user feedback) and the server-side (ensuring data integrity regardless of how the record is accessed). They are crucial for maintaining consistent data across all entry points.

Human Touch: “Data Policies are your go-to for enforcing data integrity. They can make fields mandatory or read-only, similar to UI Policies, but critically, they work on both the client *and* the server. This means that even if someone bypasses the UI (e.g., via an API call), the data policy still enforces the rules. They are essential for maintaining clean and consistent data in your instance.”

Interview Relevance: Core concept for data governance and ensuring data quality in ServiceNow.

Mastering these scenario-based questions requires more than just memorization; it demands a deep understanding of how ServiceNow works under the hood. By preparing thoroughly with practical examples and understanding the ‘why’ behind each answer, you’ll be well-equipped to tackle your next technical interview with confidence.