Answer: “I’m currently working on the Washington DC release, which is the latest stable version available.”

Why it matters: Different versions introduce new features, functionalities, and sometimes, changes in how certain components behave. Knowing your version helps tailor your answers and demonstrate your up-to-date knowledge.

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

Why it matters: This showcases your experience and progression within the platform. It demonstrates that you’re not new to ServiceNow and have seen how the platform evolves, which is valuable for problem-solving and understanding historical context.

Answer: “Yes, absolutely. Permissions in ServiceNow are primarily managed through roles. We can assign roles directly to individual users, or more effectively, assign them to groups. When a user is a member of a group, they inherit the roles assigned to that group.

The best practice is to manage permissions through groups. This is significantly more efficient and scalable. Instead of assigning roles individually to dozens or hundreds of users, you assign roles to a group. When an employee joins, they are added to the relevant groups. When they leave, removing them from the group automatically revokes all their inherited roles and permissions. This greatly simplifies administration and reduces the risk of orphaned permissions or security gaps.”

Real-world example: Imagine a ‘Finance Team’ group. You assign the ‘finance_manager’ role to this group. All members of the ‘Finance Team’ group automatically gain the ‘finance_manager’ permissions. If someone leaves the finance team, removing them from the group is all that’s needed.

Troubleshooting: If a user suddenly has unexpected access, check the groups they belong to and the roles assigned to those groups. Conversely, if a user lacks expected access, verify their group memberships and the roles assigned to those groups.

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

Answer: The table that links users to groups is sys_user_group_member. This table contains records representing which user is a member of which 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'; // Set a unique username
userGr.first_name = 'John';
userGr.last_name = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.insert();
            

Explanation: We instantiate a GlideRecord object for the sys_user table, initialize it, set the required fields (username, first name, last name, email), and then call insert() to save the new record.

Troubleshooting: Ensure the username is unique, as it’s a key identifier. Check logs for any errors during insertion, such as duplicate username violations or missing mandatory fields.

Answer: Creating a group via script is also straightforward using GlideRecord:

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

Explanation: Similar to user creation, we use GlideRecord on the sys_user_group table. Key fields include name, and optionally manager (by its sys_id), email, and description.

Answer: Permissions are managed via roles. Adding a role to a user or group involves creating records in specific linking tables.

• To a User: A record is created in the sys_user_has_role table.

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();
                

• To a Group: A record is created in the sys_group_has_role table.

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();
                

Interview Relevance: This question tests your understanding of the underlying tables that manage relationships in ServiceNow, specifically how roles are associated with users and groups.

Answer: User delegation allows one user (the delegate) to perform tasks and access resources on behalf of another user (the delegator). This is typically used for situations where the delegator is unavailable, such as during vacations, extended leave, or even for temporary task coverage.

The delegator can specify:

• Delegate: The user who will perform tasks.
• Start and End Dates: The period for which delegation is active.
• Permissions: What actions the delegate can perform (e.g., approvals, notifications, assignments).

Real-world example: Sarah is going on a two-week vacation. She delegates her pending approvals for expense reports to her colleague, Mark. While Sarah is away, Mark can access and approve/reject these reports using his own login but acting on behalf of Sarah.

How to configure: Navigate to the user’s record (sys_user), scroll down to the ‘Delegates’ related list, and click ‘New’. Fill in the delegate’s name, start/end dates, and the specific permissions to delegate.

Troubleshooting: If a delegate cannot perform an action, verify the delegation record’s dates and the specific permissions granted. Ensure the delegate hasn’t exceeded their delegated authority.

Answer: This involves interacting with the sys_user_group_member table.

• Adding a Group Member:

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

• Removing a Group Member:

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

Explanation: For adding, we simply create a new record. For removing, we query for the specific user-group membership and then delete that record.

Answer: Historically, ServiceNow has had several user interfaces. The most commonly discussed are UI15, UI16, and the Next Experience UI (often referred to as the Polaris UI). While older versions might be less relevant now, understanding the evolution helps appreciate the platform’s modernization.

Answer: A ‘web services user’ (or more accurately, a user with the ‘soap’ or ‘rest_api_explorer’ role, and often a dedicated system user) is an account specifically created for programmatic access to ServiceNow, typically for integrations with other applications. These users cannot log in to the ServiceNow graphical user interface (GUI) like regular users. Their purpose is to authenticate API requests to interact with ServiceNow data and functions.

Best Practice: Always create dedicated users for integrations with the minimum necessary roles. Avoid using administrator accounts for web service access due to security risks.

Answer: On the client-side (e.g., in client scripts, UI policies), you can use the global JavaScript object g_user:

var currentUserId = g_user.userID; // or g_user.sys_id
console.log("Current User Sys ID (Client-side): " + currentUserId);
            

Answer: On the server-side (e.g., in business rules, script includes), you use the gs (GlideSystem) object:

var currentUserId = gs.getUserID();
gs.info("Current User Sys ID (Server-side): " + currentUserId);
            

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

var groupName = 'IT Support'; // Replace with the actual group name or Sys ID
if (gs.getUser().isMemberOf(groupName)) {
    gs.info("User is a member of the " + groupName + " group.");
} else {
    gs.info("User is NOT a member of the " + groupName + " group.");
}
            

Note: You can pass either the group name or the group’s Sys ID to this method.

Client-side equivalent: While not a direct method, you’d typically achieve this by calling a Script Include from a client script or using a UI Policy to check a condition that relies on this server-side check.

Answer: The primary role required to create, modify, and manage ACLs is the security_admin role.

Important Note: While security_admin grants broad access, it’s often best practice to grant this role sparingly. For specific ACL development, other roles might suffice depending on the scope.

Answer: Impersonation is a powerful feature in ServiceNow that allows a user with appropriate permissions (usually itil role or higher, and often the admin role) to temporarily log in and act as another user. This is invaluable for testing permissions, troubleshooting user-specific issues, and verifying that ACLs are behaving as expected for different roles and users.

How to use: Navigate to the user’s record, and click the ‘Impersonate User’ button. To stop impersonating, click the ‘Stop Impersonating’ link in the header.

Troubleshooting: When testing ACLs, impersonation is your best friend. If a user reports they can’t do something, impersonate them and try to replicate the action. If you can perform it as them, the issue might be elsewhere. If you can’t, you know it’s a permission issue, and you can start investigating the ACLs.

Answer: User preferences are settings that individual users can configure to personalize their experience within ServiceNow. These preferences are stored against the specific user and do not affect other users in the system. Examples include setting default views, column preferences on lists, or notification settings.

Example: A user might set their default homepage to a specific dashboard or choose to display fewer columns in their incident list view. These choices are stored in the sys_user_preference table and are tied to their user record.

Answer: An incident is any event that disrupts or reduces the quality of a service. It’s a deviation from normal service operation. When an employee experiences an issue that prevents them from performing their work, they typically raise an incident to get support and restore service as quickly as possible.

Goal: To restore normal service operation as quickly as possible and minimize the adverse impact on business operations.

Answer: A problem is the underlying cause of one or more incidents. When the same incident occurs repeatedly, or a significant number of users are affected by a similar issue, it’s classified as a problem. The goal of problem management is to identify the root cause of incidents and prevent them from recurring.

Distinction: An incident is about restoring service. A problem is about finding and fixing the root cause. If multiple users report the same issue, they might all create separate incidents, which would then be linked to a single parent problem investigation.

Answer: Yes, this is a common workflow. If a support engineer identifies that an incident is likely part of a recurring issue or a larger underlying problem, they can create a problem record directly from the incident. This usually involves a ‘Create Problem’ button or action on the incident form, which pre-populates the problem record with relevant incident details.

Answer: Yes, this is also a standard process. If resolving an incident requires a change to the IT infrastructure or application (e.g., a software patch, configuration update), the support engineer can initiate a change request from the incident. This ensures that the necessary change is tracked, approved, and implemented in a controlled manner.

Answer: Using GlideRecord for incident creation:

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bc5d94'; // 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 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();
            

Answer: Similar to incidents, using GlideRecord for problem creation:

var gr = new GlideRecord('problem');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bc5d94'; // 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 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();
            

Answer: Using GlideRecord for change request creation:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8be5dc3'; // 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();
            

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

• Table: Incident [incident]
• When: After
• Update: Checked
• Condition: current.state.changesTo(7) && current.parent == '' (Assuming state 7 is ‘Closed’. Adjust state value if needed. The `current.parent == ”` ensures it’s a top-level incident, not already a child trying to close.)
• Script:

if (current.state == 7 && current.parent == '') { // Ensure state is Closed and it's a parent
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id); // Find children linked to this parent
    grChild.query();
    while (grChild.next()) {
        if (grChild.state != 7) { // Only update if not already closed
            grChild.state = 7; // Set the state to Closed
            grChild.update(); // Update the child incident
        }
    }
}
                

Troubleshooting: If child incidents aren’t closing, double-check the ‘Closed’ state value. Also, verify that the parent field on child incidents is correctly populated with the parent’s sys_id.

Answer: This requires a Before Business Rule on the incident table (and similar rules for problem and change_request).

• Table: Incident [incident]
• When: Before
• Update: Checked
• Condition: current.state.changesTo(7) (Assuming state 7 is ‘Closed’)
• Script:

// Check for open Incident Tasks
var grTask = new GlideRecord('incident_task');
grTask.addQuery('incident', current.sys_id);
grTask.addQuery('state', '!=', 3); // Assuming state 3 is 'Closed'. Adjust if needed.
grTask.query();
if (grTask.hasNext()) {
    gs.addErrorMessage('Cannot close the incident because there are open incident tasks.');
    current.setAbortAction(true); // Prevents the incident from being updated
}

// For Problem Management (on problem table, check problem tasks)
// var grProblemTask = new GlideRecord('problem_task');
// grProblemTask.addQuery('problem', current.sys_id);
// grProblemTask.addQuery('state', '!=', 3); // Assuming state 3 is 'Closed'
// grProblemTask.query();
// if (grProblemTask.hasNext()) {
//     gs.addErrorMessage('Cannot close the problem because there are open problem tasks.');
//     current.setAbortAction(true);
// }

// For Change Management (on change_request table, check change tasks)
// var grChangeTask = new GlideRecord('change_task');
// grChangeTask.addQuery('change_request', current.sys_id);
// grChangeTask.addQuery('state', '!=', 3); // Assuming state 3 is 'Closed'
// grChangeTask.query();
// if (grChangeTask.hasNext()) {
//     gs.addErrorMessage('Cannot close the change request because there are open change tasks.');
//     current.setAbortAction(true);
// }
                

Explanation: A Before rule is crucial here because we want to prevent the update (closing the incident) from happening if the condition isn’t met. current.setAbortAction(true) is the key to stopping the transaction.

Troubleshooting: Ensure the ‘Closed’ state values for incidents, problems, changes, and their respective task types are correct. If the error message doesn’t appear, the condition or the query might be off.

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

• Table: Problem [problem]
• When: After
• Update: Checked
• Condition: current.state.changesTo(7) (Assuming state 7 is ‘Closed’)
• Script:

if (current.state == 7) { // Ensure state is Closed
    // GlideRecord to find incidents associated with this problem
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Link based on problem_id field
    grIncident.addQuery('state', '!=', 7); // Find 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: When a problem is updated and its state becomes ‘Closed’, this rule finds all incidents linked to that problem (via the problem_id field) and updates their state to ‘Closed’ as well.

Troubleshooting: Verify that the problem_id field is consistently populated on incidents that are linked to problems. Also, confirm the state values.

Answer: These are interconnected processes within IT Service Management (ITSM):

• Incident: Focuses on restoring service as quickly as possible when something breaks. It’s about resolving the immediate issue.
• Problem: Investigates the root cause of recurring or significant incidents to prevent them from happening again. It aims to eliminate the underlying cause.
• Change: Manages the lifecycle of all changes to IT services and infrastructure. Any modification to a system, whether to fix a problem, implement a new feature, or enhance performance, typically goes through a change request to ensure it’s planned, tested, and approved.

Flow: A user reports an incident. If it’s a recurring or widespread issue, a problem is identified to find the root cause. Once the root cause is found, the solution might involve making a modification to the system, which then triggers a change request to implement that fix in a controlled manner.

Interview Relevance: This question tests your understanding of fundamental ITSM processes and how they work together in a real-world IT environment.

Answer: Out-of-the-box tables are those provided by ServiceNow by default. They typically do not start with x_ (custom tables in scoped applications) or u_ (legacy custom tables). Some common examples include:

• incident
• problem
• change_request
• sc_req_item (Requested Item)
• cmdb_ci (Configuration Item base table)
• sys_user
• sys_user_group
• sys_audit (Audit trail)
• sys_journal_field (For journal fields like comments)

Answer: Base tables are core tables in ServiceNow that are often extended by many other tables. They provide foundational data structures. They are not usually extended by other tables themselves (though there are exceptions). Common examples include:

• task: This is a crucial base table extended by incident, problem, change, etc., providing common fields like number, state, assignment group.
• cmdb_ci: The base table for all Configuration Items in the CMDB.
• sys_security_acl: The base table for Access Control Lists.
• sys_user: The base table for user records.

Explanation: Extending a base table allows you to inherit its fields and structure, promoting data consistency and code reuse.

Answer: The task table is a widely extended base table. Examples of tables that extend task include:

• incident
• problem
• change_request
• sc_task (Catalog Task)
• incident_task
• problem_task
• change_task

Interview Relevance: This question checks your understanding of table hierarchies and how ServiceNow organizes its data.

Answer: By default, when you create a new table, ServiceNow automatically generates four Access Control Lists (ACLs) if the “Create ACLs” checkbox is selected during table creation. These are:

• *.* (Read, Write, Create, Delete) – Typically assigned to the admin role.
• *.none (Read) – For general read access, often to the public role or specific user roles.
• *.none (Write) – This is unusual and generally restricted.
• *.none (Create) – For creating new records.
• *.none (Delete) – For deleting records.

Important: These default ACLs are very broad and usually need to be refined or replaced with more specific ACLs tailored to your security requirements. If you uncheck the “Create ACLs” option, you’ll need to manually create all necessary ACLs.

Answer: Number fields (like incident_number) are typically auto-numbered. When creating or configuring a table, you can define an auto-number specification:

1. Go to System Definition > Tables.
2. Open the table record you want to add the number field to (or create a new table).
3. Under the ‘Fields’ related list, click ‘New’.
4. Set the Type to ‘String‘.
5. In the ‘Advanced view’ section (you might need to toggle to it or find it in Dictionary properties), check the ‘Auto number‘ checkbox.
6. Configure the ‘Number specification‘ field:
• Prefix: e.g., ‘INC’ for Incident.
• No. of digits: e.g., ‘00007’ for 7 digits with leading zeros.
• Next number: The starting number for the sequence.

Alternatively, for existing tables, you might edit the dictionary entry for the auto-number field and configure its properties. The sys_auto_number table stores these specifications.

Answer: When you extend a table (e.g., creating a new table that extends the task table), the child table inherits all the fields from the parent table. This means you don’t need to redefine common fields like ‘Number’, ‘State’, ‘Assignment Group’ in the child table; they are automatically available.

Key Points:

• Field Inheritance: All fields from the parent table are present in the child table.
• sys_class_name field: A field named sys_class_name is automatically added to the parent table. This field stores the actual table name (the specific record type, like ‘incident’ or ‘problem’) for any record inserted into its hierarchy. This is how ServiceNow knows which specific table a record belongs to, even when queried through the parent.
• No duplication of sys_id etc.: System fields like sys_id, sys_created_on, etc., are not duplicated in the child table; they are inherited from the parent.
• Multiple Inheritance: A table can only extend one direct parent table, but it can inherit fields indirectly through a chain of extensions.

Example: An ‘Incident’ table extends ‘Task’. When you create an incident, the sys_class_name on the ‘Task’ table record will be ‘incident’.

Answer: ServiceNow offers a rich set of field types. Here are 10 common ones:

1. Reference: Links to another record in a different table (e.g., Caller on Incident links to User).
2. String: For textual data (e.g., Short Description, Name).
3. List: Allows selection of multiple records from another table (e.g., Affected CIs on Incident).
4. Choice: A dropdown with predefined options (e.g., State, Category).
5. Email: Specifically formatted for email addresses, with validation.
6. Date/Time: For storing both date and time values.
7. Date: For storing only date values.
8. Boolean: For true/false values (e.g., Active checkbox).
9. Integer: For whole numbers.
10. Journal: For free-form text entries like comments or work notes, which also log a history.
11. Attachment: Allows users to attach files.
12. HTML: For rich text content.

Answer:

• Normal Tables: Store data permanently. They are used for core business data like users, incidents, problems, etc. Data persists until explicitly deleted or archived.
• Temporary Tables: Designed to hold data for a limited time, typically for staging purposes or processing. They usually extend the import_set_row table and have a built-in retention period (e.g., 7 days). After this period, the data is automatically purged.

Use Case: Temporary tables are commonly used during data import processes (e.g., Import Sets) where you need to load data, transform it, and then migrate it to normal tables before the temporary data is automatically cleaned up.

Answer: Yes, you can extend the retention period of data in temporary tables. This is typically done using Archive Rules. You can configure archive rules to retain data for longer periods than the default, or to archive it to a separate archive table instead of purging it.

Answer:

• Normal Tables: Store data directly within your ServiceNow instance’s database. When you query these tables, you are retrieving data that resides locally.
• Remote Tables: These tables are not stored within your ServiceNow instance. Instead, they represent data that is accessed and retrieved from an external data source in real-time via a connection (e.g., JDBC or REST). When you query a remote table, ServiceNow makes a request to the external system to fetch the live data.

Use Case: Remote tables are useful when you need to display or interact with data from an external system (like an HR database or a CRM) without replicating it into ServiceNow. This ensures you’re always working with the most current information.

Answer: These describe how records in different tables relate to each other:

• One-to-Many Relationship: This is the most common type. It means one record in Table A can be related to many records in Table B, but each record in Table B can only be related to one record in Table A.
  • Example: Users and Incidents. One user (Table A) can have many incidents (Table B), but each incident is typically assigned to only one user (caller_id field). Here, the caller_id field in the incident table is a reference to the sys_user table.
• One-to-One Relationship: This is less common and often achieved using specific configurations. It means one record in Table A can only be related to one record in Table B, and vice versa.
  • Example: A user’s primary contact details might be stored in a separate table, linked via a unique reference field on both the user record and the contact details record.
• Many-to-Many Relationship: One record in Table A can relate to many records in Table B, AND one record in Table B can relate to many records in Table A. This is typically implemented using a junction table.
  • Example: Incidents and Groups. An incident can be assigned to multiple groups (e.g., for collaboration or different support tiers), and a group can be assigned to many incidents. The sys_user_group_member table is an example of a junction table, linking users and groups. For incidents and groups, you might use a custom many-to-many relationship table if an incident needs to be associated with multiple groups directly.

Interview Relevance: This question assesses your understanding of relational database concepts and how they are applied in ServiceNow’s data model.

Answer: ServiceNow provides multiple avenues for record creation:

1. Forms: The most direct way, by navigating to a table’s list and clicking ‘New’ or using a form associated with a parent record.
2. Record Producers: These are specialized forms that generate records in tables, often used for self-service scenarios (e.g., requesting a new laptop).
3. Email: By configuring inbound email actions, emails can trigger the creation of records (e.g., creating an incident from an email).
4. GlideRecord Scripting: Server-side scripts (in business rules, script includes, etc.) using new GlideRecord('tablename').insert().
5. Import Sets/Data Sources: Loading data from external files (Excel, CSV) or other systems.
6. Web Services/APIs: Programmatic creation via REST or SOAP integrations.
7. Workflows/Flow Designer: Automated record creation as part of a process.

Answer: There are several ways to control field visibility, mandatory status, and read-only properties:

• Dictionary Properties: Directly on the field’s dictionary entry, you can set ‘Mandatory’ or ‘Read only’ flags. These are generally static settings.
• Dictionary Overrides: To change the behavior of a field in a child table compared to its parent. You can override the mandatory or read-only status here.
• UI Policies: Client-side scripts that execute on form load or when conditions change. They can make fields mandatory, read-only, hidden, set values, or clear values based on conditions.
• Data Policies: Similar to UI Policies but designed to work on both client and server sides, enforcing data consistency regardless of how the record is accessed. They can also make fields mandatory or read-only.
• Client Scripts: Using g_form.setMandatory(), g_form.setReadOnly(), and g_form.setVisible() for dynamic client-side control.
• Business Rules: Server-side scripts that can set field values, including making them read-only or mandatory during record processing (less common for mandatory/read-only, more for setting values).

Best Practice: Use UI Policies for client-side interactions and Data Policies for server-side (and client-side) data integrity enforcement. Dictionary properties are for static, always-on behavior.

Answer: No, you should only designate one field as the ‘Display’ field in a table’s dictionary definition. The ‘Display’ field is used when a record is shown in a reference field’s lookup or autocomplete. If multiple fields are marked as display, it can lead to unpredictable behavior and confusion in reference lookups and related lists.

Example: For the sys_user table, ‘Name’ (which concatenates first and last names) is typically the display field. For incident, ‘Number’ is the display field.

Troubleshooting: If reference lookups are showing incorrect information or behaving strangely, check if multiple fields are marked as ‘Display’ on the target table.

Answer: All table definitions in ServiceNow are stored in the sys_db_object table. This table contains metadata about each table in the instance, including its name, label, extends, and other configuration details.

Answer: Default values can be set in several ways:

1. Dictionary Entry: On the field’s dictionary definition, there’s a ‘Default value’ field. You can enter a static value or a JavaScript snippet that evaluates to a value.
2. UI Policies: A UI Policy Action can be configured to set a specific value for a field when the policy’s conditions are met (often on load).
3. Data Policies: Similar to UI Policies, Data Policies can set default values.
4. Client Scripts: Using g_form.setDefaultValue('field_name', 'your_default_value');, usually within an OnLoad script.
5. Business Rules: For server-side default values (e.g., if a field should always be set to a certain value upon creation, and this logic needs to be guaranteed even without client-side interaction).

Example (Dictionary): For a ‘State’ field, you might set the default value to ‘1’ (Open).

Example (Script): gs.getUser().getDisplayName() to set the caller_id’s display name as default in certain contexts.

Answer: The current object is a server-side scripting object available in Business Rules, Script Includes (when called from a context that provides it), and other server-side operations. It represents the record that is currently being processed (e.g., the record being inserted, updated, or deleted).

Usage: You use current to read values from the record being processed or to set new values before the record is saved to the database.

Answer: You use the current object:

• current.setValue('field_name', value);
  • This is the standard method.
  • For reference fields, the value should be the Sys ID of the referenced record.
• current.setDisplayValue('field_name', value);
  • This method is useful for reference fields. You provide the display value (e.g., the user’s name) instead of the Sys ID, and ServiceNow will attempt to find the corresponding record.
  • Use this cautiously, as it relies on finding a unique match based on the display value, which can fail if there are duplicates or unexpected formats.

Example:

// Setting a string field
current.setValue('short_description', 'Issue resolved.');

// Setting a reference field (assuming 'caller_id' is a reference to sys_user)
current.setValue('caller_id', 'a1b2c3d4e5f6...'); // Sys ID of the user

// Setting a reference field using display value
current.setDisplayValue('caller_id', 'Abel Tuter'); // Display name of the user
            

Answer: Reference Qualifiers are used to filter the list of records that can be selected in a reference or list field. They ensure that users can only pick relevant records, improving data integrity and usability.

Types of Reference Qualifiers:

1. Simple Reference Qualifier:
   • Description: The most basic type. It uses a simple condition builder interface to define filter conditions. You specify fields, operators, and values to filter the referenced records.
   • Example: On an ‘Incident’ record, if the ‘Caller’ field (a reference to sys_user) should only show active users, you’d set a simple qualifier: active=true.
   • When to use: For straightforward filtering based on static conditions or conditions on the referenced table itself.
2. Dynamic Reference Qualifier:
   • Description: This type uses pre-defined ‘Dynamic Filter Options’ (configured under System Definition > Dynamic Filter Options). These options encapsulate dynamic query logic that can adapt based on context (e.g., the current user).
   • Example: Displaying only users who are members of the ‘IT Support’ group. You’d create a dynamic filter option for this.
   • How to use: You select a predefined dynamic filter option in the Reference Qualifier field.
   • When to use: When you need dynamic filtering based on contextual information without writing custom JavaScript for every instance.
3. Advanced Reference Qualifier (JavaScript Reference Qualifier):
   • Description: This type allows you to write custom JavaScript code directly in the Reference Qualifier field. This provides the most flexibility for complex filtering logic based on values from the current form, related records, or other dynamic conditions.
   • Example: On an Incident, filter the ‘Affected CI’ field to show only CIs that are in the same business service as the CI specified in another field on the form.

     javascript: 'business_service=' + current.cmdb_ci.business_service;

     Or to show users who are members of the same assignment group as the incident:

     javascript: 'sys_idIN' + gs.getUser().getGroups();

   • When to use: For complex, custom filtering logic that cannot be achieved with simple or dynamic qualifiers.

Differences Explained:

• Simple vs. Dynamic: Simple is static or based on fields on the referenced table. Dynamic uses pre-configured, reusable dynamic filter logic.
• Dynamic vs. Advanced: Dynamic uses pre-defined filters. Advanced lets you write custom JavaScript, offering much greater power and flexibility.
• Simple vs. Advanced: Simple is easy to configure via the UI builder. Advanced requires JavaScript knowledge but offers complete control.

Troubleshooting: If a reference field isn’t showing the expected records, check the reference qualifier configuration. For advanced qualifiers, ensure the JavaScript syntax is correct and that the variables (like current or gs) are available and returning the expected values.

Answer: Dependent values are used to create cascaded dropdowns. This means the choices available in one field (the dependent field) change based on the selection made in another field (the parent field).

How it works:

1. Parent Field: Typically a Choice or Reference field with multiple options.
2. Dependent Field: Another Choice or Reference field whose options will be filtered.
3. Configuration:
   • In the dictionary entry for the dependent field, set the ‘Dependent field‘ attribute to the name of the parent field (e.g., category).
   • For Choice fields, the choices themselves must be configured to link to the parent field’s values. When you add a choice for the dependent field, you’ll specify which parent choice it belongs to.

Example:

• Parent Field: Category (e.g., ‘Hardware’, ‘Software’, ‘Network’)
• Dependent Field: Subcategory (dependent on Category)
• If Category is ‘Hardware’, Subcategory options might be ‘Laptop’, ‘Desktop’, ‘Printer’.
• If Category is ‘Software’, Subcategory options might be ‘Operating System’, ‘Application’, ‘Database’.

Interview Relevance: This tests your understanding of user interface configuration and how to build intuitive forms.

Answer: A calculated value refers to a field whose value is determined dynamically by a script, rather than being manually entered or set via a simple default. This is configured using the ‘Calculated‘ field type or by using a Dictionary Attribute like ref_auto_cases or by referencing a script include.

More commonly, when you set a field to be calculated via its Dictionary Entry, you provide a JavaScript snippet that runs when the record is displayed or updated to compute the field’s value.

Example: A field named ‘Full Name’ might be calculated by concatenating ‘First Name’ and ‘Last Name’ using a script in its dictionary entry.

javascript: current.first_name + ' ' + current.last_name;

Note: While ‘calculated value’ can refer to script-driven calculations, the ‘Calculated’ field type is a specific field type in ServiceNow that uses a script to derive its value.

Answer: Attributes are used to modify the behavior or appearance of fields (dictionary entries) or tables (collection entries). They are essentially key-value pairs or just keys applied to a field’s definition.

Commonly Used Attributes:

• no_email: Prevents automatic notifications from being sent when this field changes.
• no_attachment: Disables the attachment icon for this field.
• tree_picker: Enables a hierarchical tree view for selection in reference fields.
• ref_auto_cases: Used for linking catalog items to cases.
• readonly: Makes a field read-only (similar to dictionary setting but can be applied via attributes).
• mandatory: Makes a field mandatory (similar to dictionary setting).
• ref_contributions=user_show_incidents: Shows related incidents for a user in a reference field dropdown.
• max_length=100: Sets a maximum character limit for a string field.

Where to apply: Attributes are applied in the ‘Attributes’ field of a field’s dictionary entry (or a table’s collection entry).

Answer: A ‘collection field’ is not a standard field type. When you see ‘collection’ in the context of a table, it usually refers to the table definition itself within the sys_db_object table. The entry for a table in sys_db_object is itself a record, and modifications made to its attributes or properties (like the ‘Read only’ checkbox or ‘Attributes’ field) affect the entire table, not a specific field.

Example: Attributes applied to the collection record for the incident table will apply to the incident table as a whole (e.g., disabling attachments for all incident records).

Answer: To control attachments for a specific table (i.e., on all forms for that table), you apply attributes to the collection record for that table in the sys_db_object table.

• To disable attachments: Add the attribute no_attachment to the ‘Attributes’ field of the table’s record in sys_db_object.
• To enable attachments: Ensure the no_attachment attribute is *not* present. By default, attachments are enabled unless restricted.

Note: This controls the global attachment capability for the table. Individual field attachments can be controlled by field-level attributes.

Answer: Dictionary overrides allow you to change the properties of a field in a child table without altering the parent table’s definition. This is crucial for customizing inherited fields to meet specific requirements of different child tables.

Properties that can be overridden:

• Mandatory: Make a field mandatory in a child table even if it’s not in the parent.
• Read only: Make a field read-only in a child table.
• Default value: Set a different default value.
• Max length: Change the maximum length of a string field.
• Attributes: Add or remove attributes.
• Display: (Caution: Generally only one display field per table hierarchy is best practice).
• Label: Change the visible label of the field.
• Help text: Update the help text.
• Choices: For Choice fields, you can add or remove specific choices.
• Reference Qualifiers: Apply different qualifiers.

How to use: Navigate to System Definition > Dictionary, then click ‘Dictionary Overrides’. Create a new record, specifying the parent table, the table you are overriding in (child table), and the field name. Then, modify the desired properties.

Example: The ‘Priority’ field on the base ‘Task’ table might have a default value of ‘4’. In the ‘Incident’ table, you could use a dictionary override to set the default priority to ‘3’.

Answer: Application Menus (also known as Modules) are used to organize and present ServiceNow functionalities (like forms, lists, dashboards, reports) to users in the navigation filter (left-hand menu). They act as entry points for users to access different parts of the application.

Structure: An application menu can contain several modules. A module defines how a specific item (like a list of incidents or a particular form) is displayed and accessed. Users navigate through applications and modules to find the information or functionality they need.

Example: Under the ‘Incident’ application, you might have modules for ‘Open Incidents’, ‘My Incidents’, ‘All Incidents’, ‘New Incident’.

Answer: Process flow (or Flow Designer, or older Workflow visualizers) is a visual representation that shows the steps or stages a record goes through in a specific process. It helps users understand where a record is in its lifecycle and what the next expected steps are.

Example: In an Incident, a process flow might visually depict stages like ‘New’, ‘In Progress’, ‘On Hold’, ‘Resolved’, ‘Closed’. On a Change Request, it could show ‘New’, ‘Assess’, ‘Authorize’, ‘Scheduled’, ‘Implement’, ‘Review’, ‘Closed Complete’.

Benefits: Improves transparency, helps users understand process expectations, and can guide users through complex workflows.

Answer: Data lookup rules are used to automatically populate field values on a form based on the values entered into other fields on the same form. They are typically configured using a specific table (often sys_data_lookup) and provide a mechanism to create dynamic data population without extensive scripting.

How it works: You define rules that specify:

• Source Table: The table containing the lookup data.
• Lookup Fields: Fields on the source table used for matching.
• Target Table: The table where the record is being created/updated.
• Target Fields: Fields on the target table to populate.
• Conditions: When the lookup should occur.

Example: If a user selects a ‘Department’ on a form, a data lookup rule could automatically populate the ‘Location’ field based on the department’s predefined location. This is a more structured alternative to simple default values or client scripts for certain lookup scenarios.

Answer: UI Policies are client-side scripts that dynamically change the form’s appearance and behavior based on conditions. They are a user-friendly alternative to client scripts for common tasks like making fields mandatory, read-only, visible, or hidden, and setting field values.

Key Capabilities:

• Make fields mandatory, read-only, or visible/hidden.
• Set field values.
• Clear field values.
• Execute client scripts (optional, via UI Policy Actions).

Execution: They run on the client (browser) when a form loads or when field values change. They do NOT run on the server.

Answer: The ‘Global’ checkbox in a UI Policy determines whether the policy applies to all views or only to specific views.

• Checked: The UI Policy will apply to all views of the table.
• Unchecked: You will be prompted to select specific views to which the UI Policy should apply. This is useful for tailoring UI behavior for different user contexts or purposes.

Example: A UI Policy making a field read-only might be global, or it might only apply to the ‘Self-Service’ view if it’s not relevant for fulfillers.

Answer: ‘Reverse if false’ is a crucial setting in UI Policies. When checked, it means that if the UI Policy’s conditions evaluate to false, the actions defined in the UI Policy will be reversed.

Example:

• UI Policy Condition: State is 'In Progress'
• UI Policy Action: Make ‘Assignment Group’ mandatory.
• If ‘Reverse if false’ is checked:
• When ‘State’ is ‘In Progress’ (condition TRUE), ‘Assignment Group’ becomes mandatory.
• When ‘State’ is NOT ‘In Progress’ (condition FALSE), the ‘Assignment Group’ will revert to its original state (e.g., if it was optional, it becomes optional again; if it was mandatory due to another rule, it might remain mandatory, but this action is reversed).
• If ‘Reverse if false’ is unchecked:
• When ‘State’ is ‘In Progress’, ‘Assignment Group’ becomes mandatory.
• When ‘State’ is NOT ‘In Progress’, the ‘Assignment Group’ remains as it was set by the UI Policy action (i.e., it stays mandatory, potentially overriding other rules, or remains in its last state).

Best Practice: Generally, you want ‘Reverse if false’ checked for most UI Policies to ensure that actions are correctly applied and then undone when conditions change, maintaining a consistent UI state.

Answer: The ‘On Load’ checkbox determines whether the UI Policy’s conditions and actions are evaluated and applied when the form initially loads.

• Checked: The UI Policy runs as soon as the form is loaded. This is common for setting initial states, default values, or mandatory/read-only properties when the form first appears.
• Unchecked: The UI Policy will NOT run on form load. It will only execute when a field value changes that triggers the UI Policy’s conditions. This is useful for dynamic behavior that reacts to user input after the form has loaded.

Example: A UI Policy that makes a field visible only if another field has a specific value should have ‘On Load’ checked to ensure the field appears or is hidden correctly from the start. A UI Policy that makes a field read-only when a checkbox is ticked would likely have ‘On Load’ unchecked, or its condition would handle the initial state appropriately.

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

• Checked: The UI Policy will be inherited by all child tables. For example, if a UI Policy is on the ‘Task’ table and ‘Inherit’ is checked, it will also apply to ‘Incident’, ‘Problem’, and ‘Change Request’ tables.
• Unchecked: The UI Policy will only apply to the table it is defined on.

Caution: Use this carefully. Inheriting UI Policies can lead to unintended consequences on child tables if the logic isn’t universally applicable. It’s often better to create specific UI Policies for child tables or use dictionary overrides for field-level variations.

Answer: Yes, you can execute scripts within UI Policies. This is done through UI Policy Actions.

How:

1. Create a UI Policy with its conditions.
2. Create UI Policy Actions to define what happens when the conditions are met.
3. In a UI Policy Action, there is a checkbox labeled ‘Run script‘. Check this box.
4. This will reveal a ‘Script‘ field where you can write client-side JavaScript.

Use Cases: Executing custom client-side logic, calling Script Includes, manipulating DOM elements (though generally discouraged), or performing complex field manipulations not covered by standard actions.

Example: You might write a script to dynamically set the value of one field based on a calculation involving multiple other fields, or to dynamically add options to a choice list.

Answer: Yes, ServiceNow provides a convenient feature to convert a UI Policy into a Data Policy.

How: Open the UI Policy record. There is typically a related link or button that says “Convert to Data Policy” or similar. Clicking this will create a corresponding Data Policy with similar conditions and actions.

Answer: While the conversion feature is helpful, not all UI Policy functionalities can be directly translated into Data Policies. The following are cases where direct conversion might not be possible or may require manual adjustments:

• Controlling Data Visibility (e.g., hiding fields): Data Policies are primarily for enforcing data integrity (mandatory, read-only) and do not directly control UI visibility. Hiding fields is a UI concern.
• Controlling Views: UI Policies can be configured to apply to specific views. Data Policies are not view-specific.
• Controlling Related Lists: UI Policies can sometimes dynamically show/hide related lists. Data Policies do not interact with related list visibility.
• Executing Complex Client-Side Scripts: If a UI Policy relies heavily on complex, client-specific JavaScript (e.g., DOM manipulation, advanced client-side interactions), this logic might not have a direct server-side equivalent or might need significant re-architecture for a Data Policy.
• Dynamic Field Value Setting (where the value depends on complex client-side logic): While Data Policies can set values, if the logic for determining that value is purely client-side and intricate, it might be difficult to replicate server-side.

Recommendation: Always review the converted Data Policy to ensure all intended behavior is preserved and adjust as necessary.

Answer: Data Policies are ServiceNow features used to enforce data consistency and integrity across all data sources (client-side and server-side). They are similar to UI Policies in that they use conditions to apply actions, but they operate independently of the user interface.

Key Capabilities:

• Make fields mandatory.
• Make fields read-only.
• Set default values.

Execution: Data Policies can be configured to run on the client (similar to UI Policies) or on the server, or both. This ensures that data rules are enforced regardless of how the record is accessed (e.g., via form, import, API call, or email).

When to use: Use Data Policies when you need to enforce data rules that must apply universally, not just on a specific form view. They are excellent for ensuring data quality and security.