Answer: “I’m currently working with the Washington DC release. It’s always exciting to leverage the latest features and enhancements ServiceNow brings with each iteration, and Washington DC has some really impactful updates.”

Interview Relevance: Demonstrates your awareness of current ServiceNow releases and your engagement with the platform’s evolution. Mentioning specific features you like can be a bonus.

Answer: “My ServiceNow journey began with the Rome release. Since then, I’ve had the opportunity to work with subsequent versions like San Diego, Tokyo, Utah, Vancouver, and now Washington DC. This progression has given me a solid understanding of how features have been introduced and refined over time.”

Interview Relevance: Shows your experience depth and your ability to adapt to platform changes across different versions.

Answer: “Absolutely! In ServiceNow, permissions are primarily managed through Roles. We can assign roles to individual users, and crucially, to groups. The best practice is to assign roles to groups rather than directly to users. This is a game-changer for manageability. When an employee joins, you add them to the relevant groups, and they automatically inherit the roles assigned to those groups. Conversely, when an employee leaves, you simply remove them from their groups, and their access is revoked across the board. This significantly reduces administrative overhead and minimizes the risk of orphaned permissions.”

Troubleshooting Tip: If you find users with unintended access, always check their group memberships first, as this is the most common and manageable way permissions are granted.

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

Answer: The table that links users to groups is sys_user_grmember.

Answer: You can create a user account programmatically using GlideRecord. Here’s a common example:

var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username = 'jdoe';
userGr.first_name = 'John'; // Note: field names are typically snake_case
userGr.last_name = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.active = true; // It's good practice to set active status
userGr.insert();
console.log('User ' + userGr.username + ' created with sys_id: ' + userGr.sys_id);
            

Troubleshooting Tip: Ensure you are using the correct field names (they are case-sensitive and typically snake_case, e.g., first_name instead of firstname). Always check if the record was inserted successfully.

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

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Service Desk - Tier 2';
newGr.description = 'Team responsible for second-level support for IT incidents.';
// Assigning a manager requires their sys_id. You'd typically look this up or hardcode for examples.
// newGr.manager = 'sys_id_of_manager'; 
newGr.email = 'servicedesk.tier2@example.com';
newGr.active = true; // Ensure group is active
newGr.insert();
console.log('Group ' + newGr.name + ' created with sys_id: ' + newGr.sys_id);
            

Troubleshooting Tip: If the manager field isn’t populating, verify the sys_id you’re using is correct and that the user specified as the manager exists and is active.

Answer: Permissions are managed by adding roles. This involves interacting with the tables that link users/groups to roles:

To a User: The linking table is sys_user_has_role.

var userRole = new GlideRecord('sys_user_has_role');
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();
console.log('Role assigned to user.');
            

To a Group: The linking table is sys_group_has_role.

var grpRole = new GlideRecord('sys_group_has_role');
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();
console.log('Role assigned to group.');
            

Interview Relevance: Shows understanding of the underlying data model for permissions and practical scripting skills.

Troubleshooting Tip: Always verify the sys_ids of both the user/group and the role are correct. If a role isn’t taking effect, double-check that the user/group is active and the role itself is active.

Answer: User delegation in ServiceNow allows one user (the delegate) to perform actions on behalf of another user (the delegator). This is incredibly useful for ensuring business continuity when someone is on leave, on vacation, or otherwise unavailable. The delegate can be granted specific permissions, such as approving records, assigning tasks, or responding to notifications that would normally be directed to the delegator. You configure this within the delegator’s user record by scrolling down to the ‘Delegates’ related list and specifying the delegate, the date range, and the types of actions they can perform.

Interview Relevance: This question assesses your understanding of user management features beyond basic creation and your knowledge of features that support operational efficiency.

Real-world Example: A manager going on vacation might delegate their approval tasks for expense reports to their direct report. This ensures that requests are still handled promptly.

Answer: This involves scripting against the sys_user_grmember table.

Adding a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize(); // Important to initialize a new record
grMem.user = 'sys_id_of_user_to_add'; // Replace with actual user sys_id
grMem.group = 'sys_id_of_group_to_add_to'; // Replace with actual group sys_id
grMem.insert();
console.log('User added to group.');
            

Removing a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', 'sys_id_of_user_to_remove'); // Replace with actual user sys_id
grMem.addQuery('group', 'sys_id_of_group_to_remove_from'); // Replace with actual group sys_id
grMem.query();
if (grMem.next()) {
    grMem.deleteRecord(); // Use deleteRecord() for GlideRecord objects
    console.log('User removed from group.');
} else {
    console.log('User not found in the group.');
}
            

Troubleshooting Tip: When removing a member, ensure your queries accurately target the specific user-group relationship. If the script doesn’t find a member to remove, it’s likely due to incorrect sys_ids or the member not actually being in that group.

Answer: ServiceNow has evolved its user interfaces over time. The main ones you’ll encounter are:

• UI15: An older, but still present, interface.
• UI16: The standard interface for a long time, offering a structured layout.
• Next Experience UI: This is the modern, highly customizable, and user-friendly interface, often referred to as the “Polaris” UI. It’s the direction ServiceNow is heading.

Interview Relevance: Shows awareness of the platform’s UI evolution and understanding of the current modern interface.

Answer: A ‘web services user’ in ServiceNow is a special type of user account primarily used for system-to-system integrations. When you create a user and check the ‘Web service access only’ flag, that user cannot log in to the ServiceNow UI (like the classic homepage or the Next Experience UI). Instead, they are granted credentials that third-party applications can use to authenticate and interact with ServiceNow’s APIs (like REST or SOAP). This is a crucial security practice to ensure integration accounts don’t have unnecessary UI access.

Troubleshooting Tip: If an integration is failing due to authentication issues and you’re using a dedicated integration user, confirm that the ‘Web service access only’ flag is indeed checked and that the user has the appropriate roles assigned (e.g., rest_api_explorer, soap_query).

Answer: On the client-side (e.g., in UI Policies, Client Scripts), you can access the current user’s sys_id using the global object g_user:

var currentUserSysId = g_user.userID;
console.log('Current User Sys ID (Client-side): ' + currentUserSysId);
            

Answer: On the server-side (e.g., in Business Rules, Script Includes), you use the global object gs (GlideSystem):

var currentUserSysId = gs.getUserID();
console.log('Current User Sys ID (Server-side): ' + currentUserSysId);
            

Interview Relevance: This is a fundamental scripting question. Knowing the difference between client-side and server-side methods is essential.

Answer: On the server-side, you can use the gs.getUser() object:

// Replace 'Your Group Name' with the actual name or sys_id of the group
if (gs.getUser().isMemberOf('Your Group Name') || gs.getUser().isMemberOf('sys_id_of_your_group')) {
    gs.addInfoMessage('The current user is a member of the specified group.');
} else {
    gs.addInfoMessage('The current user is NOT a member of the specified group.');
}
            

On the client-side, you’d typically use g_user:

if (g_user.isMemberOf('Your Group Name')) {
    alert('You are a member of this group!');
} else {
    alert('You are not a member of this group.');
}
            

Troubleshooting Tip: The isMemberOf() method is forgiving with group names, but it’s generally more robust to use the group’s sys_id if possible, especially in complex scenarios or when group names might change.

Answer: To create, modify, or delete ACLs, you need the security_admin role. This is a highly privileged role designed to protect the security configuration of your instance.

Interview Relevance: Critical for understanding ServiceNow security and data access management.

Answer: Impersonation in ServiceNow is a feature that allows an administrator (or a user with the ‘admin’ role) to temporarily log in and act as another user. This is invaluable for testing. For example, if a user reports an issue with how a form looks or behaves, an admin can impersonate that user to see exactly what they are seeing, understand their role-based access, and troubleshoot effectively without needing their credentials. It’s accessed via the user menu at the top right of the interface.

Interview Relevance: Demonstrates an understanding of essential administrative tools for testing and support.

Answer: User preferences are settings that individual users can configure to personalize their ServiceNow experience. These are stored in the sys_user_preference table and are specific to each user. Examples include their preferred list columns, theme settings, or notification preferences. When a user changes a preference, it only affects their view; it doesn’t impact anyone else on the platform. This is distinct from system-wide settings.

Interview Relevance: Shows awareness of user personalization features and the distinction between user-specific and global settings.

Answer: An incident is defined as an unplanned interruption to an IT service or a reduction in the quality of an IT service. If an employee’s computer suddenly stops working, or a critical application becomes inaccessible, that’s an incident. The primary goal of Incident Management is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations. Users typically report incidents by creating a ticket.

Interview Relevance: Core ITSM concept. Understanding its definition and purpose is fundamental.

Answer: A Problem is a cause of one or more incidents. While an incident focuses on restoring service, a Problem focuses on identifying the root cause of incidents and preventing their recurrence. If the same incident keeps happening to the same employee, or if multiple employees are experiencing the same issue, it’s likely a problem. In ServiceNow, when multiple incidents stem from the same underlying issue, they can be linked to a single Problem record. Closing the Problem record often triggers the closure of associated incidents, aiming for a permanent fix.

Interview Relevance: Distinguishing between Incident and Problem management is key to understanding ITSM processes.

Answer: Yes, absolutely. This is a standard practice. If a support engineer identifies that an incident is recurring or has a potentially deeper root cause, they can create a Problem record directly from the Incident form. This action typically links the incident to the new Problem record, initiating the investigation into the root cause.

Interview Relevance: Shows understanding of workflow and process integration between ITSM modules.

Answer: Yes, this is also a common scenario. If resolving an incident requires a modification to the IT infrastructure or services (e.g., patching a server, updating software), a Change Request can be initiated from the Incident. This ensures that any changes made are properly managed, approved, and documented to minimize the risk of introducing new incidents or service disruptions.

Interview Relevance: Demonstrates knowledge of how ITSM processes are interconnected and managed for risk mitigation.

Answer: Using GlideRecord on the incident table is straightforward:

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = 'sys_id_of_caller'; // Use the sys_id of the user reporting it
gr.category = 'inquiry'; // Example category
gr.subcategory = 'antivirus'; // Example subcategory
// gr.cmdb_ci = 'sys_id_of_ci'; // Optionally link to a Configuration Item
gr.short_description = 'System performance degraded significantly.';
gr.description = 'User is reporting that their laptop is running very slowly and applications are unresponsive.';
// gr.assignment_group = 'sys_id_of_assignment_group'; // Optionally assign to a group
gr.insert();
console.log('Incident created with sys_id: ' + gr.sys_id);
            

Troubleshooting Tip: Ensure the caller_id field points to a valid, active user record. Incorrect category/subcategory values can lead to routing issues.

Answer: Similar to incident creation, but using the problem table:

var gr = new GlideRecord('problem');
gr.initialize();
gr.caller_id = 'sys_id_of_reporter'; // Often the person who identified the problem
gr.category = 'software'; // Example category
gr.subcategory = 'application_issue'; // Example subcategory
// gr.cmdb_ci = 'sys_id_of_ci'; // Optionally link to a CI
gr.short_description = 'Intermittent application crashes impacting multiple users.';
gr.description = 'Users are experiencing application XYZ crashing randomly throughout the day. Root cause investigation needed.';
// gr.assignment_group = 'sys_id_of_assignment_group'; // For the Problem Management team
gr.insert();
console.log('Problem created with sys_id: ' + gr.sys_id);
            

Interview Relevance: Demonstrates practical scripting for core ITSM modules.

Answer: Using the change_request table:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'software'; // Example category
gr.subcategory = 'patch_management'; // Example subcategory
// gr.cmdb_ci = 'sys_id_of_ci'; // CI being changed
gr.short_description = 'Apply security patch to CRM application server.';
gr.description = 'Install the latest security patch for the CRM application to address vulnerability CVE-XXXX-XXXX.';
gr.requested_by = 'sys_id_of_requester'; // Who requested the change
// gr.assignment_group = 'sys_id_of_change_manager_group'; // For the Change Management team
gr.type = 'normal'; // e.g., normal, standard, emergency
gr.insert();
console.log('Change Request created with sys_id: ' + gr.sys_id);
            

Troubleshooting Tip: Ensure you’re using appropriate values for fields like type (normal, standard, emergency) as they drive workflows.

Answer: This is a classic use case for a Business Rule. You’ll configure an ‘after update’ business rule on the incident table.

Business Rule Configuration:

• Table: Incident
• When to run: After update
• Filter Conditions: State changes to Closed
• Script:

// Check if the incident is a parent (has no parent itself) and has been closed.
// 'current.state == 7' assumes 7 is the sys_id for the 'Closed' state. You should verify this for your instance.
// A more robust check might be: current.state.changesTo(glideRecordForClosedStateSysId)
if (current.state.changesTo(7) && current.parent.nil()) { 
    // Find all incidents linked as children to this parent
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id);
    grChild.query();

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

Interview Relevance: Crucial for demonstrating automation and workflow management skills using Business Rules.

Troubleshooting Tip: The current.state == 7 is a simplification. The most reliable way is to check for changes using current.state.changesTo(7). Also, ensure the ‘parent’ field is correctly populated on child incidents.

Answer: This requires a “before update” Business Rule on the incident table. This rule will prevent the incident from being updated (closed) if there are open tasks.

Business Rule Configuration:

• Table: Incident
• When to run: Before update
• Filter Conditions: State changes to Closed
• Script:

// Check if the incident is being closed and if there are any open incident tasks
// Assuming '3' is the sys_id for the 'Closed' state for incident tasks. Verify this.
var openTasksExist = false;
var grTask = new GlideRecord('incident_task');
grTask.addQuery('incident', current.sys_id);
grTask.addQuery('state', '!=', 3); // Check for tasks that are NOT closed
grTask.setLimit(1); // We only need to know if at least one exists
grTask.query();

if (grTask.hasNext()) {
    openTasksExist = true;
}

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

You would implement similar logic for problem (checking problem_task) and change_request (checking change_task) tables.

Interview Relevance: Demonstrates control over workflows and data integrity using “before” business rules.

Troubleshooting Tip: Ensure the state value for ‘Closed’ in incident_task (and problem_task, change_task) is correctly identified and used in the query.

Answer: This is also handled by a “before update” Business Rule on the problem table, similar to the parent/child incident scenario but reversed.

Business Rule Configuration:

• Table: Problem
• When to run: Before update
• Filter Conditions: State changes to Closed
• Script:

// Assuming '7' is the sys_id for the 'Closed' state. Verify this.
if (current.state.changesTo(7)) { 
    // Find all incidents associated with this problem
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Link to the problem
    grIncident.addQuery('state', '!=', 7); // Only target incidents that are not already closed
    grIncident.query();

    while (grIncident.next()) {
        grIncident.state = 7; // Set the state to Closed
        grIncident.update(); // Update the incident
        gs.info('Incident ' + grIncident.number + ' closed due to parent problem closure.');
    }
}
            

Interview Relevance: Shows understanding of how to automate related record closures for process efficiency.

Troubleshooting Tip: Confirm the `problem_id` field correctly links incidents to problems. Also, ensure you’re using the correct sys_id for the ‘Closed’ state.

Answer: These are three core pillars of IT Service Management (ITSM) that are highly interconnected:

• Incident Management: Focuses on restoring service as quickly as possible when it’s disrupted. It’s reactive. “My application is down!”
• Problem Management: Focuses on finding the root cause of recurring incidents and preventing them from happening again. It’s proactive and reactive (investigates past incidents). “Why is the application crashing?”
• Change Management: Focuses on controlling the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services. It’s proactive and planned. “We need to update the server to prevent crashes.”

The flow often looks like this: An Incident occurs -> If recurring or complex, it leads to a Problem investigation -> The root cause identified might require a modification to the IT environment, which then triggers a Change Request.

Interview Relevance: Essential for understanding the overarching ITIL framework that ServiceNow implements.

Answer: Out-of-the-box tables are those created by ServiceNow and do not start with x_ (custom scoped app) or u_ (legacy custom table prefix). Some common examples include:

• incident
• problem
• change_request
• sc_req_item (Service Catalog Requested Item)
• cmdb_ci (Configuration Item)
• sys_user
• sys_group
• task (a base table)

Interview Relevance: Shows familiarity with ServiceNow’s foundational data structures.

Answer: Base tables are tables that other tables extend but do not themselves extend any other table (except implicitly from sys_db_object, which is internal). They are foundational. Key examples include:

• task: The parent table for many IT workflow records like incidents, problems, changes, and tasks.
• cmdb_ci: The parent table for all Configuration Items in the CMDB.
• sys_user: The primary table for users.

Understanding base tables is crucial because fields and behaviors defined on a base table are inherited by tables that extend it.

Interview Relevance: Deepens understanding of the ServiceNow data model and inheritance.

Answer: As mentioned, the task table is a base table. Many ITSM records extend it. Examples include:

• incident
• problem
• change_request
• sc_task (Service Catalog Task)
• ecc_agent_work_item (a type of task for ECC agents)

These tables inherit fields like ‘assigned_to’, ‘assignment_group’, ‘state’, ‘due_date’, etc., from the task table.

Answer: When you create a new table and opt for the default settings (i.e., checking the box to create necessary ACLs), ServiceNow automatically generates four basic Access Control Lists (ACLs) to secure your new table:

• create ACL: Allows users to create new records.
• delete ACL: Allows users to delete records.
• write ACL: Allows users to modify existing records.
• read ACL: Allows users to view records.

These are typically assigned to roles like admin and catalog. If you uncheck the option, you’ll need to manually create these ACLs.

Interview Relevance: Shows understanding of table creation fundamentals and security setup.

Troubleshooting Tip: If users cannot create records on a newly created table, check if these four default ACLs were generated and assigned appropriate roles. If not, you’ll need to create them manually.

Answer: For auto-generated, unique sequential numbers (like INC0001001), you don’t create a standard ‘Number’ field. Instead, you configure auto-numbering when defining the table or on existing tables. For a table like incident, you go to the table definition, navigate to the ‘Control’ tab, and specify:

• Prefix: e.g., “INC”
• Number of digits: e.g., 7
• Auto-number: Check this box.

When a new record is inserted, ServiceNow will automatically generate a sequential number based on these settings.

Interview Relevance: Demonstrates knowledge of essential record identification mechanisms.

Troubleshooting Tip: If auto-numbering isn’t working, verify that the ‘Auto-number’ checkbox is checked on the table’s control attributes and that there are no custom scripts interfering with number generation.

Answer: When you extend a table (e.g., create a new table that inherits from task), several things occur:

• Inheritance: Your new child table automatically inherits all fields, attributes, and configurations from the parent table. You don’t need to recreate them.
• New Fields: You can then add fields specific to your child table.
• ‘Class’ Field: A field named class is created in the parent table. This field stores the sys_id of the actual table the record belongs to (e.g., for an incident record, the class field in the task table would point to the incident table’s sys_id). This is how ServiceNow knows which specific table a record originated from, especially when querying the parent table.
• Single Class Field: Even if a table extends multiple tables through inheritance chains, it will only have one `class` field in its ultimate parent to identify its specific type.

Interview Relevance: Crucial for understanding object-oriented principles within ServiceNow and table design.

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

1. Reference: Links to another record in a different table.
2. String: For text input (single line).
3. String (Full UTF-8): For longer text input, supporting international characters.
4. List: Allows selection of multiple records from another table.
5. Choice: A dropdown list of predefined options.
6. Email: Formatted for email addresses.
7. Date/Time: For selecting both date and time.
8. Date: For selecting only a date.
9. Boolean: A checkbox (true/false).
10. Integer: For whole numbers.
11. Journal: For adding comments or work notes (stores history).
12. Attachment: Allows users to upload files.
13. URL: For web addresses.
14. HTML: For rich text content.
15. Currency: For monetary values.

Interview Relevance: Shows broad knowledge of data types and how they are used to model information.

Answer:

• Normal Tables: These store data permanently. When you create a standard table like incident, its data persists until explicitly deleted.
• Temporary Tables: These are designed for short-term data storage, often used during import processes or for staging data. They typically extend the import_set_row table (or a similar staging table) and have a limited data retention period (e.g., 7 days) after which the data is automatically purged. They are not intended for long-term storage.

Interview Relevance: Understanding data lifecycle and storage mechanisms.

Troubleshooting Tip: If data disappears from a table after a few days, it’s likely a temporary table. Ensure you’re not using temporary tables for data that needs to be permanent.

Answer: Yes, you can. While temporary tables have a default retention period, you can configure **Archive Rules** to manage the lifecycle of data in tables, including temporary ones. You can define when data should be archived or deleted based on specific criteria, effectively extending or modifying the default retention. However, it’s important to remember why they are “temporary” – they are not optimized for long-term querying and performance.

Interview Relevance: Shows knowledge of data lifecycle management and ServiceNow’s archiving capabilities.

Answer:

• Normal Tables: Store data directly within your ServiceNow instance’s database. When you query them, you get the data that resides locally.
• Remote Tables: These are tables that do not store data within your ServiceNow instance. Instead, they act as a pointer to data residing in an external system (e.g., another database, a cloud application) accessible via an integration. When you query a remote table, ServiceNow fetches the data live from the external source. This is often achieved using REST Message, IntegrationHub, or other integration mechanisms.

Interview Relevance: Demonstrates understanding of data integration and how ServiceNow can interact with external data sources.

Troubleshooting Tip: Performance issues with remote tables are often due to the latency of the external system or network. Ensure the integration is stable and the remote data source is responsive.

Answer: These refer to 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 sys_user record (Table A) can have many incident records (Table B) associated with it (via the caller_id field). One user can report many incidents, but each incident is reported by only one user.
• One-to-One Relationship: This is less common but occurs when one record in Table A is related to exactly one record in Table B, and vice versa.
  • Example: A user’s primary photo stored in a separate table might have a one-to-one relationship with the sys_user record.
• Many-to-Many Relationship: One record in Table A can relate to many records in Table B, AND one record in Table B can relate to many records in Table A.
  • Example: An incident record can be assigned to multiple sys_user_group records (e.g., for collaboration), and a sys_user_group can be assigned to many incident records. This is typically implemented using a bridging table, like sys_group_has_role for roles or a custom table for incident-group associations.

Interview Relevance: Fundamental database design concept applied to ServiceNow.

Answer: ServiceNow provides multiple avenues for record creation:

1. Form: The standard user interface for manually entering data into a record.
2. List View: You can often add new records directly from a list view (e.g., clicking ‘New’ on an incident list).
3. Record Producers: A specialized form designed to create a specific type of record, often surfaced through Service Catalog or portals.
4. Email: Inbound email actions can create records (e.g., creating an incident from an email).
5. GlideRecord Scripting: Programmatically creating records via server-side scripts (Business Rules, Script Includes, etc.).
6. Import Sets: Bulk creation of records from external data sources like CSV, Excel, or XML files.
7. APIs: REST, SOAP, or other web services can be used to create records from external systems.
8. Scheduled Imports: Similar to Import Sets but automated on a schedule.

Interview Relevance: Shows comprehensive understanding of data input methods.

Answer: There are several ways to enforce mandatory or read-only states for fields:

• Dictionary Properties: Directly on the field’s dictionary entry, you can check ‘Mandatory’ or ‘Read only’. This is a static setting and applies everywhere.
• Dictionary Overrides: For fields inherited from parent tables, you can create a dictionary override on the child table to set it as mandatory or read-only specifically for that child table.
• UI Policies: These are client-side scripts that dynamically control field visibility, mandatory status, read-only status, and other UI behaviors based on conditions evaluated on the form.
• Data Policies: Similar to UI Policies but can run on both the client-side and server-side, ensuring data integrity regardless of how the record is accessed.
• Client Scripts (using g_form.setMandatory() or g_form.setReadOnly()): For more complex logic that needs to be executed when specific events occur on the form.
• Business Rules (Server-side): While not directly setting mandatory/read-only in the UI, server-side logic can enforce data validation and prevent updates if conditions aren’t met, achieving a similar outcome.

Interview Relevance: Crucial for understanding UI and data validation techniques.

Troubleshooting Tip: If a field is unexpectedly mandatory or read-only, check UI Policies, Data Policies, and Dictionary Overrides in that order, as they can override static dictionary settings.

Answer: No, you should not make more than one field as ‘display’ in a table. The ‘Display’ checkbox on a dictionary entry is used to mark a field whose value should be used in relating fields (e.g., in choice lists or reference fields) to identify a record. ServiceNow is designed to use only one display value per table. Having multiple display fields can lead to confusion and unpredictable behavior in related lookups.

Interview Relevance: Shows understanding of database design principles and best practices.

Troubleshooting Tip: If you encounter strange behavior in reference lookups where multiple fields seem to be returned, it might indicate an incorrect setup of display values.

Answer: All table definitions in ServiceNow are stored in the sys_db_object table. This table contains metadata about every table defined in the instance, including its name, label, extensions, and other structural properties.

Interview Relevance: Demonstrates knowledge of the ServiceNow metadata repository.

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

• Dictionary Entry: In the field’s dictionary record, there’s a ‘Default value’ field. You can enter a static value (e.g., ‘Open’) or a script (e.g., javascript:gs.getUser().getDepartmentID()) to dynamically set the default. This value is populated when a new record is created and the field is not otherwise set.
• UI Policies: You can use a UI Policy action to set a default value when certain conditions are met on the form.
• Client Scripts: Using g_form.setDefaultValue('field_name', 'value'); in an ‘OnLoad’ client script.

Interview Relevance: Shows understanding of initializing records with common values.

Troubleshooting Tip: If a default value isn’t populating, check if a UI Policy or Client Script is overriding it, or if the value is conditional and the condition isn’t met.

Answer: The current object is a global GlideRecord object available in server-side scripts (like Business Rules, Script Includes, and UI Actions) that refers to the record currently being processed. It allows you to read values from the current record and, importantly, to set values on it before it’s saved to the database.

Interview Relevance: Essential for server-side scripting.

Answer: Using the current object in server-side scripts:

• current.setValue('field_name', value);: This sets the internal value of a field. For reference fields, you must provide the sys_id of the referenced record.
• current.setDisplayValue('field_name', value);: This sets the display value of a field. For reference fields, you provide the human-readable display value (e.g., the user’s name), and ServiceNow will attempt to find the correct sys_id. This is often more convenient for users but can be slower.

Example:

// Set a simple string field
current.setValue('short_description', 'Updated description');

// Set a reference field (assuming you have the sys_id of the user)
current.setValue('caller_id', 'sys_id_of_user');

// Set a reference field using display value
current.setDisplayValue('assigned_to', 'John Doe'); 
            

Interview Relevance: Core scripting skill for manipulating records.

Troubleshooting Tip: When using setValue for reference fields, ensure you’re passing the correct sys_id. If the field doesn’t update, double-check the field name and the value’s format.

Answer: Reference Qualifiers are used to filter the list of records that can be selected in a reference (or list) field. They ensure users can only pick relevant records, improving data accuracy and user experience. There are three main types:

1. Simple Reference Qualifier:

Description: The most basic type. You define a static query directly in the dictionary entry of the reference field using a simple conditional statement (e.g., active=true, state!=3).

Example: In a reference field for the User table, you could use active=true^department=IT to show only active users in the IT department.

How to Use: In the reference field’s dictionary entry, under the ‘Reference Specifications’ tab, you’ll find a ‘Reference Qualifier’ field. Enter your query here (e.g., active=true).

2. Dynamic Reference Qualifier:

Description: This type uses a dynamically generated query based on context. You create a ‘Dynamic Filter Option’ (under System Definition) that defines a query. This option can then be selected in the Reference Qualifier field of your reference field.

Example: Displaying only users who are members of a specific group. The dynamic filter option can be configured to look at the assignment group of the current record.

How to Use: Go to System Definition > Dynamic Filter Options. Create a new option with your query. Then, in the reference field’s dictionary entry, select ‘Dynamic’ from the Reference Qualifier dropdown and choose your created option.

3. Advanced Reference Qualifier (JavaScript Reference Qualifier):

Description: This is the most powerful type, allowing you to write custom JavaScript code to define the query. This enables complex filtering logic based on multiple conditions, current form values, and even GlideRecord lookups.

Example: Filter incidents to show only those assigned to the current user’s manager, or display products from a specific vendor.

How to Use: In the reference field’s dictionary entry, select ‘Advanced’ for the Reference Qualifier. Enter your JavaScript code in the text area. For instance:

javascript: 'assignment_group=' + current.assignment_group + '^state!=3';
// Or a more complex script that queries other tables
javascript: "sys_idIN" + getMyValidUsers(); 
            

Difference between types:

• Simple vs. Dynamic: Simple is static. Dynamic uses pre-configured, reusable dynamic filters.
• Dynamic vs. Advanced: Dynamic uses pre-configured filters. Advanced uses custom JavaScript for maximum flexibility.
• Simple vs. Advanced: Simple is basic condition builder. Advanced uses custom code for any logic.

Interview Relevance: Critical for understanding how to control data selection and improve usability.

Troubleshooting Tip: If a reference qualifier isn’t working, check the browser’s JavaScript console for errors. For advanced qualifiers, ensure your JavaScript syntax is correct and that the query logic correctly targets the desired records.

Answer: Dependent values are used to create cascaded dropdowns, where the available options in one field (the dependent field) change based on the selection made in another field (the parent field). This is configured in the dictionary entry of the dependent field.

Example:

1. Parent Field: ‘Category’ on the Incident form (e.g., Hardware, Software, Network).
2. Dependent Field: ‘Subcategory’ on the Incident form.

You would go to the dictionary entry for ‘Subcategory’, set its ‘Dependent Field’ attribute to ‘Category’, and then define the choices for Subcategory, linking them to specific Category selections. For instance, if ‘Category’ is ‘Hardware’, ‘Subcategory’ might show ‘Laptop’, ‘Desktop’, ‘Printer’. If ‘Category’ is ‘Software’, ‘Subcategory’ might show ‘Operating System’, ‘Application’, ‘Database’.

Interview Relevance: Demonstrates understanding of form design and user experience enhancements.

Troubleshooting Tip: If a dependent field isn’t updating, ensure the ‘Dependent Field’ attribute is correctly set in the dependent field’s dictionary and that the choices are properly configured with their corresponding parent values.

Answer: A calculated value is set for a field using a script defined in its dictionary entry. This script runs when a new record is created or when an existing record is updated and the field is not explicitly set by other means. It allows you to dynamically populate a field’s value based on other fields or business logic.

How to Use: In the field’s dictionary entry, there’s a ‘Default value’ field. You can select ‘JavaScript’ and enter a script. For example, to set a ‘Business Impact’ field based on the ‘Urgency’ and ‘Impact’ fields:

javascript: 
    var urgency = current.u_urgency; // Assuming custom urgency field
    var impact = current.impact;
    if (urgency && impact) {
        if (urgency == 1 && impact == 1) return 'Critical';
        if (urgency == 1 || impact == 1) return 'High';
        return 'Medium';
    }
            

Interview Relevance: Shows understanding of dynamic field population and scripting for data processing.

Troubleshooting Tip: Ensure your script is syntactically correct and that it correctly references other fields. If the calculated value is not appearing, verify that the script logic is being hit and that it’s returning a valid value.

Answer: Attributes are special properties you can apply to fields (on the dictionary entry) or tables (on the collection field’s dictionary entry) to modify their behavior or appearance. They are typically entered as comma-separated key-value pairs.

Some common attributes I’ve used include:

• no_email: Prevents this field from being used in email notifications.
• no_attachment: Disables attachments for this specific field (though usually applied at the table level).
• no_add_me: Hides the “Add Me” button on a list.
• tree_picker: Enables a hierarchical tree-like selection interface for reference fields.
• ref_auto_completer=...: Configures the auto-completion behavior for reference fields.
• ref_ac_columns=...: Specifies which columns to display in the auto-complete dropdown for reference fields.
• max_length=...: Sets a maximum character limit for string fields.
• read_only=true: Makes a field read-only. (Note: UI Policies and dictionary entries can also achieve this).

Interview Relevance: Shows practical knowledge of fine-tuning field behavior.

Troubleshooting Tip: When a field behaves unexpectedly (e.g., email notifications are sent when they shouldn’t be, or attachments aren’t allowed), check the attributes defined on its dictionary entry or its table’s collection field.

Answer: A ‘collection’ field in the context of table definitions refers to the dictionary entry that represents the table itself, rather than a specific field on that table. When you create a new table, ServiceNow automatically creates a dictionary entry for it with the ‘Type’ set to ‘Collection’. Any attributes or properties applied to this collection entry (like no_attachment, can_create, etc.) affect the entire table’s behavior, not just a single field.

Interview Relevance: Understanding ServiceNow’s internal data model representation.

Troubleshooting Tip: If you need to disable attachments for an entire table, you’d add the no_attachment attribute to the collection field’s dictionary entry for that table.

Answer: To disable attachments for an entire form (table), you would add the no_attachment attribute to the **collection field** for that table. Locate the table in the “Tables” module (System Definition > Tables), open its dictionary entry (which is the “Collection” entry for the table), and add no_attachment to the Attributes field.

To enable attachments (if they were disabled globally or via another attribute), you would remove the no_attachment attribute.

Interview Relevance: Practical configuration of form features.

Answer: A dictionary override allows you to change the definition of a field that is inherited from a parent table. When you extend a table, you inherit all its fields. A dictionary override lets you customize those inherited fields for the specific child table without altering the parent table’s definition. This is incredibly powerful for tailoring inherited fields.

You can override numerous properties, including:

• Default Value
• Mandatory status
• Read only status
• Max Length
• Display Value setting
• Choice List Specification (e.g., changing choices for a choice field)
• Reference Specification (e.g., changing the reference qualifier)
• Attributes
• Help Text
• Label (though often discouraged unless for specific internationalization needs)

Example: The task table might have a default ‘State’ field. On the incident table, you might override this to make it mandatory and change its default value from ‘Open’ to ‘New’.

Interview Relevance: Essential for understanding how to customize inherited fields and manage table-specific configurations.

Troubleshooting Tip: If a field’s behavior (mandatory, default value, etc.) seems inconsistent across different tables, check for dictionary overrides on the child tables. The override on the child table will take precedence over the parent’s definition.

Answer: Application menus (often referred to as “Modules”) are used to organize and provide access to lists, forms, and other content within ServiceNow. They appear in the left-hand navigation menu. You create an Application Menu and then associate one or more Modules with it. Modules can then link to specific tables, reports, or even custom pages. This structure helps users quickly find and access the information they need, grouping related functionalities logically.

Interview Relevance: Shows understanding of user navigation and content organization.

Troubleshooting Tip: If users can’t find a particular list or form, check if an appropriate Application Menu and Module have been created and linked correctly.

Answer: A process flow visually represents the stages or states a record progresses through within a particular workflow or module. On a form, it typically appears as a series of buttons or steps, highlighting the current stage and indicating the allowed transitions to the next stages. For example, on an Incident form, a process flow might show stages like New > In Progress > On Hold > Resolved > Closed. It helps users understand where they are in a process and what actions are available.

Interview Relevance: Demonstrates understanding of visual process aids and user guidance.

Answer: Data Lookup Rules (more commonly referred to as “Data Lookups” or “Dictionary Lookups” in this context) are a mechanism to automatically populate field values on a form based on the values of other fields on the same form. They are configured in the dictionary entry of the field whose value you want to populate. You define conditions based on other fields, and for each condition, you specify the value to be set.

Example: When a user selects a specific ‘Configuration Item’ (CI) on an Incident, a Data Lookup could automatically populate the ‘Business Service’ field based on the CI’s related business service. Or, based on the caller’s department, it could pre-populate the ‘Assignment Group’.

Interview Relevance: Shows knowledge of automating data entry and ensuring data consistency.

Troubleshooting Tip: If fields aren’t auto-populating as expected, check the Data Lookup rules on the target field to ensure the conditions match the current form data and that the lookup values are correctly defined.

Answer: UI Policies are client-side scripts used to dynamically set field attributes (like mandatory, read-only, visible, hidden) and control form behavior based on conditions evaluated on the form. They offer a declarative way to manage form logic, often replacing the need for complex client scripts for simple show/hide or mandatory/read-only requirements. They can also trigger scripts for more advanced logic.

Interview Relevance: Fundamental for interactive form design and user experience.

Answer: The ‘Global’ checkbox on a UI Policy determines whether the UI Policy applies to all views of a form or only to specific views. If checked, the UI Policy runs on all views. If unchecked, you must then specify which views the UI Policy should apply to in the ‘Views’ related list. This is crucial for managing different user interfaces or form layouts.

Interview Relevance: Understanding how UI Policies are applied across different user contexts.

Troubleshooting Tip: If a UI Policy isn’t working on a particular form view, check if the ‘Global’ checkbox is checked or if the correct view is specified in the related list.

Answer: The ‘Reverse if false’ checkbox in UI Policies is very handy. When checked, it means that if the conditions defined in the UI Policy evaluate to false, the actions specified in the UI Policy will be reversed. For example, if a UI Policy action makes a field mandatory when the condition is true, and ‘Reverse if false’ is checked, that field will become optional again when the condition is false. This simplifies logic for showing/hiding or making fields mandatory/optional.

Interview Relevance: Shows ability to leverage declarative tools for efficient form scripting.

Troubleshooting Tip: If a field that was supposed to revert to its original state (e.g., become visible again) is not doing so, double-check if ‘Reverse if false’ is enabled on the relevant UI Policy.

Answer: The ‘On Load’ checkbox in a UI Policy determines whether the UI Policy’s conditions and actions are evaluated and applied immediately when the form is first loaded. If checked, the UI Policy runs as soon as the form is displayed. If unchecked, the UI Policy actions will only trigger when a condition changes after the form has loaded (e.g., when a user changes a field value).

Interview Relevance: Understanding form loading behavior and UI Policy execution timing.

Troubleshooting Tip: If a UI Policy’s logic isn’t applied when the form initially loads, ensure the ‘On Load’ checkbox is checked. Conversely, if it’s running too early or unnecessarily, you might uncheck it.

Answer: The ‘Inherit’ checkbox in a UI Policy means that the UI Policy will be applied not only to the table where it’s defined but also to any tables that extend it. If you have a UI Policy on the ‘Task’ table with ‘Inherit’ checked, it will automatically apply to ‘Incident’, ‘Problem’, ‘Change Request’, etc., provided those tables haven’t overridden or disabled it. This is a powerful way to enforce consistent UI behavior across related tables.

Interview Relevance: Understanding how to apply policies consistently across an inheritance hierarchy.

Troubleshooting Tip: If a UI Policy is expected to run on a child table but isn’t, verify that ‘Inherit’ is checked on the parent UI Policy and that there isn’t a conflicting UI Policy or an override on the child table.

Answer: Yes, you can! While UI Policies are declarative, they also have the capability to execute client-side scripts for more complex logic. To do this, you enable the ‘Run scripts’ checkbox within the UI Policy and then define scripts in the ‘UI Policy Script’ section (for the overall UI Policy logic) or within individual UI Policy Actions (for action-specific scripts). This allows for dynamic field manipulations that go beyond simple mandatory/read-only/visible changes.

Interview Relevance: Shows understanding of the scripting capabilities within declarative tools.

Troubleshooting Tip: If a UI Policy script isn’t running, ensure that ‘Run scripts’ is checked on the UI Policy itself, and that the UI Policy Action associated with the script is also configured correctly. Also, check the browser’s JavaScript console for errors.

Answer: Yes, you can convert a UI Policy into a Data Policy. ServiceNow provides a convenient “Convert to Data Policy” button directly on the UI Policy form. This is useful when you want to ensure that the logic applied by the UI Policy also runs on the server-side, guaranteeing data integrity regardless of how the record is accessed (e.g., via API, import, or another client-side interaction).

Interview Relevance: Understanding the relationship and migration path between UI and Data Policies.

Troubleshooting Tip: If you convert a UI Policy, review the resulting Data Policy to ensure all intended logic has been correctly translated, especially if the original UI Policy relied heavily on specific client-side DOM manipulations.

Answer: While most UI Policy logic can be converted, there are specific scenarios where a direct conversion isn’t possible or ideal, primarily because Data Policies operate at a data level and don’t directly interact with the UI in the same way:

• Controlling Field Visibility (setVisible()): Data Policies are for data integrity, not UI presentation. Making a field visible or hidden is a UI concern.
• Controlling Form Views: Data Policies do not manipulate the structure of views.
• Controlling Related Lists: Similar to visibility, managing related list display is a UI function.
• Complex Client-Side Scripting: If a UI Policy relies heavily on interacting with the DOM or using client-specific functions not available server-side, a direct conversion might not be feasible or might require significant rewrites.
• UI-Specific Interactions: Any logic that directly manipulates UI elements or events not tied to data validation.

Interview Relevance: Understanding the limitations of data policies and the distinct roles of UI and Data Policies.

Answer: Data Policies are server-side logic that enforces data integrity and field attributes (mandatory, read-only, visible/hidden) on records, regardless of whether the record is accessed via the client-side UI, a mobile app, an API, or an import. They ensure that data entered into ServiceNow is always validated and consistent, providing a robust layer of data governance.

They consist of Data Policy Rules, which define conditions and actions for fields.

Interview Relevance: Essential for understanding ServiceNow’s data governance and validation framework.

Troubleshooting Tip: If data validation issues persist across different access methods, always check Data Policies first, as they are the most comprehensive way to enforce data rules.