Answer: “I’m currently working with the **Washington DC** release. It’s always exciting to be on the latest platform, as it offers the most up-to-date features and performance enhancements.”

Human Touch: Be honest and specific. If you’re not on the absolute latest, mention the most recent stable version you’re comfortable with. The key is to demonstrate awareness of the platform’s evolution.

Troubleshooting Tip: If you’re unsure about your instance’s version, navigate to “System Diagnostics” > “About” in the application navigator. This will show you the exact release information.

Answer: “My ServiceNow journey began with the **Rome** release. Since then, I’ve had the opportunity to work with subsequent versions including San Diego, Tokyo, Utah, Vancouver, and now Washington DC.”

Human Touch: This question assesses your experience trajectory and how you’ve adapted to platform changes. Listing out the versions shows progressive involvement.

Interview Relevance: This helps the interviewer understand your depth of experience and whether you’ve kept up with significant platform updates. Mentioning specific features or challenges from earlier versions can be a bonus.

Answer: “Absolutely, permissions are fundamental in ServiceNow, and they are managed through roles. You can add roles to individual users directly via their user record, or more effectively, assign roles to groups. When a user is a member of a group, they inherit all the roles assigned to that group.

The best practice is to assign roles to groups rather than individual users. This adheres to the principle of ‘least privilege’ and significantly simplifies user management. When an employee joins or leaves an organization, you simply add or remove them from the relevant groups, and their access rights are automatically updated. This prevents orphaned roles and ensures consistent security policies.”

Real-world Example: Imagine a group called ‘IT Service Desk Agents’. You assign the ‘itil’ role to this group. Any user added to the ‘IT Service Desk Agents’ group automatically gains the ‘itil’ role, allowing them to manage incidents without manually assigning the role to each individual agent.

Troubleshooting Tip: If a user isn’t getting the expected permissions, first check their user record to see their assigned groups. Then, check the roles assigned to those groups. Use the “Roles” related list on the group record and the “Groups” related list on the user record.

Answer: “The primary table for user information in ServiceNow is sys_user.”

Interview Relevance: This is a foundational question to ensure you know the basic table structures you’ll be interacting with, especially in scripting.

Answer: “The table that links users to groups is sys_user_group_member.”

Human Touch: This table is crucial for managing group memberships and understanding relationships between users and groups.

Answer: “You can create a user account using a GlideRecord operation on the sys_user table. Here’s a typical example:

var userGr = new GlideRecord('sys_user');
userGr.initialize(); // Prepare a new record
userGr.username = 'jdoe';
userGr.firstname = 'John';
userGr.lastName = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.password = gs.generatePassword(); // Optional: Generate a secure password
userGr.insert(); // Commit the new record to the database
        

Explanation:

• new GlideRecord('sys_user'): Initiates a GlideRecord object to interact with the user table.
• initialize(): Clears any existing data and prepares the GlideRecord for a new record insertion.
• Setting fields like username, firstname, lastName, email: Populates the required fields for the new user.
• insert(): Saves the new user record to the sys_user table.

Troubleshooting Tip: Always check for duplicate usernames or emails before inserting to avoid errors. You can use userGr.get('username', 'jdoe') to check for existence.

Answer: “Similar to user creation, you use GlideRecord on the sys_user_group table:

var newGr = new GlideRecord('sys_user_group');
newGr.initialize(); // Prepare for a new group
newGr.name = 'Service Catalog Admins';
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // sys_id of the manager
newGr.email = 'catalog.admins@example.com';
newGr.description = 'Group for managing Service Catalog items';
newGr.insert(); // Save the new group
        

Explanation:

• new GlideRecord('sys_user_group'): Targets the group table.
• initialize(): Sets up for a new record.
• Setting fields like name, manager (using the manager’s sys_id), email, and description.
• insert(): Creates the group record.

Interview Relevance: This demonstrates your understanding of administrative scripting tasks, which are common in ServiceNow implementations.

Answer: “Permissions (roles) are managed through relationship tables.

To add a role to a user: You interact with the sys_user_has_role table.

var userRole = new GlideRecord('sys_user_has_role');
userRole.setValue('user', 'sys_id_of_the_user'); // sys_id of the user
userRole.setValue('role', 'sys_id_of_the_role'); // sys_id of the role
userRole.insert();
        

To add a role to a group: You interact with the sys_group_has_role table.

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.setValue('group', 'sys_id_of_the_group'); // sys_id of the group
grpRole.setValue('role', 'sys_id_of_the_role'); // sys_id of the role
grpRole.insert();
        

Explanation:

• sys_user_has_role: This table creates a link between a user and a role.
• sys_group_has_role: This table links a group to a role.
• You need the sys_id of both the user/group and the role you’re assigning. You can find role sys_ids in the sys_role table.

Troubleshooting Tip: Always ensure the user/group and role records actually exist before attempting to create the link. Check for existing entries to avoid duplicates.

Answer: “User delegation in ServiceNow allows one user to perform actions on behalf of another user. This is incredibly useful when a primary user is unavailable, such as during vacations, leave, or extended absences. The delegated user gains the necessary permissions to access resources and perform tasks that the original user would normally handle.

Real-world Example: Think of a manager who needs to approve requests. If the manager goes on vacation, they can delegate their approval tasks to a senior team member. This ensures that critical approvals aren’t delayed.

In ServiceNow, this is configured on the original user’s record. You’d go to their user form, scroll down to the ‘Delegates’ related list, and specify the delegate (who is doing the work), the start and end dates of the delegation, and what specific tasks or permissions the delegate can handle (e.g., approvals, notifications).”

Interview Relevance: This question tests your understanding of user management and process continuity features within ServiceNow, which are crucial for operational efficiency.

Answer: “This involves interacting with the sys_user_group_member table.

To add a group member:

var grMem = new GlideRecord('sys_user_group_member');
grMem.user = 'sys_id_of_the_user'; // The user to add
grMem.group = 'sys_id_of_the_group'; // The group to add them to
grMem.insert();
        

To remove a group member:

var grMem = new GlideRecord('sys_user_group_member');
grMem.addQuery('user', 'sys_id_of_the_user'); // The user to remove
grMem.addQuery('group', 'sys_id_of_the_group'); // The group to remove them from
grMem.query(); // Execute the query to find the membership record

if (grMem.next()) { // If a matching record is found
    grMem.deleteRecord(); // Remove the membership
}
        

Explanation:

• For adding, you simply create a new record in sys_user_group_member linking the user and group.
• For removing, you first query the table to find the specific membership record using both the user and group sys_ids and then delete that record.

Troubleshooting Tip: When removing, ensure your query is specific enough. If a user is in multiple groups, querying only by user might attempt to delete incorrect memberships. Always query by both user and group.

Answer: “On the client-side (within a Catalog Client Script, UI Policy, etc.), you use the global object g_user. To get the current user’s sys_id, you would use:

var currentUserId = g_user.userID;
console.log('Current User ID:', currentUserId);
        

Human Touch: This is a very common piece of scripting you’ll use to personalize catalog experiences or check user-specific conditions. g_user.userID is universally available in client scripts.

Interview Relevance: This demonstrates your understanding of client-side context objects, essential for making dynamic changes within the user interface.

Answer: “On the server-side (e.g., in Business Rules, Script Includes), you use the gs (GlideSystem) object. The method to get the current user’s sys_id is:

var currentUserId = gs.getUserID();
gs.info('Current User ID: ' + currentUserId);
        

Explanation:

• gs.getUserID(): Retrieves the sys_id of the user currently logged in or whose session is being processed.

Troubleshooting Tip: Be mindful of context. In some background scripts or scheduled jobs, there might not be an explicit ‘logged-in’ user. gs.getUserID() will return an empty string or a system user’s ID in such cases. Always test in the intended execution context.

Answer: “On the server-side, the gs.getUser() object provides a handy method for this:

// Check if the current user is a member of the 'ITIL Users' group
var isMember = gs.getUser().isMemberOf('ITIL Users'); // Provide the group name

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

Explanation:

• gs.getUser(): Gets the user object for the current user.
• isMemberOf('group name'): Returns true if the user is a member of the group whose name matches the provided string, and false otherwise.

Human Touch: This is a staple for controlling access to features or customizing catalog item behavior based on user roles and group affiliations. For example, showing or hiding a specific catalog item for certain teams.

Troubleshooting Tip: Ensure you’re using the exact, case-sensitive name of the group. If the group name changes, your script will break. It’s often safer to query by group sys_id if possible, especially in more complex scenarios.

Answer: “To create, modify, or view Access Control Lists (ACLs), you need the security_admin role. This role has elevated privileges specifically for managing security rules across the platform.”

Interview Relevance: Understanding security roles is critical for any ServiceNow administrator or developer. It shows you know how to control access to sensitive configurations.

Answer: “Impersonation in ServiceNow is the ability to log in and act as another user. This is an essential tool for administrators and developers for testing purposes. It allows you to see the platform from a specific user’s perspective, verifying their permissions, the data they can see, and how certain UI policies or client scripts behave for them.”

Human Touch: You can impersonate a user by going to the user menu (top right, usually your profile picture) and selecting ‘Impersonate User’.

Troubleshooting Tip: Always remember to stop impersonating once you’re done testing! Leaving yourself impersonating another user can lead to unintended data modifications or confusion.

Answer: “User preferences in ServiceNow allow individual users to customize their experience within the platform without affecting other users. These are personal settings that a user can change based on their own needs or preferences.

Examples:

• Display density (Compact, Comfortable, Cozy)
• Date/time formats
• List column layouts
• Email notification settings

When a user changes a preference, it’s stored in the sys_user_preference table, associated with their user record. This ensures that their customized view is retained across sessions.”

Interview Relevance: Understanding user preferences shows you grasp how ServiceNow caters to individual user needs and how these preferences can sometimes influence the behavior of scripts or UI policies (though direct manipulation of preferences is less common in catalog scripts, understanding their existence is key).

Answer: “An incident in ServiceNow represents any event that disrupts or has the potential to disrupt an organization’s IT service. It’s essentially a break in service, or a reduction in the quality of an IT service. When an employee encounters a problem that prevents them from performing their work due to a technical issue, they typically report it as an incident. The goal of incident management is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations.”

Real-world Example: Your email is not sending, your laptop won’t boot, or the company printer is offline. These are all classic examples of incidents.

Interview Relevance: While this isn’t directly a *catalog client script* question, understanding the core ITIL processes that ServiceNow supports is crucial. Catalog items often trigger incidents.

Answer: “A problem in ServiceNow is the underlying cause of one or more incidents. While incidents focus on restoring service quickly, problems focus on identifying the root cause of recurring incidents and finding a permanent solution. If the same issue keeps happening, it’s likely a problem. A problem can be identified proactively or reactively from one or more incidents. The goal is to prevent future incidents by resolving the root cause.”

Real-world Example: If multiple employees report that a specific application crashes every Tuesday morning, that recurring issue would be investigated as a problem to find the root cause and fix it permanently.

Relationship to Incidents: Often, multiple incidents can be linked to a single problem record. Closing the problem record (once the root cause is fixed) helps in closing all associated incidents or at least provides a permanent solution.

Answer: “Yes, absolutely. If a support engineer is working on an incident and realizes that this issue is recurring or has a deeper underlying cause that needs to be addressed systematically, they can create a problem record directly from the incident. This is typically done using a ‘Create Problem’ button or related link available on the incident form. This action often pre-populates the problem record with details from the incident, linking them together.”

Interview Relevance: This shows you understand the interconnectedness of IT Service Management processes within ServiceNow.

Answer: “Yes, this is a common and important workflow in ServiceNow. If, during the resolution of an incident, it’s determined that a permanent fix requires a change to the IT infrastructure or an application (e.g., deploying a patch, reconfiguring a server), a change request can be initiated from the incident. This ensures that the proposed change is properly assessed, approved, and implemented, minimizing the risk of introducing new incidents or service disruptions. Again, this is usually facilitated by a ‘Create Change Request’ button on the incident form.”

Interview Relevance: Demonstrates understanding of the SDLC and how incidents can drive proactive changes.

Answer: “You can create an incident record programmatically using GlideRecord on the incident table. Here’s an example:

var gr = new GlideRecord('incident');
gr.initialize(); // Prepare for a new incident
gr.caller_id = 'sys_id_of_the_caller'; // e.g., gs.getUserID()
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'sys_id_of_the_configuration_item'; // Optional: link to a CI
gr.short_description = 'User reporting slow system performance';
gr.description = 'The user is experiencing significant slowdowns, impacting productivity. Please investigate.';
gr.assignment_group = 'sys_id_of_the_assignment_group'; // Optional: assign to a group
gr.insert(); // Save the incident
        

Explanation:

• new GlideRecord('incident'): Targets the incident table.
• initialize(): Prepares for a new record.
• Populating fields like caller_id (who reported it), category, subcategory, cmdb_ci (the affected configuration item), short_description, description, and assignment_group.
• insert(): Creates the incident.

Interview Relevance: This is a common task for automation or integrating external systems with ServiceNow. It shows you can create core ITSM records via scripting.

Troubleshooting Tip: Ensure that the sys_ids you use for fields like caller_id, cmdb_ci, and assignment_group are valid and refer to existing records. Incorrect sys_ids will cause the insert to fail or create orphaned records.

Answer: “Similar to creating incidents, you’d use GlideRecord on the problem table:

var gr = new GlideRecord('problem');
gr.initialize(); // Prepare for a new problem
gr.caller_id = 'sys_id_of_the_reporter'; // e.g., gs.getUserID()
gr.category = 'application';
gr.subcategory = 'database';
gr.cmdb_ci = 'sys_id_of_the_affected_ci'; // e.g., the database server
gr.short_description = 'Recurring application errors impacting users';
gr.description = 'Multiple incidents have been raised regarding intermittent application errors. Investigating root cause.';
gr.assignment_group = 'sys_id_of_problem_management_group'; // e.g., Problem Management
gr.insert(); // Save the problem
        

Explanation: The structure is very similar to incident creation, but you target the problem table and use fields relevant to problem management, such as linking to related incidents if applicable (though not shown in this basic example).

Troubleshooting Tip: When creating problems from incidents, consider if you need to establish the link (e.g., using the problem_id field on the incident). This ensures proper traceability.

Answer: “Creating change requests via script follows the same GlideRecord pattern, targeting the change_request table:

var gr = new GlideRecord('change_request');
gr.initialize(); // Prepare for a new change request
gr.category = 'standard'; // Or 'normal', 'emergency'
gr.type = 'implementation'; // e.g., implementation, uninstall, upgrade
gr.cmdb_ci = 'sys_id_of_the_affected_ci'; // e.g., the server to be patched
gr.short_description = 'Apply security patch to web servers';
gr.description = 'Applying critical security patch KB12345 to all web servers in production.';
gr.assignment_group = 'sys_id_of_change_management_group'; // e.g., Change Management
gr.insert(); // Save the change request
        

Explanation: You’ll populate fields like category, type, cmdb_ci, short_description, and assign it to the appropriate group. Note that change management often involves complex workflows, so you might need to set additional fields based on your organization’s change policies.

Troubleshooting Tip: Change requests have many mandatory fields and complex approval workflows. A simple script might create the change, but it won’t necessarily pass through all stages. You’ll need to understand the specific change process and set the appropriate fields accordingly.

Answer: “This is a perfect use case for an After Business Rule on the incident table.

// Business Rule: Auto-Close Child Incidents
// Table: Incident
// When: after
// Update: true
// Condition: current.state.changesTo(7) && current.parent == ''
// Script:

(function executeRule(current, previous /*null when async*/) {

    // Check if the current incident is a parent (no parent field set) and its state is closing
    if (current.state == 7 && current.parent == '') { // Assuming state 7 is 'Closed'
        gs.info('Parent incident ' + current.number + ' is closing. Closing associated child incidents.');

        // GlideRecord to find all child incidents associated with this parent
        var grChild = new GlideRecord('incident');
        grChild.addQuery('parent', current.sys_id); // Filter by the parent's sys_id
        grChild.query();

        while (grChild.next()) {
            // Only update if the child incident is not already closed
            if (grChild.state != 7) {
                grChild.state = 7; // Set the state to Closed
                grChild.update(); // Update the child incident record
                gs.info('Closed child incident: ' + grChild.number);
            }
        }
    }

})(current, previous);
        

Explanation:

• Table: incident.
• When: after – We want this to run after the parent incident has been saved with the ‘Closed’ state.
• Update: true – This rule should trigger when an existing incident record is updated.
• Condition: current.state.changesTo(7) && current.parent == '' – This ensures the rule only fires when the state is changed to 7 (Closed) AND the incident itself is a parent (i.e., its parent field is empty).
• Script: It queries for all incidents where the parent field matches the sys_id of the current parent incident. For each found child, it sets its state to 7 (Closed) and updates it.

Troubleshooting Tip: Make sure you have the correct state value for ‘Closed’. You can find this by right-clicking the state field label on an incident and selecting “Configure Dictionary”. Also, ensure the parent field on child incidents is correctly populated.

Answer: “This scenario requires a Before Business Rule on the incident table to prevent closure if associated tasks are open.

// Business Rule: Prevent Incident Closure if Tasks are Open
// Table: Incident
// When: before
// Insert: false
// Update: true
// Condition: current.state.changesTo(3) // Assuming state 3 is 'Closed'
// Script:

(function executeRule(current, previous /*null when async*/) {

    // Check if the incident is being closed
    if (current.state == 3) { // Assuming state 3 is 'Closed'
        // GlideRecord to find open incident tasks associated with this incident
        var grTask = new GlideRecord('incident_task');
        grTask.addQuery('incident', current.sys_id); // Link to the current incident
        grTask.addQuery('state', '!=', 3); // Assuming state 3 is 'Closed' for tasks
        grTask.query();

        if (grTask.hasNext()) { // If there are any open tasks
            gs.addErrorMessage('Cannot close the incident because there are open incident tasks. Please close all associated tasks first.');
            current.setAbortAction(true); // Stop the update operation
        }
    }

})(current, previous);
        

Explanation:

• Table: incident.
• When: before – This rule must run before the incident is saved as ‘Closed’ to prevent it.
• Condition: current.state.changesTo(3) – Triggers when the state is about to change to ‘Closed’.
• Script: It queries the incident_task table, looking for tasks linked to the current incident that are NOT in a ‘Closed’ state. If any are found, it displays an error message and uses current.setAbortAction(true) to stop the incident from being closed.

Adaptation for Problem/Change: You would create similar ‘Before’ Business Rules on the problem and change_request tables, querying their respective task tables (e.g., problem_task, change_task) and applying the same logic.

Troubleshooting Tip: Ensure the state values for ‘Closed’ are correct for both incidents and their respective tasks. Mismatched states are a common pitfall. Also, verify the link between incidents and tasks (e.g., the incident field on incident_task).

Answer: “This is another scenario for an After Business Rule on the problem table.

// Business Rule: Auto-Close Incidents on Problem Closure
// Table: Problem
// When: after
// Update: true
// Condition: current.state.changesTo(7) // Assuming state 7 is 'Closed'
// Script:

(function executeRule(current, previous /*null when async*/) {

    // Check if the problem is being closed
    if (current.state == 7) { // Assuming state 7 is 'Closed'
        gs.info('Problem ' + current.number + ' is closing. Closing associated incidents.');

        // GlideRecord to find incidents associated with this problem
        var grIncident = new GlideRecord('incident');
        grIncident.addQuery('problem_id', current.sys_id); // Link to the problem's sys_id
        grIncident.addQuery('state', '!=', 7); // Only update incidents that are not already closed
        grIncident.query();

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

})(current, previous);
        

Explanation:

• Table: problem.
• When: after – After the problem is saved as ‘Closed’.
• Update: true – For updates to existing records.
• Condition: current.state.changesTo(7) – Fires when the state changes to ‘Closed’.
• Script: It queries the incident table for incidents where the problem_id matches the current problem’s sys_id. For any open incidents linked to this problem, it sets their state to ‘Closed’ and updates them.

Troubleshooting Tip: Confirm the correct state value for ‘Closed’ for both problems and incidents. Ensure the problem_id field on the incident table is correctly populated when a problem is linked.

Answer: “These three are core pillars of IT Service Management (ITSM) and have a crucial, symbiotic relationship within ServiceNow:

• Incident: The primary goal is to restore service as quickly as possible. When something breaks for a user, they raise an incident. It’s reactive and focused on immediate resolution.
• Problem: Deals with the root cause of incidents. If multiple incidents have similar symptoms, or a single incident indicates a deeper systemic issue, a problem record is created to investigate and find a permanent fix, thereby preventing future incidents. It’s proactive and aims for long-term stability.
• Change: Manages the implementation of changes to the IT environment. This could be a fix for a problem, an upgrade, a new deployment, or a configuration adjustment. The goal is to implement changes smoothly, with minimal disruption, and often, a change request is triggered by a problem resolution or even an incident workaround that needs to become permanent.

In essence:

1. A user reports an Incident.
2. If the incident is recurring or points to a systemic issue, a Problem is identified to find the root cause.
3. Resolving the Problem often requires a controlled modification to the IT environment, leading to the creation of a Change Request.
4. The successful completion of the Change resolves the underlying Problem, thus preventing future Incidents.

”

Interview Relevance: This shows you understand how ServiceNow supports core ITIL processes and how these processes integrate. It’s a broad question that demonstrates your grasp of the platform’s purpose beyond just scripting.

Answer: “Out-of-the-box (OOTB) tables are those provided by ServiceNow itself, not custom tables created by an organization. They typically do not start with x_ or u_. Some very common ones include:

• incident
• problem
• change_request
• sc_req_item (Requested Item)
• sc_cat_item (Catalog Item)
• sys_user (User)
• sys_group (Group)
• task (Base table for tasks)
• cmdb_ci (Base table for Configuration Items)
• sys_audit (Audit history)

”

Interview Relevance: Demonstrates familiarity with the core data model of ServiceNow.

Answer: “Base tables in ServiceNow are tables that don’t extend from any other table but serve as foundational structures from which many other tables inherit fields and properties. They are designed to be extended. Key examples include:

• task: This is the parent table for many task-based records like Incidents, Problems, Change Requests, and Service Catalog Tasks. It provides common fields like state, assignment group, assigned to, short description, etc.
• cmdb_ci: The base table for Configuration Items. All items within your Configuration Management Database (CMDB) extend from this table, providing common attributes for managing IT assets and services.
• cmdb: The top-level CMDB table, from which cmdb_ci and its various categories extend.
• sys_security_acl: The base table for Access Control Lists.

”

Explanation: When you extend a table, you inherit all its fields. This promotes reusability and consistency across the platform.

Answer: “As mentioned, the task table is the parent. Some common tables that extend from task are:

• incident
• problem
• change_request
• sc_task (Service Catalog Task)
• std_change_proposal (Standard Change Proposal)
• knowledge (though it extends from cmms_model, it can sometimes be associated with task-like workflows)

”

Interview Relevance: Shows understanding of the table hierarchy and how it supports efficient data management.

Answer: “When you create a new table using the ServiceNow platform interface and the ‘Create application file’ wizard or by manually creating a new table record, there’s typically a checkbox that says something like ‘Create application files’ or ‘Create sample data’. If this option is selected, ServiceNow will automatically generate four Access Control Lists (ACLs) for the new table by default. These are usually:

• A create ACL
• A delete ACL
• A read ACL
• An write ACL

If you uncheck that option during table creation, these default ACLs will not be generated.”

Interview Relevance: This question tests your knowledge of table creation best practices and security defaults.

Troubleshooting Tip: If you need to secure a table more granularly, you can always create additional ACLs after the initial table creation, or manually remove and redefine the default ones.

Answer: “To create a number field that automatically generates unique sequential numbers, similar to INC0012345, you configure it in the Dictionary Entry for that field. When defining the field’s properties:

• Go to the Control tab in the Dictionary Entry.
• Check the Auto Number checkbox.
• You’ll then define the Prefix (e.g., INC) and the Number of digits (e.g., 7 for 7 digits after the prefix).

ServiceNow then handles the incrementing and formatting automatically. For existing tables like Incident, this is already configured.”

Interview Relevance: This shows you know how to implement standard ServiceNow features for record identification and tracking.

Answer: “When you extend a table in ServiceNow, you’re essentially creating a child table that inherits all the fields and properties of its parent table. This is a powerful mechanism for reusability and establishing hierarchical data structures.

Here’s what happens:

• Inheritance: All fields from the parent table are automatically available in the child table. You don’t need to recreate them.
• No New Sys Fields: Standard system fields (like sys_created_on, sys_updated_on, sys_id, sys_mod_count) are NOT recreated in the child table. They reside in the parent and are inherited.
• Class Field: A field called class is created on the parent table. This field stores the sys_id of the actual table record that the current row belongs to. This is how ServiceNow knows whether a record in the task table is actually an incident, a problem, or a change_request.
• Single Class Field: Even if a table extends multiple other tables (though direct extension is typically one level, the concept of a ‘class’ points to its ultimate origin), it will only have one class field in its hierarchy.

”

Real-world Example: The incident table extends the task table. So, an incident has all the fields of a task (like caller, short description, state) plus its own specific fields (like impact, urgency, priority).

Interview Relevance: This demonstrates an understanding of ServiceNow’s object-oriented database model and how it facilitates platform extensibility.

Answer: “Certainly! Here are 10 common field types available in ServiceNow:

1. String: For short text entries.
2. Reference: Links to another record in a different table (e.g., linking an incident to a user).
3. Choice: A dropdown list of predefined options.
4. Date: For selecting a date.
5. Date/Time: For selecting a date and time.
6. Boolean: A true/false or checkbox field.
7. Integer: For whole numbers.
8. Decimal: For numbers with decimal places.
9. URL: For web links.
10. Email: Specifically formatted for email addresses.
11. (Bonus!) List: Allows selecting multiple records from another table.
12. (Bonus!) Journal: For free-form text entries with history, like work notes.

”

Interview Relevance: This shows you’re familiar with the fundamental building blocks of tables and forms in ServiceNow.

Answer: “The key difference lies in data retention and intended use:

• Normal Tables (e.g., incident, sys_user): These tables store data permanently. Records are created and remain in the table until they are explicitly deleted or archived according to retention policies. They are used for ongoing operational data.
• Temporary Tables (e.g., import_set_row, ecc_agent_heartbeat): These tables are designed to hold data for a limited period. They often extend the sys_import_set_row table (or similar) and are typically used for staging data during import processes, for short-term logging, or for caching transient information. Data in these tables is usually automatically purged after a predefined retention period (often around 7 days, but configurable).

”

Interview Relevance: Understanding data storage and lifecycle management is important for database design and performance tuning.

Answer: “Yes, you can increase the retention period for data in temporary tables, especially those that extend from import set tables. This is typically achieved through Archive Rules. You can configure archive rules to define how long data should be retained before being moved to an archive table or purged entirely. While the default is often around 7 days for import set rows, you can adjust this based on your business needs, though it’s important to balance retention with storage and performance considerations.”

Interview Relevance: Shows you understand data lifecycle management and archival strategies in ServiceNow.

Answer: “The primary distinction is where the data resides and how it’s accessed:

• Normal Tables (e.g., incident, sys_user): These tables store data directly within your ServiceNow instance’s database. When you query these tables, you’re retrieving data that is physically located and managed by your ServiceNow instance.
• Remote Tables (often accessed via REST/SOAP integrations or specific configurations like Data Sources for ETL): This refers to tables or data sources that reside outside of your ServiceNow instance. When you query or interact with a ‘remote table’ within ServiceNow, you are typically making a call to an external system to retrieve or process data in real-time. ServiceNow acts as an intermediary or a client to this external data.

”

Real-world Example: A normal table is your ServiceNow incident list. A remote table might be querying a customer’s ERP system for order status via a ServiceNow integration.

Interview Relevance: This question probes your understanding of data integration and ServiceNow’s ability to interact with external systems.

Answer: “These 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 many Incidents (Table B). Each incident is assigned to one user, but a user can be assigned many incidents. The User field on the incident table is a reference to the sys_user table.
• Many-to-Many Relationship: This is a more complex relationship where one record in Table A can relate to multiple records in Table B, AND one record in Table B can relate to multiple records in Table A. These are typically implemented using an intermediary table.
  
  Example: Incidents and Groups. An incident might be assigned to multiple groups for different types of work, and a single group (e.g., Network Team) can be assigned many incidents. The sys_user_group_member table is a classic example of enabling many-to-many between users and groups.
• One-to-One Relationship: Less common, where one record in Table A is related to exactly one record in Table B, and vice versa. This might be used for specific extensions where a child table has a unique, singular relationship to its parent or another related record. For instance, some specialized configuration might have a one-to-one link.

”

Interview Relevance: Understanding relationships is key to designing effective data models and building robust integrations.

Answer: “There are several ways to create records in ServiceNow tables, catering to different use cases:

1. Forms: The standard graphical user interface where users manually fill in fields and click ‘Submit’ or ‘Save’.
2. Record Producers: A catalog item type that creates a record in a table when submitted, often mapping catalog variables to table fields. This is very common for Service Catalog requests.
3. GlideRecord (Scripting): Using JavaScript’s GlideRecord API in Business Rules, Client Scripts, Script Includes, etc., to programmatically create records.
4. Email: ServiceNow can be configured to automatically create records (like incidents or tickets) from incoming emails.
5. Import Sets / Data Import: Using features like ‘Load Data’ or scheduled imports to bulk create records from files (CSV, Excel, XML) or external data sources.
6. REST API / SOAP Web Services: Creating records from external applications by sending data to ServiceNow’s web service endpoints.
7. Scheduled Jobs: Scripts that run on a schedule can create records as part of automated processes.

”

Interview Relevance: Shows breadth of knowledge on how data gets into ServiceNow.

Answer: “There are multiple ways to control the visibility, mandatory status, and read-only nature of fields in ServiceNow, depending on whether you need client-side or server-side enforcement:

Client-Side (UI):

• Dictionary Properties: You can set a field as ‘Mandatory’ or ‘Read only’ directly on the field’s Dictionary Entry. This is a baseline setting.
• UI Policies: These are powerful client-side scripts that can dynamically change a field’s visibility (show/hide), make it mandatory/optional, or set it as read-only/editable based on conditions evaluated on the form.
• Client Scripts (g_form): Using JavaScript functions like g_form.setMandatory(), g_form.setReadOnly(), and g_form.setVisible() directly within client scripts (e.g., OnLoad, OnChange).

Server-Side (Data Enforcement):

• Dictionary Overrides: Similar to dictionary properties but allows you to override parent table field attributes in a child table.
• Data Policies: These provide server-side (and client-side rendering) enforcement of mandatory and read-only attributes, similar to UI Policies but enforced at the data layer, meaning they apply regardless of how the record is accessed (UI, API, Import).
• Business Rules: You can use server-side scripts in Business Rules to set field values or make them read-only under specific conditions before a record is saved.
• Access Control Lists (ACLs): While primarily for read/write access to records and fields, ACLs can effectively make fields read-only by denying write access.

”

Interview Relevance: This is a fundamental question about UI and data control, crucial for building secure and user-friendly applications.

Answer: “No, you should not make more than one field as ‘Display’ in a table. The ‘Display’ checkbox on a field’s Dictionary Entry signifies that this field should be used to represent the record when it appears in reference fields or search results.

Why only one? If multiple fields were marked as ‘Display’, ServiceNow wouldn’t know which one to prioritize. This would lead to unpredictable behavior, confusion in displaying records in reference lookups, and potential issues with search functionality.

Best Practice: Typically, a unique identifier like ‘Name’ or ‘Number’ is chosen as the display field. For example, on the sys_user table, the name field is marked as display. On the incident table, number is the display field.

”

Interview Relevance: This tests your understanding of database design principles and ServiceNow’s specific limitations and best practices.

Answer: “All table definitions in ServiceNow are stored in a special meta-table called sys_db_object. This table holds information about every table defined on the platform, including its name, label, columns, attributes, and other schema-related details. When you create a new table or modify an existing one, you are essentially creating or modifying records within sys_db_object and its related tables.”

Interview Relevance: Shows you understand the underlying meta-data management of the ServiceNow platform.

Answer: “There are several ways to set a default value for a field in ServiceNow:

1. Dictionary Entry: The most straightforward method is to set a default value directly in the field’s Dictionary Entry. There’s a ‘Default value’ field where you can enter a static value. This value will be pre-populated whenever a new record of that table is created.
2. OnLoad Client Script: For dynamic default values that depend on other fields or the current user, you can use an OnLoad Client Script. Using g_form.setDefaultValue('field_name', value);, you can set a default value when the form loads.
3. Dictionary Overrides: If you’re extending a table and want to set a default value for a field that differs from the parent table’s default, you can use a Dictionary Override.
4. Business Rules (onInsert): For server-side defaults that are more complex or depend on other server-side logic, you can use an ‘After’ or ‘Before’ Business Rule that runs on insert, setting the default value using current.setValue('field_name', value);.

”

Interview Relevance: This is a common requirement for improving user experience and ensuring data consistency.

Real-world Example: Setting the ‘State’ field to ‘New’ by default on incident creation, or setting the ‘Caller’ field to the currently logged-in user via an OnLoad Client Script.

Answer: “The current object is a special variable available in server-side scripting environments like Business Rules and Fix Scripts. It represents the record being processed at that moment.

• On Insert: When a new record is inserted, current refers to the record being created.
• On Update: When an existing record is updated, current refers to the record with its newly modified values.
• On Delete: When a record is deleted, current refers to the record that is about to be deleted.

You use the current object to get and set values of fields on the record in context. For example, current.setValue('short_description', 'New value');.”

Interview Relevance: Essential for server-side scripting. It’s the gateway to manipulating the record you’re working on.

Answer: “You use the current object with methods like setValue() and setDisplayValue().

• current.setValue('field_name', value);: This is the standard method to set a field’s value. For reference fields, you must provide the sys_id of the referenced record. For choice lists, you provide the actual choice value. For strings, numbers, dates, etc., you provide the corresponding data type.

  
  // Setting a string field
  current.setValue('short_description', 'Updated description');
  
  // Setting a reference field (e.g., Caller)
  current.setValue('caller_id', 'sys_id_of_the_user');
                  

• current.setDisplayValue('field_name', value);: This method is particularly useful for reference fields. Instead of providing the sys_id, you provide the display value (e.g., the user’s name). ServiceNow will attempt to find the correct sys_id based on this display value. It can also work for choice lists.

  
  // Setting a reference field using display value
  current.setDisplayValue('caller_id', 'Abel Tuter');
                  

”

Interview Relevance: Crucial for understanding how to manipulate data server-side, a fundamental skill.

Troubleshooting Tip: When using setValue for reference fields, if you get an error or the field remains blank, double-check that you have the correct sys_id. If using setDisplayValue and it doesn’t work, ensure the display value you are providing exactly matches an existing record’s display value (case-sensitive sometimes) and that it’s not ambiguous.

Answer: “Reference qualifiers are powerful tools used to filter the records that appear in reference fields (and list fields). They restrict the choices a user sees, making it easier to select the correct related record and preventing invalid selections.

There are three main types of Reference Qualifiers:

1. Simple Reference Qualifier

Description: This is the most basic form. You define a static query using field names and operators (=, !=, >, <, STARTSWITH, ENDSWITH, CONTAINS, IN, etc.) directly in the reference qualifier field. It filters records based on predefined conditions.

Example: On an Incident form, for a ‘Configuration Item’ reference field, you might want to show only ‘Active’ CIs. The simple reference qualifier would be: active=true.

How to Use: Navigate to the Dictionary Entry of the reference field. In the ‘Reference qualifier’ field, select ‘Simple’ and enter your query.

2. Dynamic Reference Qualifier

Description: This type uses a ‘Dynamic Filter Option’ which is a reusable query definition. This allows for more flexibility and consistency across different fields. Dynamic filter options can be created by administrators and then selected in the reference qualifier, providing a way to manage complex filtering logic centrally.

Example: Suppose you want to show only users from the same country as the caller of an incident. You could create a dynamic filter option that defines this logic, and then use it as a dynamic reference qualifier for a ‘User’ reference field.

How to Use:

1. Go to System Definition > Dynamic Filter Options.
2. Create a new dynamic filter option, defining your query logic.
3. On the reference field’s Dictionary Entry, select ‘Dynamic’ for the reference qualifier and choose your created dynamic filter option from the dropdown.

3. Advanced Reference Qualifier (JavaScript Reference Qualifier)

Description: This is the most powerful type, allowing you to write custom JavaScript code to dynamically build and apply the query. This is used for very complex filtering logic that cannot be achieved with simple or dynamic qualifiers. The script usually returns a encoded query string. The getRefQual function in a Client Script can also be used for this.

Example: Displaying only ‘Active’ users who are members of a specific group, or users who have a specific role, based on the current form’s context. A script might look like: javascript: 'active=true^sys_idIN' + gs.getUserIDs(); (though this example is very basic, complex ones can involve multiple conditions and lookups).

How to Use: On the reference field’s Dictionary Entry, select ‘Advanced’ for the reference qualifier and enter your JavaScript code that returns an encoded query string.

Differences Explained:

• Simple vs. Dynamic:
  • Simple: Static, embedded query. Good for one-off, unchanging filters.
  • Dynamic: Reusable query definition managed centrally. Better for consistency and easier maintenance if the same logic is needed in multiple places.
• Dynamic vs. Advanced:
  • Dynamic: Uses predefined ‘Dynamic Filter Options’ which are essentially pre-built encoded queries. Less coding, more configuration.
  • Advanced: Requires custom JavaScript. Offers ultimate flexibility to build queries on the fly, incorporating complex logic, current form values, or server-side data.
• Simple vs. Advanced:
  • Simple: Basic, static filtering. Easy to implement for straightforward needs.
  • Advanced: Full JavaScript control. Necessary for highly dynamic or conditional filtering that requires script execution.

”

Interview Relevance: This is a critical question for anyone working with reference fields, which are ubiquitous in ServiceNow. It shows your ability to refine user input and control data relationships.

Troubleshooting Tip: When a reference qualifier isn’t working as expected, check the browser’s JavaScript console for errors. Also, ensure your query syntax is correct. For advanced qualifiers, use gs.info() or gs.log() within your script (if running server-side) to debug the generated query string.

Answer: “Dependent values in ServiceNow are used to create cascaded dropdowns, where 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 very common UI pattern for organizing choices logically.

How it works:

1. Parent Field: This field has a set of predefined choices.
2. Dependent Field: This field also has choices, but these choices are only displayed if they are linked to the currently selected value in the parent field.

Example:
Consider the classic ‘Category’ and ‘Subcategory’ fields on an Incident form.

• Parent Field: Category (e.g., Hardware, Software, Network)
• Dependent Field: Subcategory (e.g., Laptop, Printer, Operating System, Database, Router)

If a user selects ‘Hardware’ as the Category, the Subcategory dropdown should only show options like ‘Laptop’, ‘Desktop’, ‘Printer’. If they select ‘Software’, it should show options like ‘Operating System’, ‘Application’, ‘Database’.

Configuration:
This is configured within the Dictionary Entry of the dependent field.

1. Open the Dictionary Entry for the Subcategory field.
2. In the Attributes field, add the attribute: dependent_field=category (replace category with the actual field name of your parent field).
3. Then, for each choice you create for the Subcategory field, you specify which parent choice it is dependent on.

”

Interview Relevance: Understanding dependent values is key to creating intuitive and user-friendly forms, especially in Service Catalog items where complex options need to be presented logically.

Troubleshooting Tip: Ensure the ‘dependent_field’ attribute in the Dictionary Entry is correctly set to the API name of the parent field. Also, verify that each choice in the dependent field is correctly linked to a choice in the parent field.

Answer: “A calculated value in ServiceNow refers to a field whose value is not entered directly by a user but is automatically computed based on other fields or logic. This is typically achieved through a ‘Calculated’ type field in the Dictionary Entry.

When you set a field to ‘Calculated’:

• You provide a JavaScript expression or script that ServiceNow will evaluate.
• The result of this script will be the value stored in the field.
• This calculation can happen on the client-side (e.g., in an OnLoad or OnChange script using g_form.setValue()) or, more commonly, on the server-side.

Server-Side Calculation Example:
If you have a field ‘Full Name’ on the sys_user table, you could make it a calculated field with a script like:

// Script in Dictionary Entry for 'Full Name' field
var firstName = current.getValue('first_name');
var lastName = current.getValue('last_name');
return firstName + ' ' + lastName;
        

Whenever the ‘first_name’ or ‘last_name’ fields are updated, the ‘Full Name’ field will automatically re-calculate and display the combined name.

”

Interview Relevance: This demonstrates an understanding of how to automate data population and maintain data integrity through derived values.

Answer: “Attributes in ServiceNow are special properties added to a field’s Dictionary Entry that modify or enhance the field’s behavior or appearance. They are key-value pairs that tell the platform how to render and interact with the field.

Commonly used attributes include:

• no_email: Prevents email notifications from being sent for changes to this field. Useful for fields that are updated frequently by system processes.
• no_attachment: Prevents users from adding attachments to records where this field is present (though this is more typically controlled at the table level or via security rules). The more common use is to disable attachments on a specific form view.
• readonly: Makes the field read-only. This is functionally similar to setting the field as read-only in the Dictionary, but attributes offer a more flexible way to apply behavior.
• tree_picker: Transforms a reference field into a tree-like picker interface, useful for hierarchical data like CI classes or locations.
• dependent_field=parent_field_name: As discussed earlier, used to create cascaded dropdowns.
• ref_qual_elements=element1,element2: Used in conjunction with reference qualifiers to pass values from other fields on the form into the qualifier’s script or query.
• max_length=X: Limits the character count for a String field.
• dynamic_filter_now=true: For date fields, it allows the ‘dynamic’ option to filter based on the current date (e.g., “Last week”).

”

Interview Relevance: Attributes are fundamental for fine-tuning field behavior, and knowing them shows practical experience with the platform’s customization capabilities.

Answer: “A ‘collection field’ on a table isn’t a standard field type you add directly. Instead, the term ‘collection’ in this context refers to the table itself. When you’re looking at the Dictionary Entry for a table (not a specific field), it’s often referred to as a ‘Collection Entry’.

Changes made to this ‘Collection Entry’ (the table’s record in sys_db_object) affect the entire table. For example:

• Setting Attributes on the table definition (like no_attachment applied to the table) would disable attachments for all records in that table.
• Checking the Read only checkbox on the table definition would make all fields on that table read-only by default.
• Defining the table’s label, name, and extension.

This entry is automatically created when a table is created and defines the metadata for the entire table. It’s distinct from a field’s dictionary entry, which defines a specific column within the table.”

Interview Relevance: Shows understanding of ServiceNow’s metadata and how table properties are managed.

Answer: “You can disable attachments on a form by adding the no_attachment attribute. This is typically done on the Dictionary Entry for the table (the ‘Collection Entry’).

Steps:

1. Navigate to System Definition > Tables.
2. Find and open the Dictionary Entry for your table (e.g., incident).
3. In the Attributes field, add no_attachment.
4. Save the record.

This will remove the paperclip icon and the attachments section from the form for that table, effectively disabling attachments for all users on that form.

”

Interview Relevance: Demonstrates practical knowledge of controlling form behavior using attributes.

Answer: “Dictionary overrides allow you to change the attributes of a field in a child table without affecting the parent table or other child tables. It’s a way to customize inherited fields.

Use Case: Imagine the Task table has a field ‘Priority’ with default values. If you want the ‘Priority’ field on the Incident table to have different default values, or be mandatory while it’s optional on the parent, you use a dictionary override.

Properties that can be overridden include:

• Default value: Set a different default value for the field.
• Mandatory: Make the field mandatory (or uncheck it to make it optional).
• Read only: Make the field read-only (or uncheck it).
• Maximum length: Change the allowed length for String fields.
• Attributes: Add or remove attributes that apply specifically to this field in the child table.
• Reference Qualifiers: Modify the reference qualifier applied to a reference field.
• Display Value: Although generally not recommended to change the display value setting on an overridden field, it is technically possible.
• Label: Change the display label of the field.

Configuration:

1. Navigate to System Definition > Dictionary.
2. Find the Dictionary Entry for the field in the parent table.
3. Right-click the header and select Dictionary Overrides.
4. Click New and select your child table, then specify the overridden properties.

”

Interview Relevance: This is a key concept for extending and customizing ServiceNow tables effectively, showing an understanding of table inheritance and specialization.

Answer: “Application Menus (also known as Modules) are navigational elements in the ServiceNow application navigator (the left-hand side menu). They are used to group related lists, forms, and other views under a specific application or module name, making it easier for users to find and access functionality.

When you create a new application or a new module within an existing application, you are defining an Application Menu. For example, under ‘Incident’, you have modules like ‘Open’, ‘All’, ‘Assigned to me’, etc. These are all Application Menus that point to specific reports, lists, or forms.

They are essential for organizing the user interface and providing a structured way for users to interact with ServiceNow data and processes.”

Interview Relevance: Shows understanding of UI navigation and how users access ServiceNow features.

Answer: “Process flow in ServiceNow, often referred to as ‘Process Flow Designer’ or ‘Flow Designer’ (though Flow Designer is a more modern automation tool), is a visual representation of a workflow or a sequence of steps in a business process. It helps to map out and automate complex sequences of tasks.

In the context of a form or record, a ‘process flow’ might refer to a visual indicator showing the current stage of that record’s lifecycle. For instance, on an Incident form, you might see a visual representation of stages like ‘New’, ‘In Progress’, ‘On Hold’, ‘Resolved’, ‘Closed’.

Flow Designer is ServiceNow’s modern low-code tool for automating multi-step processes that can involve tasks, approvals, notifications, and integrations, often triggered by specific events.”

Interview Relevance: Demonstrates awareness of process automation and visual workflow tools within ServiceNow.

Answer: “Data lookup rules are a feature that allows you to automatically populate fields on a form based on the values of other fields on the same form. They are configured separately from dictionary entries and UI policies, offering a dedicated mechanism for creating cascaded lookups.

How they work:

• You define a set of conditions (e.g., if ‘Category’ is ‘Hardware’).
• For each condition, you specify which field’s value in the current record should be used to look up a value in another table.
• Then, you specify which field in the looked-up table contains the value to populate, and which field on the current form should receive that value.

Example:
If a user selects ‘Laptop’ as the Subcategory on an Incident, a data lookup rule might automatically populate the ‘Configuration Item’ field with a default laptop CI, or set a specific assignment group based on the laptop model.

They are typically configured under System UI > Data Lookup Rules.”

Interview Relevance: Shows you know about efficient ways to pre-populate forms and reduce manual data entry.

Answer: “UI Policies are client-side scripts that run on the browser to dynamically change the behavior of form fields. They are a powerful, low-code alternative to Client Scripts for many common form manipulations.

UI Policies can be used to:

• Make fields mandatory or optional.
• Make fields read-only or editable.
• Make fields visible or hidden.
• Set default values for fields.
• Show or hide related lists on a form.

They are configured using conditions (similar to Business Rules) and UI Policy Actions, which define what happens to specific fields when the conditions are met. They are evaluated when the form loads (‘On Load’) and can also be triggered by changes to other fields (‘On Change’).”

Interview Relevance: This is a cornerstone of ServiceNow form customization. Understanding UI Policies is essential for making forms dynamic and user-friendly.

Answer: “When the ‘Global’ checkbox is checked on a UI Policy, it means that the UI Policy will be evaluated and applied across all views of the form. This is the default behavior for most UI Policies.

If you uncheck the ‘Global’ checkbox, you will then be prompted to specify a particular View name. In this case, the UI Policy will only apply to that specific view of the form. This is useful when you have different views of the same form designed for different roles or purposes, and you want distinct UI behaviors for each view.”

Interview Relevance: Shows you understand how to control the scope and application of UI policies across different user interfaces.

Answer: “‘Reverse if false’ is a crucial checkbox on a UI Policy Action. When it’s checked, the actions defined in that UI Policy Action will be executed when the UI Policy’s conditions are true, and then reverted (undone) when the conditions become false.

Example:
Let’s say you have a UI Policy Action that makes a field ‘Mandatory’ when a certain condition is met.

• If ‘Reverse if false’ is checked: When the condition is true, the field becomes mandatory. When the condition becomes false, the field reverts to its default (optional) state.
• If ‘Reverse if false’ is unchecked: When the condition is true, the field becomes mandatory. However, when the condition becomes false, the field remains mandatory. The original state is not restored automatically.

This is incredibly useful for managing dynamic form states without needing multiple UI Policies or complex Client Scripts for each state change.”

Interview Relevance: This demonstrates an understanding of how to create sophisticated dynamic form behavior efficiently.

Answer: “The ‘On Load’ checkbox on a UI Policy determines whether the UI Policy’s conditions and actions are evaluated and executed immediately when the form is initially loaded.

• If ‘On Load’ is checked: The UI Policy runs as soon as the form appears in the browser. This is useful for setting initial states, default values, or making fields visible/hidden right away based on initial form data.
• If ‘On Load’ is unchecked: The UI Policy does not run when the form is loaded. Instead, its conditions and actions are only triggered when a specific event occurs on the form, such as a field’s value changing (which would be handled by an ‘On Change’ trigger, or indirectly by a user interaction that then evaluates the conditions).

For most UI Policies that need to set an initial state, ‘On Load’ is typically checked. If a UI Policy is designed to react *only* to user input after the form has loaded, then ‘On Load’ might be unchecked. However, UI Policies are generally evaluated on load by default, so the primary purpose of this checkbox is to ensure it *does* run on load.

Interview Relevance: Understanding when and how UI Policies are executed is key to their effective use.

Answer: “The ‘Inherit’ checkbox on a UI Policy signifies whether the UI Policy should also be applied to child tables that extend the table on which the UI Policy is defined.

• If ‘Inherit’ is checked: The UI Policy and its actions will automatically be applied to any tables that extend the current table. For example, if you define a UI Policy on the task table with ‘Inherit’ checked, that UI Policy will also apply to incident, problem, change_request, and any other tables extending task.
• If ‘Inherit’ is unchecked: The UI Policy will only apply to the table it is defined on. It will not be inherited by child tables.

This is a powerful way to enforce consistent UI behavior across related tables without duplicating logic.
”

Interview Relevance: Demonstrates knowledge of how to manage UI behavior across table hierarchies.

Answer: “Yes, you absolutely can write scripts within UI Policies. This is done in two places:

1. UI Policy Script: On the main UI Policy form, there are two checkboxes: ‘Run scripts’. If you check this box, it enables two related lists: ‘UI Policy Script’ for OnLoad scripts and ‘UI Policy Script’ for OnChange scripts. These scripts execute server-side or client-side depending on the UI policy’s context.
2. UI Policy Actions: Within each UI Policy Action, there’s a ‘Run script’ checkbox. If you check this, you can enter a client-side JavaScript snippet that will execute when that specific UI Policy Action is applied (e.g., when a field is made mandatory, you can run a script to perform additional actions).

The ‘Run scripts’ checkboxes on the main UI Policy form usually enable client-side scripting for the UI Policy itself, affecting how conditions are evaluated or how actions are performed dynamically. When you need to execute scripts based on the conditions of the UI Policy, you would typically enable ‘Run scripts’ and use the UI Policy Scripts related list. For actions that need custom scripting, you’d check ‘Run scripts’ on the action.
”

Interview Relevance: Shows you know how to extend UI Policy functionality with scripting for more complex requirements.

Troubleshooting Tip: If your UI Policy scripts aren’t running, ensure the ‘Run scripts’ checkbox is checked on the UI Policy itself or on the specific UI Policy Action. Also, verify the UI Policy is set to run ‘On Load’ if you expect it to execute immediately upon form load.

Answer: “Yes, ServiceNow provides a convenient way to convert a UI Policy into a Data Policy. This is very useful when you have UI Policies that enforce mandatory or read-only attributes and you want to ensure this enforcement also happens at the server-side (data layer) and for other access methods, not just the UI.

How to Convert:
You can typically find a related link or button on the UI Policy form itself that says something like ‘Convert to Data Policy’ or ‘Convert this UI Policy to Data Policies’. Clicking this will create new Data Policies based on the conditions and actions of your UI Policy.”

Interview Relevance: Demonstrates knowledge of platform features that promote code conversion and best practices for data integrity.

Answer: “While the conversion tool is powerful, it can’t convert every aspect of a UI Policy. The conversion process is primarily designed for enforcing mandatory and read-only field states. UI Policies that involve functionality beyond this may not be fully convertible:

• Controlling Data Visibility (Show/Hide): Data Policies primarily enforce data constraints (mandatory, read-only), not field visibility. You cannot directly convert a UI Policy action that hides or shows a field into a Data Policy.
• Controlling Views: UI Policies can sometimes influence which fields are displayed based on view configurations, but Data Policies do not manage view-specific rendering.
• Controlling Related Lists: UI Policies can show or hide related lists on a form, a capability not directly supported by Data Policies.
• Complex Scripting: If a UI Policy relies heavily on complex client-side JavaScript within its scripts or actions (beyond simple mandatory/read-only enforcement), the direct conversion might not capture all the scripting logic accurately or appropriately. Data Policies have server-side script capabilities, but the conversion process is focused on common attributes.
• Dynamic Behavior Based Solely on Client-Side Interaction: While Data Policies have client-side rendering capabilities, the core strength of UI Policies is their direct client-side interaction and immediate feedback. Complex interactive behaviors might be better suited for UI Policies.

In these cases, you would need to re-implement the functionality using Data Policies for server-side enforcement and potentially separate Client Scripts or UI Policies for client-side specific behaviors.
”

Interview Relevance: This shows you understand the limitations of automated tools and the distinct roles of UI Policies and Data Policies.

Answer: “Data Policies are a powerful feature in ServiceNow that enforce data policies on forms and from server-side access (like integrations or business rules). They ensure data integrity and consistency across all ways data is accessed.

Data Policies can:

• Make fields mandatory or optional.
• Make fields read-only or editable.

The key distinction is that Data Policies work on the server-side (data layer) and also affect the client-side rendering. This means that whether you create or update a record via the UI, a REST API call, or a scheduled import, the Data Policy’s rules will be enforced. This is different from UI Policies, which primarily operate on the client-side (browser).

Data Policies are configured using conditions, similar to UI Policies, and then define the actions (mandatory, read-only) to be applied to specific fields.”

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

Troubleshooting Tip: If a field is mandatory in the UI but isn’t when accessed via an API, it’s likely a Data Policy that needs to be checked or created, rather than just a UI Policy.