Answer: “I’m currently working with the Washington DC release, which is the latest one.”

Interview Relevance: This question gauges your exposure to the most recent features and functionalities. It’s always good to be updated with the latest release.

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

Interview Relevance: Shows your experience progression and understanding of how the platform has evolved. A longer history indicates deeper experience.

Answer: “Yes, absolutely. Permissions, or roles in ServiceNow terminology, can be assigned to individual users or to groups. We can do this manually through the user or group records, or programmatically using GlideRecord scripts. The best practice is to assign roles to groups. This is because when an employee leaves the organization, you simply remove them from their assigned groups, and all their associated roles are automatically revoked. This streamlines user lifecycle management and significantly reduces the risk of orphaned permissions.”

Interview Relevance: Demonstrates understanding of security models and operational efficiency. Group-based permissions are a fundamental security principle.

Answer: The user table in ServiceNow is named sys_user.

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

Answer: You can create a user account using a GlideRecord script like this:

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

Interview Relevance: Assesses scripting ability and understanding of record creation. This is a foundational scripting task.

Answer: Creating a group programmatically using GlideRecord looks like this:

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Testing Group';
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Sys ID of the manager
newGr.email = 'testing@tcs.com';
newGr.description = 'This is a test group for demonstration.';
newGr.insert();
            

Interview Relevance: Similar to user creation, this tests scripting proficiency and knowledge of common tables.

Answer: Permissions are managed through roles. When you assign a role to a user, a record is created in the sys_user_has_role table. To add a role to a user via script:

var userRole = new GlideRecord('sys_user_has_role');
userRole.setValue('user', '62826bf03710200044e0bfc8bcbe5df1'); // Sys ID of the user
userRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Sys ID of the role
userRole.insert();
            

For groups, roles are managed in the sys_group_has_role table. To add a role to a group:

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.setValue('group', '477a05d153013010b846ddeeff7b1225'); // Sys ID of the group
grpRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Sys ID of the role
grpRole.insert();
            

Interview Relevance: This is crucial for understanding ServiceNow’s security model and how to automate role assignments, especially in large organizations.

Answer: User delegation allows one user to act on behalf of another user within the organization. This is incredibly useful when the primary user is unavailable, perhaps on vacation or sick leave, ensuring critical tasks like approvals or notifications continue to be processed. The delegated user inherits specific permissions granted by the original user to perform these actions. For instance, an employee going on leave can delegate their approval tasks to a colleague, preventing workflow bottlenecks.

To set this up, you navigate to the original user’s account, scroll down to the ‘Delegates’ related list, and then specify the ‘Delegate’ (the person acting on behalf), the ‘Start Date’, and ‘End Date’. You can also grant specific permissions for assignments, notifications, and approvals.

Interview Relevance: Tests understanding of user management features and their practical application in business continuity.

Answer: Group memberships are managed via the sys_user_grmember table.

Adding a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.user = '62826bf03710200044e0bfc8bcbe5df1'; // Sys ID of the user
grMem.group = '477a05d153013010b846ddeeff7b1225'; // Sys ID of the group
grMem.insert();
            

Removing a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1'); // Sys ID of the user
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // Sys ID of the group
grMem.query();
if (grMem.next()) {
    grMem.deleteRecord();
}
            

Interview Relevance: Another scripting question that reinforces your ability to manipulate core data structures. Essential for automating user administration.

Answer: ServiceNow has had several user interfaces over time, including UI15, UI16, and the modern Next Experience UI.

Interview Relevance: Shows awareness of the platform’s evolution and user experience trends.

Answer: A web services user is a special type of user account in ServiceNow that is primarily used by third-party applications to authenticate and interact with the ServiceNow instance via web services (like REST or SOAP). The key characteristic is that these users cannot log in directly into the ServiceNow user interface as a human user would. They are designed solely for programmatic access.

Interview Relevance: Important for understanding integration capabilities and security considerations for system-to-system communication.

Answer: On the client-side (e.g., in client scripts or UI policies), you can access the current user’s sys_id using the global variable g_user.userID. For example: alert(g_user.userID);

Troubleshooting: If g_user.userID is undefined, ensure your script is running in a context where the user object is available (e.g., not in a background script). Also, confirm you are using the correct global variable.

Answer: On the server-side (e.g., in business rules, script includes), you use the gs.getUserID() method. For example: var currentUserId = gs.getUserID();

Interview Relevance: Differentiates between client-side and server-side scripting contexts, a fundamental distinction in ServiceNow development.

Answer: On the server-side, you can use the gs.getUser().isMemberOf('group name'); method. It returns true if the user is a member and false otherwise. You can also use the group’s sys_id for more precise checking.

Troubleshooting: Ensure you are using the exact group name or sys_id. Case sensitivity might matter depending on configuration. For efficiency, especially in loops, consider caching the group membership check if done multiple times.

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

Interview Relevance: Essential for understanding security administration and the principle of least privilege.

Answer: Impersonation is a feature in ServiceNow that allows an administrator or a user with the appropriate role (like impersonator) to temporarily “act as” another user. This is invaluable for testing functionality, troubleshooting user-specific issues, or demonstrating how a particular user would experience the platform. You can access this by right-clicking on a user record or using the impersonate user feature.

Interview Relevance: Demonstrates knowledge of essential debugging and testing tools within ServiceNow.

Answer: User preferences are settings that individual users can configure to personalize their ServiceNow experience. These settings are stored in the sys_user_preference table. When a user changes their preferences—like the number of records displayed per page, theme color, or notification settings—these changes are specific to that user and do not affect other users globally. It’s about tailoring the UI to individual needs.

Interview Relevance: Shows understanding of user experience customization and the underlying data structures.

Answer: An incident is an unplanned interruption to an IT service or a reduction in the quality of an IT service. When an end-user experiences something that’s not working as expected and it’s impacting their ability to do their job, they would typically report it as 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, ensuring that the best possible levels of service quality are maintained.

Interview Relevance: Basic understanding of ITIL processes, which are core to ServiceNow’s ITSM capabilities.

Answer: A problem is defined as the underlying cause of one or more incidents. While an incident is about restoring service, a problem is about identifying and resolving the root cause to prevent future incidents. If the same incident is reported repeatedly by the same user, or if multiple users report similar issues, it’s a strong indicator of an underlying problem. In ServiceNow, a major incident might be created with several child incidents linked to it, all stemming from a single problem.

Interview Relevance: Distinguishes between incident and problem management, showcasing understanding of the broader ITSM framework.

Answer: Yes, you can. If a support engineer investigating an incident determines that it’s a recurring issue or suspects a deeper underlying cause, they can create a Problem record directly from the Incident form. This is usually done via a UI Action or a related link, linking the incident to the newly created problem record for further investigation and root cause analysis.

Interview Relevance: Demonstrates understanding of the interconnectedness of ITSM modules and workflow automation.

Answer: Yes, absolutely. When resolving an incident, if the support team identifies that a permanent fix requires a change to the IT infrastructure or application (e.g., deploying a patch, updating configuration), they can initiate a Change Request directly from the Incident. This ensures that necessary changes are tracked, approved, and implemented in a controlled manner, preventing future incidents related to the same issue.

Interview Relevance: Highlights the role of the CMDB and ITSM processes in managing the IT lifecycle. Connects incident resolution to proactive change management.

Answer: Creating an incident record programmatically involves using GlideRecord on the incident table:

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // Sys ID of the caller
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys ID of the CI
gr.short_description = 'Test incident record created via script.';
gr.description = 'This is a detailed description for the test incident.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys ID of the assignment group
gr.insert();
            

Interview Relevance: Further tests scripting skills. This is common for data import, automation, or integrating with other systems.

Answer: Similar to incidents, creating a problem record uses GlideRecord on the problem table:

var gr = new GlideRecord('problem');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // Sys ID of the caller
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8be5dc3'; // Sys ID of the CI
gr.short_description = 'Test problem record created via script.';
gr.description = 'This is a detailed description for the test problem.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys ID of the assignment group
gr.insert();
            

Interview Relevance: Reinforces scripting knowledge across ITSM modules.

Answer: Creating a change request involves the change_request table:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys ID of the CI
gr.short_description = 'Test change request created via script.';
gr.description = 'This is a detailed description for the test change request.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys ID of the assignment group
gr.insert();
            

Interview Relevance: Completes the scripting trio for core ITSM records.

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

Table: Incident

When: After

Update: True

Condition: current.state.changesTo(7) && current.parent == '' (Assuming state ‘7’ is ‘Closed’. Adjust state value as needed.)

Script:

if (current.state == 7 && current.parent == '') {
    // GlideRecord to find child incidents
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id);
    grChild.query();
    while (grChild.next()) {
        grChild.state = 7; // Set the state to Closed
        grChild.update(); // Update the child incident
    }
}
            

Interview Relevance: Demonstrates understanding of business rules, workflow automation, and parent-child relationships. Critical for process enforcement.

Troubleshooting: Ensure the state value for ‘Closed’ is correct for your instance. If the business rule runs into recursion issues (unlikely here but possible in complex scenarios), consider using setWorkflow(false) if it’s not intended to trigger other rules.

Answer: This is best handled with a Before Business Rule on the Incident table (or Problem/Change Request tables):

Table: Incident

When: Before

Update: True

Condition: current.state.changesTo(7) (Assuming state ‘7’ is ‘Closed’.)

Script:

var grTask = new GlideRecord('incident_task'); // Or problem_task, change_task
grTask.addQuery('incident', current.sys_id); // Adjust field name for problem/change
grTask.addQuery('state', '!=', 3); // Assuming state '3' is 'Closed' for tasks. Adjust as needed.
grTask.query();
if (grTask.hasNext()) {
    gs.addErrorMessage('Cannot close the incident because there are open tasks.');
    current.setAbortAction(true);
}
            

Interview Relevance: Shows understanding of validation logic, preventing incorrect state transitions, and using setAbortAction(true). This is a common requirement for data integrity.

Troubleshooting: Verify the correct task table name and the ‘Closed’ state value for your task records. The `current.state.changesTo(7)` condition ensures this check only runs when the user attempts to close the record.

Answer: This logic can be implemented with an After Business Rule on the Problem table:

Table: Problem

When: After

Update: True

Condition: current.state.changesTo(7) (Assuming state ‘7’ is ‘Closed’.)

Script:

if (current.state == 7) {
    // GlideRecord to find incidents associated with the problem
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Ensure problem_id is the correct field
    grIncident.addQuery('state', '!=', 7); // Assuming 7 is the state value for 'Closed'
    grIncident.query();
    while (grIncident.next()) {
        grIncident.state = 7; // Set the state to Closed
        grIncident.update(); // Update the incident
    }
}
            

Interview Relevance: Reinforces business rule logic for inter-record dependencies, a key aspect of ITSM process automation.

Troubleshooting: Confirm that the problem_id field on the incident table correctly links to the problem record. Ensure the state values for both problem and incident are accurate.

Answer: These three ITIL processes work in tandem to manage IT services effectively:

• Incident Management: Focuses on restoring normal service operation as quickly as possible following an interruption. When a user reports an issue, an incident is created.
• Problem Management: Aims to identify the root cause of one or more incidents and then resolve them. If an incident is recurring or widespread, it’s investigated as a problem.
• Change Management: Manages all changes to the IT infrastructure in a controlled way. If a problem requires a change to the IT environment to prevent future incidents, a change request is raised and managed through this process.

Essentially, incidents are interruptions, problems are the underlying causes, and changes are the fixes or improvements made to the environment.

Interview Relevance: Crucial for understanding the core ITSM processes that ServiceNow is built upon. Shows you grasp the bigger picture of IT service delivery.

Answer: Out-of-the-box (OOTB) tables are those provided by ServiceNow and do not start with a custom prefix like x_ (for scoped applications) or u_ (for global custom tables). Some common examples include:

• incident
• problem
• change_request
• sys_user
• sys_user_group
• cmdb_ci (and its extensions like cmdb_ci_server, cmdb_ci_computer)
• task
• sc_req_item
• sys_audit
• sys_attachment

Interview Relevance: Basic knowledge of ServiceNow’s data model and table naming conventions.

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

• cmdb_ci: The base table for all Configuration Items in the CMDB.
• task: The base table for all task-based records like Incidents, Problems, Changes, etc.
• cmdb_rel_ci: Base table for relationships between CIs.

When you create a new table by extending one of these, you inherit all the fields and functionality from the base table.

Interview Relevance: Shows understanding of ServiceNow’s table inheritance model and how a structured database is built.

Answer: Tables that extend the task table are considered task tables. They inherit fields like assigned_to, assignment_group, short_description, due_date, and state management. Common examples include:

• incident
• problem
• change_request
• sc_task (Service Catalog Task)
• std_change_request
• time_card

Interview Relevance: Reinforces the concept of table extension and the common functionalities shared by task-based records.

Answer: By default, when you create a new table in ServiceNow and check the “Create ACLs” box (which is typically checked by default), four ACLs are created automatically:

• Read access for the * role (everyone).
• Create access for the itil role.
• Write access for the itil role.
• Delete access for the admin role.

These provide a basic level of security. You’ll almost always need to customize these or add more granular ACLs based on your security requirements.

Interview Relevance: Tests knowledge of security best practices and how ServiceNow handles initial security setup for custom tables.

Answer: To create an auto-numbering field, similar to the incident number, you configure it within the table’s dictionary entry. When defining a field, you would select the ‘Number‘ field type. Then, under the ‘Control‘ tab of the dictionary entry, you can specify:

• Prefix: (e.g., INC for incident)
• Number of digits: (e.g., 7 for INC0000001)
• Auto number: Ensure this checkbox is ticked.

ServiceNow then automatically generates unique sequential numbers for records inserted into that table.

Interview Relevance: Practical knowledge of field types and their configuration, fundamental for data modeling.

Answer: When you extend a table (e.g., creating a new table that inherits from task), the child table automatically inherits all the fields, attributes, and behaviors of the parent table. This means you don’t have to recreate fields like short_description or assignment_group in the child table; they come from the parent.

Specifically:

• Sys Fields: Standard system fields (like sys_id, sys_created_on) are not duplicated in the child table; they are managed at the parent level.
• Class Field: A field named ‘class‘ is created in the parent table. This field stores the actual table name of the record. For example, if you have an Incident record, the class field in the task table would store ‘incident’.
• Single Class Field: Even if a table extends multiple levels deep (e.g., Table A -> Table B -> Table C), there’s still only one ‘class‘ field in the ultimate base table (like task or cmdb_ci), which stores the most specific table name.

Interview Relevance: Crucial for understanding ServiceNow’s object-oriented data model and efficient database design.

Answer: Certainly. Here are 10 common field types in ServiceNow:

1. String: For text input (e.g., short description, name).
2. Reference: To link to a record in another table (e.g., caller_id on Incident).
3. List: A many-to-many relationship field (e.g., assignment groups on a Knowledge Article).
4. Choice: For dropdowns with predefined options (e.g., state, priority).
5. Email: Specifically for email addresses, with built-in validation.
6. Date/Time: To store both date and time.
7. Date: To store only the date.
8. Boolean: For true/false values (e.g., active, on hold).
9. Integer: For whole numbers.
10. Journal: For entry logs or comments (e.g., work notes, comments).
11. Attachment: To allow users to attach files.

Interview Relevance: Demonstrates familiarity with data types and their appropriate use cases.

Answer:

• Normal Table: Stores data permanently until explicitly deleted. These are your standard application tables (e.g., incident, sys_user).
• Temporary Table: Designed to store data for a limited duration, typically for a specific import process or batch job. They often extend the import_set_row table. Data in temporary tables is automatically purged after a set retention period (often 7 days) to manage storage. They are excellent for staging data during complex integrations.

Interview Relevance: Understanding of data lifecycle management and the purpose of different table types for performance and storage optimization.

Answer: Yes, you can increase the retention period for data in temporary tables, primarily by configuring Archive Rules. While temporary tables have a default retention (e.g., 7 days), you can set up archive rules to either extend this period for specific tables or to move data to an archive if it needs to be retained for longer than the default but not kept active in the production database.

Interview Relevance: Shows knowledge of data retention policies and archival strategies within ServiceNow.

Answer:

• Normal Table: The data resides within your ServiceNow instance’s database. When you query it, you’re accessing data stored locally.
• Remote Table: This is a virtual table where the data actually resides in an external data source (like an external database or application). ServiceNow acts as a proxy, retrieving and displaying the data in real-time when you query the remote table. You’re not storing the data in ServiceNow itself. This is often used for integrations where real-time access to external data is required without full data replication.

Interview Relevance: Important for understanding advanced integration patterns and how ServiceNow can leverage external data sources.

Answer: In ServiceNow, table relationships define how records are connected:

• One-to-One Relationship: For every record in Table A, there is at most one related record in Table B, and vice-versa. This is less common but can be implemented using specific configurations. For example, a user might have a single, dedicated mobile device record.
• One-to-Many Relationship: This is the most common type. For every record in Table A, there can be zero, one, or many related records in Table B. However, each record in Table B is related to only one record in Table A.
• Example: A User record (Table A) can have many Incident records (Table B) associated with it (via the caller_id field). But each Incident record is typically assigned to only one User. Another example is a Problem record related to multiple Incident records.

Many-to-Many Relationship: While not explicitly asked, it’s worth noting. This occurs when a record in Table A can relate to many records in Table B, and a record in Table B can relate to many records in Table A. This is usually implemented using a junction table. For instance, Users and Groups have a many-to-many relationship managed by the sys_user_grmember table.

Interview Relevance: Fundamental database design concepts applied to ServiceNow. Essential for understanding how data is structured and linked.

Answer: There are several ways to create records in ServiceNow tables:

1. Form: The most common way, using the standard form interface for a table.
2. Record Producer: A type of catalog item that creates a record in a table when submitted.
3. Email: Using inbound email actions to create records from incoming emails.
4. GlideRecord Script: Programmatically creating records using server-side JavaScript (as seen in previous scripting questions).
5. Import Sets/Data Sources: Loading data from external files (Excel, CSV) or other systems.
6. REST API/SOAP Web Services: Creating records from external applications or scripts.
7. UI Actions: Custom buttons or links that can trigger record creation.

Interview Relevance: Shows a broad understanding of how data enters and is managed within ServiceNow.

Answer: You can control field behavior in several ways:

• Dictionary Properties: For certain fields (like Reference fields), you can set attributes directly in the dictionary entry to make them mandatory or read-only.
• Dictionary Overrides: To modify the behavior of a field inherited from a parent table. You can make it mandatory or read-only in the child table.
• UI Policies: Client-side logic that makes fields mandatory, read-only, visible/hidden based on conditions on the form. They execute when the form loads and when form fields change.
• Data Policies: Similar to UI Policies but can operate on both client and server sides. They ensure data integrity regardless of how the record is accessed (form, import, API).
• Client Scripts (using g_form.setMandatory(), g_form.setReadOnly(), g_form.setVisible()): Custom JavaScript for more dynamic control on the client side, often used for complex conditional logic.
• Server-side Scripting (using current.setMandatory(), current.setReadOnly()): Less common for direct field control as UI/Data policies are preferred, but possible in specific server-side logic.

Interview Relevance: Demonstrates a comprehensive understanding of ServiceNow’s UI and data control mechanisms.

Answer: No, you should not have two fields marked as ‘Display’ in a single table. The ‘Display’ attribute on a field is used to determine how records from that table are represented in related lists, reference fields, and other lookups. If multiple fields are marked as display, it can lead to ambiguity and confusion for users, making it unclear which field’s value to use as the primary identifier.

Interview Relevance: Understanding of field attributes and their implications for user experience and data clarity.

Answer: Information about all tables in ServiceNow, including their definitions, fields, and attributes, is stored in the sys_db_object table. This table contains metadata about the database schema itself.

Interview Relevance: Knowledge of the platform’s underlying metadata structure.

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

• Dictionary Entry: In the field’s dictionary record, there’s a ‘Default value’ field where you can enter a static value, a reference to another field, or a JavaScript expression.
• UI Policies: You can set a default value as an action within a UI Policy, which runs when the form loads or when conditions are met.
• Client Scripts: Using g_form.setDefaultValue('field_name', 'your_default_value'); in an ‘OnLoad’ client script.
• Business Rules: For server-side default values, an ‘Before Insert’ business rule can set a default value using current.field_name = 'your_default_value';.

The dictionary entry is the most permanent default, while UI Policies and Client Scripts offer dynamic defaults based on context.

Interview Relevance: Practical configuration skills for influencing user input and data consistency.

Answer: The current object is a server-side JavaScript object available in business rules, script includes (when processing a record), and workflow scripts. It represents the record that is currently being processed. You use it to get and set values on that specific record before it’s saved to the database or before an action is performed on it.

Interview Relevance: Core server-side scripting concept. Understanding `current` is fundamental for any server-side manipulation.

Answer:

• Using setValue(): This method sets the internal value of a field. For reference fields, you must provide the sys_id of the related record.

  
  current.setValue('field_name', 'value_or_sys_id');
                      

• Using setDisplayValue(): This method sets the human-readable display value. For reference fields, you can provide the actual display value (e.g., the username), and ServiceNow will find the corresponding sys_id. This is often useful when you have the display value but not the sys_id.

  
  current.setDisplayValue('field_name', 'display_value');
                      

Example:

// Set a string field
current.setValue('short_description', 'Resolved via script');

// Set a reference field using sys_id
current.setValue('assigned_to', '6816f79cc0a8016401c5a33be04be441');

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

Interview Relevance: Practical application of the `current` object, essential for server-side data manipulation.

Troubleshooting: Be mindful of the field type. Using setValue on a reference field with a display value will fail. Always use setDisplayValue when you have the display text and not the sys_id.

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

Types of Reference Qualifiers:

1. Simple Reference Qualifier:

Description: This is the most basic type, allowing you to define a fixed query directly in the reference field’s dictionary entry. It uses the standard query builder syntax.

Example: To show only ‘Active’ users in a reference field pointing to the sys_user table:

Configuration: In the reference field’s dictionary entry, set the ‘Reference qualifier’ to active=true.

2. Dynamic Reference Qualifier:

Description: This type uses a pre-configured ‘Dynamic Filter Option’ which allows the query to be dynamically generated based on various contexts, such as the current user, the current record’s field values, or specific system settings. This provides more flexibility than a simple qualifier.

Example: Displaying only CIs that are ‘In Production’ and have a ‘Critical’ impact. Or, showing users from the same department as the caller of an incident.

Configuration: You first define a Dynamic Filter Option (System Definition > Dynamic Filter Options) with your desired conditions. Then, in the reference field’s dictionary entry, select the ‘Dynamic’ option for the qualifier and choose your configured dynamic filter option.

3. Advanced (JavaScript) Reference Qualifier:

Description: This is the most powerful type, allowing you to write custom JavaScript code to define the filter. This enables complex logic that can depend on multiple fields on the current form, user roles, or other dynamic factors.

Example: Filter a list of CIs to show only those that are managed by the same group the current incident is assigned to, and have an upcoming maintenance window.

Configuration: In the reference field’s dictionary entry, select ‘Advanced’ for the qualifier and enter your JavaScript code. The code should return a query string. For example:

javascript: new MyReferenceQualifierScriptInclude().filterCIs(current.assignment_group);

Or directly:

javascript: 'assignment_group=' + current.assignment_group + '^state=production';

Differences:

• Simple vs. Dynamic: Simple is static; Dynamic adapts based on predefined rules and context. Dynamic is generally more flexible than Simple.
• Dynamic vs. Advanced: Dynamic uses pre-configured filter options, which is simpler to set up for common scenarios. Advanced (JavaScript) offers complete control for highly custom or complex filtering needs.
• Simple vs. Advanced: Simple is for basic, fixed filtering. Advanced is for highly dynamic and complex filtering that requires scripting logic.

Interview Relevance: Crucial for understanding how to guide users to select correct related records, a key aspect of data integrity and usability. Shows advanced configuration skills.

Answer: Dependent values 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 powerful way to guide users through complex choices and ensure data consistency.

Steps to Configure Dependent Values:

1. Identify Parent and Dependent Fields: For example, ‘Category’ could be the parent, and ‘Subcategory’ the dependent.
2. Configure the Parent Field: Ensure it has a defined list of choices (e.g., Hardware, Software, Network).
3. Configure the Dependent Field:
   • Go to the dictionary entry of the dependent field (e.g., Subcategory).
   • In the ‘Attributes’ field, add the attribute: dependent="parent_field_name". So, for Subcategory, it would be dependent="category".
   • For each choice in the dependent field, you define which parent value it belongs to. This is often done through related list configurations on the parent field’s dictionary entry or by managing the choices themselves.

Example:

Parent Field: Category (Choices: Hardware, Software, Network)

Dependent Field: Subcategory (dependent on Category)

• If Category = Hardware, Subcategory choices are: Laptop, Desktop, Printer.
• If Category = Software, Subcategory choices are: Operating System, Application, Database.
• If Category = Network, Subcategory choices are: Router, Switch, Firewall.

When a user selects ‘Hardware’ in Category, the Subcategory dropdown will only show Laptop, Desktop, and Printer. If they select ‘Software’, the choices change accordingly.

Interview Relevance: Essential for building user-friendly forms and ensuring data accuracy through contextual filtering. A common requirement in ITSM and Service Catalog.

Answer: A calculated value is a field whose value is automatically determined based on a formula or script, rather than being manually entered by a user. This is configured in the field’s dictionary entry under the ‘Calculated value‘ or ‘Calculation‘ field. You can use a JavaScript expression or a reference to a Script Include to compute the field’s value.

Example: A ‘Total Price’ field on a catalog item could be calculated by multiplying ‘Quantity’ and ‘Unit Price’. Or, a ‘Days Overdue’ field could be calculated as (current.due_date - current.sys_created_on) / 86400000 (approximating days).

Interview Relevance: Shows understanding of fields that derive their value dynamically, reducing manual effort and ensuring accuracy.

Troubleshooting: Ensure the JavaScript expression is valid and uses the correct field names. For complex calculations, using a Script Include is often more maintainable and reusable.

Answer: Attributes are special properties assigned to fields (in their dictionary entries) or tables that modify their behavior or appearance. They provide a quick way to enable or disable certain functionalities without writing custom scripts.

Some attributes I’ve used include:

• no_email: Prevents email notifications from being sent for changes to this field.
• no_attachment: Disables attachments for this specific field or table.
• tree_picker: Displays a hierarchical selection for reference fields.
• visible_when: Controls visibility based on a condition (often used with Reference or List fields in conjunction with UI Policies/Client Scripts).
• ref_auto_completer=...: Controls auto-completion behavior for reference fields.
• max_unit=seconds: Useful for duration fields to specify the unit.

Interview Relevance: Demonstrates practical knowledge of field configurations and how to leverage built-in ServiceNow features for common requirements.

Answer: A “collection field” isn’t a standard term for a field type in ServiceNow. However, it’s likely referring to the dictionary entry that represents the table itself, rather than a field within the table. When you create a table, ServiceNow automatically creates a dictionary entry for that table. Changes made to this *table’s dictionary entry* (like adding attributes, setting read-only properties for the entire table, or defining its label) are applied to the table as a whole, not to a specific field within it. This entry is essentially a collection of metadata about the table.

Interview Relevance: Understanding of the platform’s metadata structure and how table-level configurations are managed.

Answer: You can control the attachment functionality for a specific table using attributes in the dictionary entry for the table itself (the “collection field” mentioned earlier). To disable attachments for a form or table, you would add the no_attachment attribute to the table’s dictionary entry.

Configuration:

1. Navigate to System Definition > Tables.
2. Open the dictionary entry for the table you want to modify.
3. In the ‘Attributes’ field, add no_attachment.

This will remove the paperclip icon and prevent users from adding attachments to records of that table.

Interview Relevance: Practical application of attributes to control UI behavior and enforce business rules.

Answer: Dictionary overrides allow you to change the default behavior or values of a field that is inherited from a parent table for a specific child table. This is incredibly useful for tailoring fields to the specific needs of different applications or modules built on the same base tables.

You can override properties such as:

• Label: Change the display name of the field.
• Mandatory: Make a field mandatory in the child table even if it’s optional in the parent.
• Read only: Make a field read-only in the child table.
• Default value: Set a different default value.
• Max length: Adjust the maximum character length for a string field.
• Choice list specifications: Modify or replace the choices available for a choice field.
• Attributes: Add or remove attributes for the field in the child table.
• Display: (Though generally discouraged to change the display attribute).

Example: In the parent task table, the ‘Priority’ field might have a default value of 4. In the incident table, you might use a dictionary override to make ‘Priority’ mandatory and set its default value to 3.

Interview Relevance: Essential for understanding how to customize inherited fields and build specialized applications on top of ServiceNow’s base platform.

Answer: Application menus, often referred to as modules, are navigation items that appear in the left-hand navigation menu of ServiceNow. They provide users with access to lists, forms, reports, dashboards, and other functionalities within a specific application. When you click on an application menu (like “Incident” or “Configuration”), it expands to show modules like “Open Incidents,” “All Incidents,” “New Incident,” etc.

Creating application menus and modules is how you make custom applications and their components discoverable and usable for end-users.

Interview Relevance: Fundamental for understanding ServiceNow navigation and user access management.

Answer: A process flow, often visualized as a flowchart or a series of steps, visually represents the stages or states that a record (like an incident, problem, or change request) goes through during its lifecycle. It helps users understand where they are in a particular workflow and what the next steps should be. ServiceNow often displays process flows at the top of forms to indicate the current status and guide users through the resolution or approval stages.

Interview Relevance: Understanding of workflow visualization and user guidance within complex processes.

Answer: Data lookup rules are a powerful feature that allows you to automatically populate field values on a form based on the values of other fields on the same form. They are configured in a separate table (sys_data_lookup_rule) and essentially define a mapping. When a user changes a field that triggers a lookup rule, ServiceNow checks the rule’s conditions and, if met, populates specific fields on the form with predefined values.

Example: On an incident form, if the ‘Configuration Item’ is selected, a data lookup rule could automatically populate the ‘Assignment Group’ based on a pre-defined relationship between that CI and a group.

Interview Relevance: Shows knowledge of automation capabilities that reduce manual data entry and improve consistency.

Answer: UI Policies are client-side scripts that dynamically change the behavior of form fields and related lists based on specific conditions. They are a more user-friendly, low-code alternative to client scripts for many common UI manipulations. UI Policies can make fields mandatory, read-only, visible, or hidden, and can also show/hide related lists, all based on defined conditions. They run when the form loads and when form fields change.

Interview Relevance: Core UI configuration tool. Demonstrates ability to control user interaction with forms.

Answer: The ‘Global’ checkbox in UI Policies determines the scope of the UI Policy. When checked, the UI Policy applies to all views of the form. When unchecked, you must specify which view(s) the UI Policy should apply to. This is useful when you need different form behaviors for different user interfaces or contexts.

Interview Relevance: Understanding of UI Policy scope and how to manage different view configurations.

Answer: The ‘Reverse if false’ checkbox is a powerful option in UI Policies. When checked, if the UI Policy’s conditions evaluate to false, the actions defined in the UI Policy are reversed. For example, if a UI Policy makes a field mandatory when a certain condition is true, checking ‘Reverse if false’ will make that field optional again when the condition becomes false. This simplifies logic and avoids needing to create separate UI Policies for opposite conditions.

Interview Relevance: Demonstrates efficiency in configuring UI Policies and leveraging their advanced options.

Answer: The ‘On Load’ checkbox determines whether the UI Policy’s conditions and actions are evaluated and applied immediately when the form is initially loaded. If ‘On Load’ is checked, the UI Policy executes as soon as the form appears. If it’s unchecked, the UI Policy actions will only trigger in response to user interactions (e.g., changing a field value) after the form has loaded.

Interview Relevance: Understanding how UI Policies are executed and when they are triggered.

Answer: When the ‘Inherit’ checkbox is checked on a UI Policy, it means that the same UI Policy will be applied to any child tables that extend the table on which the UI Policy is defined. This is a significant time-saver for maintaining consistent UI behavior across an inheritance hierarchy, avoiding the need to recreate policies for each child table.

Interview Relevance: Shows understanding of how UI Policies interact with table inheritance, promoting efficient configuration.

Answer: Yes, you can write scripts within a UI Policy. To do this, you need to enable the ‘Run scripts’ checkbox within the UI Policy or a specific UI Policy Action. Once enabled, you’ll see fields for ‘Onload script’, ‘Condition script’, and ‘On blur script’ (or similar) where you can enter JavaScript code. This allows for more complex logic than simple condition builders can handle, such as fetching data or performing advanced validations.

Interview Relevance: Demonstrates ability to extend UI Policy functionality with custom scripting for advanced requirements.

Answer: Yes, in many cases, you can convert a UI Policy into a Data Policy. There’s typically a UI action or a button within the UI Policy form that allows you to do this. The system attempts to translate the UI Policy’s conditions and actions into a Data Policy format.

Interview Relevance: Shows understanding of the relationship and potential conversion between UI and Data Policies.

Answer: While many UI Policy actions can be converted, some functionalities are specific to the client-side UI and cannot be directly translated into a Data Policy (which operates on both client and server). These include:

• Controlling Data Visibility: UI Policies can hide/show fields or related lists directly on the form. Data Policies focus on data integrity and don’t typically control visual UI elements like related lists.
• Controlling Views: UI Policies can be view-specific, whereas Data Policies are generally not tied to specific views.
• Controlling Related Lists: Showing or hiding related list sections is a UI-specific function.
• Scripting that Manipulates the UI DOM: Scripts in UI Policies might directly interact with DOM elements for advanced styling or behavior, which is outside the scope of Data Policies.
• Certain UI-Specific Client Script Logic: While many scripting scenarios can be translated, very intricate client-side interactions might be difficult or impossible to replicate in a Data Policy.

Interview Relevance: Critical for understanding the limitations of Data Policies and when UI Policies are the only or best solution.

Answer: Data Policies are powerful declarative rules that enforce data integrity and consistency across all data sources. Unlike UI Policies, which primarily operate on the client-side form, Data Policies can run on both the client and server. They are used to make fields mandatory, read-only, or visible/hidden based on specific conditions, ensuring these rules are applied whether a record is accessed via a form, an import, a REST API call, or other methods. This makes them ideal for enforcing critical business rules at the data level.

Interview Relevance: Essential for understanding data governance and ensuring data quality, regardless of the access method.