Answer: Washington DC – the latest one.

Interview Relevance: This question is a classic icebreaker to gauge your immediate experience and familiarity with the platform’s evolution. It also helps interviewers understand the context for your answers.

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

Practical Explanation: Demonstrating experience across multiple versions shows adaptability and a deep understanding of how the platform has grown and improved over time. Each release often brings new features, architectural changes, and deprecated functionalities.

Troubleshooting Tip: If you’ve only worked on one or two versions, focus on what you’ve learned within those. Highlight how you stay updated on new releases through release notes, training, and community forums.

Answer: Yes, we can add roles (which represent permissions) to users and groups. This can be done manually or via scripting using GlideRecord. The best practice is to assign roles to groups. When an employee leaves the organization or their role changes, you simply remove them from the relevant group, and their permissions (roles) are automatically revoked. This dramatically simplifies user access management and reduces the risk of orphaned permissions.

Best Practice Explained: Imagine an employee moving to a new department. Instead of manually removing dozens of roles from their user record, you just move them to the new department’s group, which already has the correct roles assigned. This is much more efficient and less error-prone.

Interview Relevance: This is a fundamental question about security and access control in ServiceNow. A good answer showcases your understanding of granular permissions and efficient administration.

Answer: sys_user

Answer: sys_user_grmember

Practical Explanation: This table acts as a junction table, linking users to groups. Each record in sys_user_grmember signifies that a specific user is a member of a specific group.

Answer: You can create a user account using a server-side script with GlideRecord 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();
            

Practical Explanation: This script instantiates a new record in the sys_user table, populates essential fields, and then inserts it into the database. This is commonly used for automated user provisioning.

Troubleshooting Tip: Always check if a user with that username already exists before inserting to prevent duplicates. You can use userGr.get('username', 'jdoe') to check for an existing record.

Answer: Similar to user creation, you use GlideRecord to create a group:

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'New Department Group';
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // sys_id of the manager
newGr.email = 'newgroup@example.com';
newGr.description = 'This group is for the new department.';
newGr.insert();
            

Practical Explanation: This script creates a new entry in the sys_user_group table. Note the use of a sys_id for the manager field; this assumes you have the manager’s record already. You’d typically look this up or use a system property.

Answer: Permissions (roles) are managed through junction tables:

• For Users: Roles are added to the sys_user_has_role table.
• For Groups: Roles are added to the sys_group_has_role table.

Here are the scripts:

Adding a role to a user:

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
userRole.user = '62826bf03710200044e0bfc8bcbe5df1'; // sys_id of the user
userRole.role = '2831a114c611228501d4ea6c309d626d'; // sys_id of the role
userRole.insert();
            

Adding a role to a group:

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

Practical Explanation: These scripts create new records in the respective tables, establishing the link between a user/group and a role. Remember to always use sys_ids for referencing other records.

Troubleshooting Tip: Before adding a role, check if the user/group already has it to avoid creating duplicate entries. You can query these tables first.

Answer: User delegation allows one user to act on behalf of another user within the organization. This is incredibly useful when a user is unavailable (e.g., on vacation, sick leave) and needs their critical tasks, approvals, or notifications to be handled. The delegated user gains the necessary permissions to perform these actions as if they were the original user.

Example: An employee is going on a two-week vacation. They can delegate their pending approvals for IT equipment requests to their colleague. During their absence, the colleague receives and acts on these approvals, ensuring workflows aren’t blocked.

How to Configure: This is typically set up on the original user’s record. Navigate to the user’s form, scroll down to the ‘Delegates’ related list, and add delegate details, including the delegate’s name, start/end dates, and specific permissions (e.g., for assignments, notifications, approvals).

Interview Relevance: This question tests your understanding of operational continuity and user management features. It shows you understand how ServiceNow supports business processes during employee absence.

Answer: This involves interacting with the sys_user_grmember table.

Adding a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize(); // Use initialize() when creating a new record
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();
}
            

Practical Explanation: To add, we create a new record in the junction table. To remove, we query for the specific user-group membership record and then delete it.

Troubleshooting Tip: Always verify if the user is already a member before adding, and ensure the record exists before attempting to delete it to avoid errors.

Answer: ServiceNow has had several major UI paradigms. Historically, you’d see UI15 and UI16. The modern, primary interface is the Next Experience UI (often referred to as the “Nova” UI in earlier stages). While older UIs might still be encountered or enabled for specific reasons, the focus is heavily on the Next Experience UI.

Practical Explanation: The Next Experience UI offers a more modern, responsive, and streamlined user experience, with features like an improved header, navigation, and home page. Understanding these differences is key to appreciating the platform’s user-centric evolution.

Answer: A web services user account in ServiceNow is specifically created for programmatic access. When a third-party application needs to interact with ServiceNow (e.g., to create an incident, query data), it uses a designated user account for authentication. Crucially, these users cannot log in to the ServiceNow graphical user interface (GUI) as a human user would. They are solely for integration purposes, enhancing security by isolating integration credentials.

Best Practice: Always use dedicated ‘integration’ or ‘service’ accounts for web services, rather than impersonating regular user accounts. This provides better auditing and control.

Answer: You can access the current user’s sys_id using the g_user object:

var currentUserSysId = g_user.userID;
console.log(currentUserSysId); // Example: 6816f79cc0a8016401c5a33be04be441
            

Practical Explanation: This JavaScript snippet is available in client scripts (UI policies, client-side Business Rules, Client Scripts) and provides the sys_id of the user currently interacting with the form.

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

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

Practical Explanation: This is a fundamental way to identify the user performing an action in server-side scripts, essential for auditing, logging, and conditional logic.

Answer: You can use the gs.getUser().isMemberOf() method on the server-side:

var isMember = gs.getUser().isMemberOf('Group Name'); // Replace 'Group Name' with the actual group name or sys_id
if (isMember) {
    gs.info('User is a member of the group.');
} else {
    gs.info('User is NOT a member of the group.');
}
            

Practical Explanation: This is incredibly useful for controlling access or triggering specific logic based on user group membership. You can pass either the group’s name or its sys_id.

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

Answer: The security_admin role is required to create, modify, or delete ACLs. This is a highly privileged role.

Best Practice: Limit the use of the security_admin role and ensure all changes to ACLs are thoroughly reviewed and tested. Use dedicated administrators with this role and audit their actions.

Answer: Impersonation in ServiceNow allows an administrator or a user with specific permissions to temporarily act as another user. This is an invaluable tool for testing, troubleshooting, and verifying user experiences without needing to log in with that user’s credentials directly. It simulates how a specific user would see and interact with the platform.

Practical Use Cases:

• Testing if a user can access a specific record or module.
• Verifying if UI policies or client scripts behave as expected for a particular user.
• Troubleshooting an issue reported by a specific user.

How to Use: Typically found in the system header or by navigating to “Impersonate User” from the user menu.

Interview Relevance: Shows you understand essential administrative and debugging tools.

Answer: User preferences are personalized settings that individual users can configure for their own ServiceNow experience. These settings are stored on a per-user basis and do not affect other users globally. Examples include list column configurations, form layouts, notification settings, and theme choices.

Practical Explanation: If you decide to hide a specific column in the Incident list view, that change only impacts your view; your colleague will still see the default columns unless they make the same change. This personalization enhances user efficiency and satisfaction.

Answer: An Incident is a sudden interruption to an IT service or a reduction in the quality of an IT service. For an end-user, it’s when something they rely on stops working as expected, hindering their ability to perform their job. The goal of Incident Management is to restore normal service operation as quickly as possible with minimal business impact.

Example: An employee can’t access their email. This is an incident. They would typically report this by creating an incident record (or having it created for them) in ServiceNow.

Interview Relevance: This is a foundational ITSM concept. You must be able to define it clearly and explain its purpose.

Answer: A Problem is typically the underlying cause of one or more Incidents. If the same issue occurs repeatedly, or if a single incident is complex and requires in-depth investigation, it’s often escalated to a Problem record. The goal of Problem Management is to identify the root cause of incidents and prevent their recurrence.

Relationship to Incidents:

• If the same issue happens to one employee repeatedly, it might start as an incident and then be linked to a problem.
• If the same issue happens to multiple people simultaneously, it might be logged as one “parent” incident with multiple “child” incidents linked to it. The problem record would then be linked to this parent incident.

Closing the parent incident and its associated problem often automatically closes the child incidents, streamlining resolution.

Interview Relevance: Understanding the distinction between Incident and Problem is critical for demonstrating knowledge of ITSM best practices.

Answer: Absolutely! This is a core workflow in ServiceNow. If a support engineer identifies that an incident is recurring or requires deeper investigation, they can create a Problem record directly from the Incident form. This typically creates a link between the incident and the new problem record, allowing the problem management team to work on the root cause.

How: On the Incident form, there’s usually a “Create Problem” or “Elevate to Problem” related link or button.

Answer: Yes, this is another fundamental integration within ITSM. If resolving an incident requires a modification to the IT infrastructure or an application (e.g., deploying a patch, reconfiguring a server), the support engineer can initiate a Change Request from the Incident. This ensures that necessary changes are properly documented, planned, approved, and implemented according to change management processes, preventing further disruptions.

How: Similar to creating a problem, there’s typically a “Create Change Request” related link or button on the Incident form.

Answer: Using GlideRecord on the server-side:

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bf8bcbe5d94'; // sys_id of the caller
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // sys_id of the CI
gr.short_description = 'Test record created via script';
gr.description = 'This incident was automatically generated for testing purposes.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group
gr.insert();
            

Practical Explanation: This script inserts a new incident record, populating key fields like caller, category, configuration item, short description, and assignment group.

Troubleshooting Tip: Ensure you have valid sys_ids for all referenced fields. Errors often occur if a sys_id is incorrect or points to an inactive record.

Answer: Similar to creating an incident, you use GlideRecord on the problem table:

var gr = new GlideRecord('problem');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bf8bcbe5d94'; // 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 problem record was automatically generated.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group
gr.insert();
            

Practical Explanation: This script creates a new problem record. Notice the table name change to problem. Fields like problem_id would be used if linking to incidents later.

Answer: You’d script this against the change_request table:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'inquiry'; // Note: Category for change might differ from incident
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8be5dc3'; // sys_id of the CI
gr.short_description = 'Test change request created via script';
gr.description = 'This change request was automatically generated.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of the assignment group
// You'd typically set other critical fields like 'type', 'reason', 'requested_by', etc.
gr.insert();
            

Practical Explanation: This script creates a new change request. For change requests, you’d often need to populate more specific fields like ‘Type’ (Normal, Standard, Emergency), ‘Reason’, ‘Risk’, and ‘Impact’ depending on your organization’s process.

Answer: This logic is best implemented using an After Business Rule on the incident table.

Business Rule Configuration:

• Table: Incident
• When to run: After
• Operation: Update
• Filter Conditions: State changes to Closed (or your organization’s closed state value) AND Parent is empty (to ensure it’s a top-level incident).

Script:

// Check if the current incident is the parent and has been closed
if (current.state.changesTo(7) && current.parent == '') { // Assuming state '7' is 'Closed'
    // GlideRecord to find child incidents
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id);
    grChild.query();
    while (grChild.next()) {
        // Set the state to Closed for the child incident
        grChild.state = 7; // Set the state to Closed
        grChild.update();  // Update the child incident
    }
}
            

Explanation: This Business Rule triggers *after* a parent incident is updated and its state changes to Closed. It then queries for all incidents where the ‘parent’ field points to the current incident’s sys_id. For each found child incident, it sets the state to Closed and saves the record.

Troubleshooting Tip: Ensure the state value for ‘Closed’ is correct for your instance. If child incidents aren’t closing, verify the `parent` field is correctly populated on those child records.

Interview Relevance: This is a common scenario testing your understanding of Business Rules, parent-child relationships, and scripting for automation.

Answer: This is best handled with an Before Business Rule on the incident table.

Business Rule Configuration:

• Table: Incident
• When to run: Before
• Operation: Update
• Filter Conditions: State changes to Closed.

Script:

// Check if the current incident is attempting to be closed
if (current.state.changesTo(7)) { // Assuming state '7' is 'Closed'
    // GlideRecord to find open incident tasks associated with this incident
    var grTask = new GlideRecord('incident_task');
    grTask.addQuery('incident', current.sys_id);
    // Check for any state that is NOT 'Closed' (assuming 3 is 'Closed')
    grTask.addQuery('state', '!=', 3);
    grTask.query();

    // If any open tasks are found
    if (grTask.hasNext()) {
        gs.addErrorMessage('Cannot close the incident because there are open tasks.');
        current.setAbortAction(true); // Prevent the incident from being closed
    }
}

// For Problem and Change Request, you'd create similar Before Business Rules
// on their respective tables, checking against 'problem_task' or 'change_task'
// and the 'problem' or 'change_request' tables.
            

Explanation: A “Before” Business Rule runs *before* the record is saved to the database. If the state is changing to Closed, this script checks for any associated incident_task records that are not in a closed state. If open tasks are found, it adds an error message to the user and uses current.setAbortAction(true) to stop the incident from being updated (i.e., closed).

Troubleshooting Tip: Ensure the state values used in the queries (`7` for incident closure, `3` for task closure) are accurate for your instance. The same logic applies to checking tasks for Problem and Change Request records, just targeting different task tables.

Interview Relevance: This showcases your ability to implement validation rules and enforce process compliance using Business Rules.

Answer: This is typically implemented with an After Business Rule on the problem table.

Business Rule Configuration:

• Table: Problem
• When to run: After
• Operation: Update
• Filter Conditions: State changes to Closed (assuming state 7).

Script:

// Check if the current problem has been closed
if (current.state.changesTo(7)) { // Assuming state '7' is 'Closed'
    // GlideRecord to find incidents associated with this problem
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Link incidents via the problem_id field
    grIncident.addQuery('state', '!=', 7); // Only update incidents that are not already closed
    grIncident.query();
    while (grIncident.next()) {
        grIncident.state = 7; // Set the state to Closed
        grIncident.update();  // Update the incident
    }
}
            

Explanation: After a Problem record is updated and its state changes to Closed, this rule finds all Incidents linked to that Problem (via the problem_id field) that are not already closed. It then sets their state to Closed.

Troubleshooting Tip: Ensure the `problem_id` field is correctly populated on all incidents linked to a problem. Verify the state value for ‘Closed’.

Interview Relevance: Demonstrates understanding of inter-module dependencies and automation in ITSM.

Answer: These three processes are core pillars of ITSM and are highly interconnected:

• Incident Management: Focuses on restoring normal service operations as quickly as possible after a disruption. It’s about getting users back to work. (e.g., “My laptop won’t boot.”)
• Problem Management: Focuses on identifying the root cause of recurring or significant incidents and preventing them from happening again. It’s about finding the “why.” (e.g., “The recurring laptop boot issue is caused by a faulty driver update.”)
• Change Management: Focuses on managing all changes to the IT environment in a controlled way to minimize risk and disruption. It’s about implementing and managing modifications. (e.g., “We will deploy a new driver to all laptops to fix the boot issue.”)

The Flow: A user reports an Incident. If the incident is complex, recurring, or has a significant impact, it might be escalated to a Problem to find the root cause. Once the root cause is identified, a change might be required to fix it. This triggers a Change Request to implement the fix in a controlled manner.

Interview Relevance: This question is fundamental for any ITSM role. A clear explanation shows you understand the lifecycle of IT service issues and resolutions.

Answer: Out-of-the-box tables are those provided by ServiceNow itself, typically not starting with a custom prefix like x_ or u_. Some common examples include:

• incident
• problem
• change_request
• task (a base table for many others)
• cmdb_ci (base table for Configuration Items)
• sys_user
• sys_user_group
• sys_audit
• sc_req_item (Service Catalog Requested Item)
• sc_catalog (Service Catalog)

Practical Explanation: Tables starting with x_ usually indicate tables created within a scoped application, while tables starting with u_ were historically used for global custom tables.

Answer: Base tables are foundational tables that are extended by many other tables but do not extend any other table themselves (or only extend a very fundamental table like cmdb_ci). They provide common fields and structure.

Key examples:

• task: This is the parent table for many ITSM records like Incidents, Problems, Changes, and Service Requests. It contains fields common to all tasks (e.g., short description, state, assigned to, assignment group).
• cmdb_ci: This is the base table for all Configuration Items (CIs) in the Configuration Management Database (CMDB). All specific CI types (Servers, Applications, Databases) extend from this.
• sys_user: The base table for all user records.
• sys_documentation: Stores metadata about tables and fields.

Explanation: When you extend a table, you inherit its fields. This is a core concept of relational databases and ServiceNow’s data model.

Answer: Tables that extend the task table are considered task tables. They inherit common fields from task.

Common examples include:

• incident
• problem
• change_request
• sc_task (Service Catalog Task)
• incident_task (Incident Task)
• kb_submission (Knowledge Submission)

Practical Explanation: This inheritance allows for consistent reporting and workflow management across different types of work items.

Answer: By default, when you create a new table and check the “Create application menus and module entries” or similar options that indicate it will be user-facing, ServiceNow automatically generates four base ACLs for it:

1. read: Allows users to read records.
2. write: Allows users to update records.
3. create: Allows users to create new records.
4. delete: Allows users to delete records.

These are generated to provide basic access, often granting it to the admin role or a role specific to the application if created within a scope. If you uncheck the option to create ACLs during table creation, none will be generated automatically.

Best Practice: Always review and customize these default ACLs to enforce proper security based on your organization’s needs. Don’t rely solely on the defaults.

Answer: ServiceNow uses an “Auto-number” feature for fields like number, sys_id, and custom unique identifiers. When creating or editing a table’s dictionary entry for a number field, you would:

1. Go to the dictionary entry for the field.
2. On the “Control” tab, check the “Auto number” checkbox.
3. Configure the “Number specification”. This is where you define the prefix and the number of digits. For example, `INC` for prefix and `7` for digits would result in numbers like `INC0000001`, `INC0000002`, etc.

Practical Explanation: This ensures that each record gets a unique, sequentially generated number, which is crucial for identification and tracking.

Answer: When you extend a table (e.g., create a new table that inherits from task), the child table inherits all the fields from the parent table. This means you don’t need to recreate common fields like short_description, state, or assigned_to in the child table.

Key behaviors:

• Inheritance: The child table automatically has all fields from the parent.
• `sys_` fields: System fields like sys_created_on, sys_updated_on, sys_id, etc., are inherited from the parent and are not recreated in the child.
• `class` field: A field named class is automatically 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 store the sys_id of the incident table). If a table is extended multiple times, there’s still only one class field in the ultimate parent, indicating the specific child record type.

Practical Explanation: This is the foundation of object-oriented programming principles applied to database design, promoting code reusability and data consistency.

Answer: ServiceNow offers a wide variety of field types. Here are 10 common ones:

1. Reference: Links to another record in a different table.
2. String: For text input (single or multi-line).
3. List: Allows selecting multiple references from another table.
4. Choice: Provides a dropdown list of predefined options.
5. Email: For email addresses, with validation.
6. Date/Time: For selecting both date and time.
7. Date: For selecting only the date.
8. Boolean: A true/false checkbox.
9. Integer: For whole numbers.
10. Journal: For long text entries, often with history (like work notes or comments).
11. Attachment: Allows attaching files.
12. URL: For web addresses.

Interview Relevance: Demonstrates familiarity with the building blocks of ServiceNow forms and data structures.

Answer:

• Normal Tables: These tables store data permanently unless explicitly deleted. They are used for core business data that needs to be retained.
• Temporary Tables: These tables are designed to hold data for a limited time. They typically extend the import_set_row table or similar structures and are used for staging data during import processes, batch jobs, or temporary data holding. ServiceNow automatically purges data from these tables after a certain period (often around 7 days, but configurable).

Practical Explanation: Temporary tables are crucial for efficient data imports and transient data processing, preventing the permanent tables from being cluttered with data that’s only needed for a short duration.

Answer: Yes, you can typically increase the retention period for data in temporary tables. This is usually achieved through Archive Rules or specific system properties related to data retention and cleanup jobs. For instance, you might configure an archive rule to retain data for 30 days instead of the default 7.

Best Practice: While possible, do this judiciously. Temporary tables are meant for short-term data. Extending retention significantly can impact system performance and storage. Always consider the business justification.

Answer:

• Normal Tables: These tables store data directly within the ServiceNow instance’s database. When you query a normal table, you are retrieving data that resides locally.
• Remote Tables: These tables allow you to access and display data from an external data source (like another ServiceNow instance, a different database, or an external application via APIs) directly within your ServiceNow instance. The data itself doesn’t reside in your ServiceNow instance’s database; you’re essentially querying it in real-time from its original location.

Practical Explanation: Remote tables are powerful for integrating data without needing to duplicate it. For example, you could display a list of active customers from a CRM system directly on a ServiceNow form.

Interview Relevance: Shows understanding of advanced integration patterns and data sourcing.

Answer: These define 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 many records in Table B, but each record in Table B is related to only one record in Table A.
  • Example: A User (Table A) can have multiple Incidents (Table B). Each incident is typically assigned to only one user. The caller_id field on the incident table is a reference to the sys_user table.
• Many-to-Many Relationship: This means many records in Table A can be related to many records in Table B, and vice-versa. This is typically achieved using a junction table.
  • Example: Incidents (Table A) and Groups (Table B). An incident can be assigned to multiple groups (e.g., for collaboration), and a group can work on multiple incidents. The sys_user_group table (for users in groups) or custom junction tables are used here. The sys_user_grmember table is a perfect example of a junction table for a many-to-many relationship between users and groups.

Explanation: Understanding these relationships is fundamental for designing schemas, creating reports, and building integrations.

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

1. Forms: The most direct way, using the user interface.
2. List View: Creating new records directly in a list view.
3. GlideRecord Scripting: Server-side scripts (Business Rules, Script Includes, Fix Scripts) using new GlideRecord('table_name').insert();.
4. Record Producers: User-facing forms (often linked from Service Catalog or portals) that create records in backend tables.
5. Email: Inbound email actions can parse incoming emails to create records (e.g., creating an incident from an email).
6. Import Sets: Importing data from Excel, CSV, or other sources.
7. Web Services: Using REST or SOAP APIs to create records from external applications.
8. Flow Designer/Workflows: Automated processes can create records as part of a larger workflow.
9. UI Actions: Custom buttons or links that trigger script actions to create records.

Interview Relevance: Shows awareness of the different data entry and automation mechanisms within ServiceNow.

Answer: You can control field behavior (mandatory, read-only, visibility) using several methods:

• Dictionary Properties: Directly on the field’s dictionary entry (e.g., “Mandatory” checkbox, “Read only” attribute).
• Dictionary Overrides: To change the behavior of a field from a parent table in a child table.
• UI Policies: Client-side (browser) logic that can make fields mandatory, read-only, or visible based on conditions.
• Data Policies: Similar to UI Policies but can enforce rules at both the client and server sides, making them more robust for data integrity.
• Client Scripts: Using g_form.setMandatory('field_name', true/false);, g_form.setReadOnly('field_name', true/false);, and g_form.setVisible('field_name', true/false); for client-side control.
• Server-side Scripting (Business Rules/Script Includes): While not directly controlling UI behavior, server-side scripts can influence the data itself, which indirectly affects subsequent UI rendering. For read-only, you might set attributes server-side.

Best Practice: UI Policies are generally preferred for client-side form behavior as they are more visual and easier to manage than pure Client Scripts. Data Policies are excellent for ensuring data integrity across all entry points.

Interview Relevance: This question tests your understanding of client-side vs. server-side control and the different tools available for form customization.

Answer: No, you generally should not make two fields “display” in a single table. The “Display” attribute on a dictionary entry is intended to be a unique identifier that is shown in reference fields. If multiple fields are marked as “Display,” it can lead to confusion, unpredictable behavior in reference lookups, and incorrect display in related lists and reports.

Best Practice: Designate only one field (usually a unique, descriptive field like ‘Number’ or ‘Name’) as the primary display value for a table.

Troubleshooting Tip: If you find multiple display fields, it’s a good candidate for cleanup to ensure data integrity and predictable UI behavior.

Answer: Information about all tables in ServiceNow, including custom tables and OOTB tables, is stored in the sys_db_object table. This table holds metadata about each database object (table) in the instance.

Practical Explanation: This is where ServiceNow keeps track of the structure and properties of your entire database.

Answer: You can set default values for fields in several ways:

• Dictionary Entry: On the field’s dictionary record, there’s a “Default value” field. This value will be pre-populated when a new record is created and the field is not otherwise populated.
• UI Policies: You can set default values as part of a UI Policy action, often applied when a form loads or a condition is met.
• Client Scripts: Using g_form.setDefaultValue('field_name', value); in an OnLoad client script.
• Business Rules: For server-side defaults that should be applied before record insertion/update, you can set current.field_name = value; in a Before Business Rule.
• Data Policies: Similar to UI Policies, can set default values.

Best Practice: For simple, static defaults, the Dictionary Entry is the cleanest. For dynamic defaults that depend on context, UI Policies or Client Scripts are often used.

Answer: The current object is a server-side scripting object available in contexts like Business Rules, Fix Scripts, and some workflow activities. It represents the record that is currently being processed (e.g., the record being inserted, updated, or deleted).

Purpose: It allows you to read and modify the values of fields on the record being processed before it’s saved to the database or after an operation completes.

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

• current.setValue('field_name', value);: This is the standard way to set a field’s value. For reference fields, you must provide the sys_id of the referenced record as the value.
• current.setDisplayValue('field_name', value);: This method is useful for setting values for reference fields using their display value (e.g., the user’s name instead of their sys_id) or for choice lists using the choice text. However, be cautious as it relies on the display value being unique and can lead to issues if not used carefully.
• Direct Assignment: For simple fields, you can often directly assign values: current.short_description = 'New value';

Practical Explanation: These methods are essential in Business Rules to manipulate data before it’s committed to the database.

Troubleshooting Tip: When setting reference fields, always use the sys_id with setValue for reliability. setDisplayValue can be convenient but is more prone to errors if display values change or are not unique.

Answer: Reference Qualifiers are used to filter the list of records that can be selected in a reference or list field. They restrict the available choices, making data entry more accurate and efficient.

Types of Reference Qualifiers:

1. Simple Reference Qualifier:

Description: This is the most straightforward type, allowing you to specify a fixed query directly in the dictionary entry of the reference field. It’s ideal for static filtering conditions.

Example: On an Incident form, you might have a reference field for “Assigned to” that should only show active users. The simple reference qualifier would be active=true.

How to Use: In the reference field’s dictionary entry, under the “Reference Qual.”) tab, choose “Simple” and enter your query conditions (e.g., state=1^department=Engineering).

2. Dynamic Reference Qualifier:

Description: This type uses a dynamically generated query that can adapt based on the context of the form or other variables. It relies on predefined “Dynamic Filter Options.”

Example: Displaying only users who belong to the same “assignment group” as the current incident. This is dynamic because the assignment group can change.

How to Use:

1. Create a Dynamic Filter Option (System Definition > Dynamic Filter Options).
2. Define the conditions for your dynamic filter.
3. In the reference field’s dictionary entry, choose “Dynamic” for the reference qualifier type and select your created Dynamic Filter Option.

3. Advanced Reference Qualifier (JavaScript Reference Qualifier):

Description: This is the most powerful type, allowing you to use custom JavaScript code to define complex, context-aware queries for the reference field. It offers the greatest flexibility.

Example: Filtering a list of CIs to show only those associated with the caller’s department and that are currently in production status.

How to Use: In the reference field’s dictionary entry, choose “Advanced” for the reference qualifier type and enter your JavaScript code in the “JavaScript condition” field. This script should return a query string.

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

The current object is available here, allowing you to reference fields from the current form.

Differences Explained:

• Simple vs. Dynamic: Simple is static. Dynamic adapts based on predefined rules that use form context.
• Dynamic vs. Advanced: Dynamic uses predefined filters. Advanced allows for custom JavaScript logic for maximum flexibility and complex conditions.
• Simple vs. Advanced: Simple is a fixed query. Advanced uses JavaScript to build a query that can be highly dynamic and complex, referencing multiple form fields and server-side logic.

Interview Relevance: This is a critical topic for ServiceNow developers and administrators. A clear explanation of all three types and their use cases is a must.

Answer: Dependent Values are a mechanism in ServiceNow that creates cascaded dropdowns. This means the choices available in one field (the dependent field) are filtered based on the selection made in another field (the parent field). This is commonly used for categories and subcategories.

Example:

• Parent Field: Category (e.g., “Hardware”, “Software”, “Network”)
• Dependent Field: Subcategory (e.g., “Laptop”, “Desktop”, “Printer” for Hardware; “Operating System”, “Application” for Software).

When a user selects “Hardware” in the Category field, the Subcategory dropdown will only show hardware-related options. If they select “Software,” the Subcategory options change accordingly.

How to Configure:

1. On the dictionary entry for the dependent field (e.g., incident.subcategory), go to the “Dictionary” tab.
2. In the “Dependent field” attribute, enter the name of the parent field (e.g., category).
3. On the “Choices” tab for the dependent field, define the choices. For each choice, you can specify which parent field value it belongs to.

Practical Explanation: This significantly improves user experience and data accuracy by guiding users to select appropriate options.

Answer: A calculated value, typically configured in the field’s Dictionary Entry under the “Calculation” tab, means the field’s value is automatically computed based on a formula or script. When the form is saved or an update occurs, ServiceNow evaluates the expression or script, and the result populates the field.

Example: A “Total Price” field on a sales order might be calculated by summing the “Quantity” and “Unit Price” fields using a formula like quantity * unit_price.

Practical Explanation: This is useful for fields that derive their value from other fields, ensuring data consistency without manual intervention.

Answer: Attributes are special keywords entered in the “Attributes” field on a field’s Dictionary entry. They modify the behavior or appearance of that field on forms, lists, and other parts of the ServiceNow UI.

Commonly Used Attributes:

• no_email: Prevents emails from being sent for updates to this field.
• no_attachment: Disables the attachment icon for this field (more commonly applied to the table itself).
• tree_picker: Displays a field as a tree-like structure (often for hierarchy or category selection).
• ref_auto_completer=...: Controls the auto-completion behavior for reference fields.
• ref_ac_columns=...: Specifies which columns to display in the auto-complete lookup for a reference field.
• disabled: Makes the field non-editable.
• glide_date_time: Forces a field to behave as a date-time picker.
• is_active=true: Often used on the ‘Active’ field of tables to indicate it’s the primary status indicator.

Practical Explanation: Attributes are a powerful, yet simple, way to customize field behavior without writing complex scripts.

Interview Relevance: Knowing common attributes shows practical experience in fine-tuning ServiceNow fields.

Answer: In ServiceNow’s dictionary, a “collection” entry refers to the table itself, not an individual field on that table. When you create a table, an entry is automatically created in sys_dictionary with the “Type” set to “Collection.” Any attributes or properties set on this collection entry apply to the table as a whole.

Example: Setting the no_attachment attribute on the collection field entry for the incident table will disable attachments for all incidents.

Practical Explanation: This is how ServiceNow manages table-level configurations and attributes.

Answer: To control attachments for a table (and thus on all forms for that table), you modify the “Attributes” field on the collection entry for that table in the sys_dictionary table.

• To disable attachments: Add the no_attachment attribute to the collection field.
• To enable attachments: Ensure the no_attachment attribute is not present. By default, attachments are usually enabled unless explicitly disabled.

How: Navigate to System Definition > Dictionary, filter for your table’s collection entry (where Type is ‘Collection’), and edit the Attributes field.

Answer: Dictionary Overrides allow you to modify the behavior or properties of a field that has been inherited from a parent table in a child table. Instead of altering the parent’s field definition (which would affect all its descendants), you create a specific override for the child table.

Properties that can be overridden:

• Display: Whether the field is a display value.
• Mandatory: Whether the field is required.
• Read only: Whether the field is editable.
• Default value: A new default value for the field in the child table.
• Maximum length: For string fields.
• Reference Qualifiers: To apply specific filters for reference fields in the child table.
• Attributes: To add or remove specific field attributes.
• Calculation: To define a new calculation script or formula.
• Comment: Adding or modifying the field’s description.
• Help text: Custom help text for the field.
• Choice list configuration: Modifying choice lists if the field is of type Choice.

Example: The priority field might have a default value of 4 in the task table. In the incident table (which extends task), you can create a dictionary override for the priority field to set its default value to 5, or make it mandatory.

Best Practice: Use dictionary overrides to customize inherited fields without impacting other tables that use the same parent field. This promotes modularity and maintainability.

Answer: Application Menus (often referred to as Modules) are navigational entries that appear in the left-hand navigation menu (the “application navigator”) of ServiceNow. They provide users with quick access to specific forms, lists, reports, or dashboards defined within an application.

Example: Under the “Incident” application menu, you’ll find modules like “Open,” “All,” “Resolved,” “On Hold,” etc. Clicking on these modules takes you to the relevant list views or forms.

Practical Explanation: They are crucial for organizing and making your ServiceNow instance user-friendly. You create them when defining new applications or modules within existing ones.

Answer: Process Flow is a visual representation of the stages or steps involved in a particular workflow or business process within ServiceNow. It helps users understand where they are in a process and what the next steps are.

Example: On an Incident form, the process flow might show stages like “New” > “In Progress” > “On Hold” > “Resolved” > “Closed.” As the incident moves through these states, the process flow visualizer updates to highlight the current stage.

Practical Explanation: It improves user comprehension and guides them through complex processes, enhancing efficiency and reducing errors.

Answer: Data Lookup Rules (found under System Policy > Rules > Data Lookup Rules) allow you to automatically populate fields on a form based on the values of other fields on the same form. They are a simpler, configuration-based alternative to writing complex scripts for basic data population.

Example: If you select a “Country” (e.g., “United States”) on a form, a Data Lookup Rule could automatically populate the “State/Province” field with a default value (e.g., “California”) or restrict it to relevant states based on the country.

Practical Explanation: They are excellent for standardizing data entry and reducing manual work for common scenarios. They work at the client-side.

Answer: UI Policies are client-side scripts that automate form interactions and behavior based on specific conditions. They are a more user-friendly, point-and-click alternative to traditional Client Scripts for many common tasks.

What they can do:

• Make fields mandatory.
• Make fields read-only.
• Make fields visible or invisible.
• Set default values for fields.
• Show or hide related lists.

They operate based on conditions evaluated when a form loads or when field values change.

Interview Relevance: Understanding UI Policies is fundamental for form customization and user experience design in ServiceNow.

Answer: The “Global” checkbox in a UI Policy determines its scope of application:

• Checked (Global): The UI Policy will apply to all views of the form.
• Unchecked (Not Global): The UI Policy will only apply to specific views that you define in the “Views” related list on the UI Policy record.

Practical Explanation: This is crucial for managing UI behavior across different user interfaces or customized views of the same form.

Answer: The “Reverse if false” checkbox in a UI Policy is a powerful feature that allows you to define what happens when the UI Policy’s conditions evaluate to false. If checked, any actions performed by the UI Policy when its conditions were true will be reversed when the conditions become false.

Example:

• UI Policy Condition: If “State” is “In Progress”.
• UI Policy Action: Make “Assignment Group” mandatory.
• If “Reverse if false” is checked: When the State changes from “In Progress” back to something else (e.g., “New”), the “Assignment Group” will automatically become optional again.

Practical Explanation: This saves you from creating a separate UI Policy or complex scripting to undo actions when conditions change.

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

• Checked: The UI Policy runs immediately when the form loads, applying its actions based on the initial state of the form.
• Unchecked: The UI Policy does not run when the form loads. Its actions will only be triggered by user interactions or changes to field values after the form has loaded.

Practical Explanation: “On Load” is essential for setting initial form states (e.g., making a field mandatory based on a default value when the form first appears). If you only want actions to trigger based on user input, you would uncheck it.

Answer: The “Inherit” checkbox in a UI Policy determines whether the UI Policy’s rules will be applied to tables that extend the current table (child tables).

• Checked: The UI Policy will be inherited by child tables. If you have a UI Policy on the task table and “Inherit” is checked, it will also apply to incident, problem, and other tables extending task.
• Unchecked: The UI Policy will only apply to the table on which it is defined.

Practical Explanation: This is a powerful feature for maintaining consistent form behavior across hierarchical table structures.

Answer: Yes, you can! While UI Policies are largely configuration-driven, they offer the ability to execute custom JavaScript using the “Run scripts” option within the UI Policy Actions. When you enable “Run scripts” for a UI Policy Action, you gain access to client-side scripting fields where you can write JavaScript to perform more complex actions or conditional logic that cannot be achieved through the standard configuration options.

How: On the UI Policy Actions related list, you can enable the “Run scripts” checkbox for a specific action. This exposes “Script” and “UI Policy Script” fields where you can write your client-side code. You can also add client scripts that are triggered by UI Policy actions.

Interview Relevance: Shows you understand the hybrid nature of UI Policies, combining declarative configuration with custom scripting.

Answer: Yes, you can convert a UI Policy into a Data Policy. ServiceNow provides a utility for this. When you convert a UI Policy, the conditions and actions defined in the UI Policy are translated into the equivalent settings in a new Data Policy record.

How: Navigate to the UI Policy record you want to convert. There is usually a UI Action (a button or link) that says “Convert to Data Policy.” Clicking this will create a new Data Policy and populate it with the details from the UI Policy.

Best Practice: Data Policies are generally preferred for enforcing data integrity as they work on both client and server sides, ensuring rules are enforced regardless of how the record is accessed. Convert UI Policies to Data Policies when possible, unless you specifically need client-side-only UI interactions.

Answer: While the conversion utility is powerful, there are specific functionalities of UI Policies that cannot be directly translated into Data Policies because Data Policies operate at a data level and don’t directly control UI presentation or specific view configurations.

Cases where conversion might not be fully automatic or applicable:

• Controlling Data Visibility (Show/Hide fields): Data Policies are primarily for making fields mandatory or read-only. While you can use them to set default values, directly showing/hiding fields on the form based on conditions is a UI-specific behavior handled by UI Policies or Client Scripts.
• Controlling Views: UI Policies can be tied to specific views, which is a UI presentation aspect. Data Policies are view-agnostic.
• Controlling Related Lists: Showing or hiding related lists is a UI element controlled by UI Policies, not Data Policies.
• Complex Scripting in UI Policy Actions: If a UI Policy Action relies on complex client-side JavaScript that manipulates UI elements or performs other UI-specific tasks, a direct conversion to a Data Policy might not capture that full behavior. While Data Policies can have server-side scripts, the nuances of client-side interaction are different.

Practical Explanation: In these scenarios, you would likely convert the parts that can be translated to a Data Policy and then use Client Scripts or keep some UI Policies for the remaining UI-specific logic.

Answer: Data Policies are server-side (and optionally client-side) scripts that enforce data integrity rules on records. They are used to make fields mandatory, read-only, or set default values, regardless of how the record is accessed (e.g., via forms, imports, web services).

Key characteristics:

• Server-side Enforcement: They run on the server, ensuring data integrity is maintained even if a user bypasses form logic.
• Client-side option: They can also be configured to run on the client side for immediate user feedback, mimicking UI Policy behavior.
• Comprehensive Rules: Can enforce mandatory, read-only, and default values.
• Less UI-centric: Primarily focused on the data itself, not on specific UI elements like visibility of fields or related lists (which UI Policies handle).

Best Practice: Use Data Policies for critical data integrity rules that must be enforced universally. For UI-specific behaviors (showing/hiding fields, dynamic form layouts), use UI Policies.

Interview Relevance: Demonstrates understanding of robust data governance and the distinction between UI-level control and data-level control.