Mastering ServiceNow Request Management: Top 20 Interview Questions & Answers

Navigating the world of ServiceNow can be a thrilling journey, especially when it comes to Request Management. As organizations increasingly rely on this powerful platform to streamline IT service delivery, professionals with a solid understanding of ServiceNow Request Management are in high demand. If you’re preparing for an interview in this space, you’re in the right place. This article dives deep into some of the most frequently asked questions, providing detailed, human-like explanations that go beyond just rote memorization.

We’ll explore not only the ‘what’ but also the ‘why’ and ‘how,’ equipping you with the knowledge to confidently articulate your expertise during your next interview. Let’s get started on building your ServiceNow Request Management prowess!

Understanding Your ServiceNow Landscape

Before we dive into specific functionalities, interviewers often want to gauge your current experience and familiarity with the platform’s evolution. This helps them understand your practical exposure and adaptability.

1. Which is the current version you are working on in ServiceNow?

Answer: “I’m currently working on the Washington DC release. It’s been a great experience leveraging the latest features and enhancements this version offers.”

2. From which version you started working?

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

User and Group Management: The Foundation of Access

Access control is paramount in any system. Understanding how users and groups are managed, and how permissions are assigned, is fundamental to ServiceNow administration and development.

3. Can we add permissions to users and groups? Which is the best practice?

Answer: “Absolutely. In ServiceNow, permissions are primarily managed through roles. We can assign roles directly to individual users or to groups. The best practice is to assign roles to groups. Here’s why: When an employee joins, you add them to the relevant groups, and they automatically inherit all the necessary roles. Conversely, when an employee leaves, you simply remove them from the group, and all their inherited roles are automatically revoked. This significantly simplifies user lifecycle management and reduces the risk of orphaned permissions.”

You can achieve this both manually through the UI and programmatically using scripts with GlideRecord.

4. What is the user table name?

Answer: The user table in ServiceNow is named sys_user.

5. What is the group member table name?

Answer: The table that links users to groups, essentially the group membership table, is named sys_user_grmember.

6. How to create a user account using script?

Answer: You can create a new user account programmatically using a GlideRecord object targeting the sys_user table. Here’s a basic example:

    var userGr = new GlideRecord('sys_user');
    userGr.initialize(); // Prepares a new record
    userGr.username = 'jdoe'; // Set the username
    userGr.firstname = 'John'; // Set the first name
    userGr.lastName = 'Doe'; // Set the last name
    userGr.email = 'jdoe@example.com'; // Set the email address
    // You would typically set a password here as well, often encrypted or handled via specific user creation processes
    userGr.insert(); // Inserts the new record into the sys_user table
    gs.info('User ' + userGr.username + ' created successfully.');
    

7. How to create a group using script?

Answer: Similarly, you can create a new group using GlideRecord on the sys_user_group table:

    var newGr = new GlideRecord('sys_user_group');
    newGr.initialize(); // Prepares a new record
    newGr.name = 'IT Service Desk'; // Set the group name
    // Assigning a manager - you'll need the sys_id of the user who is the manager
    newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Replace with actual sys_id
    newGr.email = 'itservicedesk@example.com'; // Set the group email
    newGr.description = 'Handles all incoming IT service requests and incidents.'; // Set a description
    newGr.insert(); // Inserts the new group record
    gs.info('Group ' + newGr.name + ' created successfully.');
    

8. How to add permissions to a user/group account using script?

Answer: Permissions (roles) are managed via specific relationship tables.

• To a User: When you assign a role to a user, a record is created in the sys_user_has_role table.
• To a Group: When you assign a role to a group, a record is created in the sys_group_has_role table.

Here’s how you can do it with GlideRecord:

    // --- Add a role to a User ---
    var userRole = new GlideRecord('sys_user_has_role');
    userRole.initialize();
    // Set the sys_id of the user and the role you want to assign
    userRole.setValue('user', '62826bf03710200044e0bfc8bcbe5df1'); // Replace with actual user sys_id
    userRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Replace with actual role sys_id
    userRole.insert();
    gs.info('Role assigned to user.');

    // --- Add a role to a Group ---
    var grpRole = new GlideRecord('sys_group_has_role');
    grpRole.initialize();
    // Set the sys_id of the group and the role you want to assign
    grpRole.setValue('group', '477a05d153013010b846ddeeff7b1225'); // Replace with actual group sys_id
    grpRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Replace with actual role sys_id
    grpRole.insert();
    gs.info('Role assigned to group.');
    

9. What exactly does user delegation mean in ServiceNow?

Answer: User delegation in ServiceNow allows one user to perform tasks on behalf of another user within the organization. This is incredibly useful when a primary user is unavailable, such as during vacations, leave, or extended absences. The delegated user gains access to perform actions and access resources that would normally be available only to the original user, ensuring business continuity.

For example, if an employee is going on vacation, they can delegate their approval tasks to a colleague. This ensures that important workflow approvals continue without interruption. To set this up, you navigate to the original user’s account, scroll down to the ‘Delegates’ related list, and then specify the delegate’s name, the start and end dates of the delegation, and the types of permissions they should have (e.g., assignments, notifications, approvals).

10. How to add and remove a group member from a group using script?

Answer: You can manage group memberships using the sys_user_grmember table:

    // --- Adding a Group Member ---
    var grMemAdd = new GlideRecord('sys_user_grmember');
    grMemAdd.initialize();
    grMemAdd.user = '62826bf03710200044e0bfc8bcbe5df1'; // sys_id of the user to add
    grMemAdd.group = '477a05d153013010b846ddeeff7b1225'; // sys_id of the group
    grMemAdd.insert();
    gs.info('User added to group.');

    // --- Removing a Group Member ---
    var grMemRemove = new GlideRecord('sys_user_grmember');
    grMemRemove.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1'); // sys_id of the user to remove
    grMemRemove.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // sys_id of the group
    grMemRemove.query();
    if (grMemRemove.next()) {
        grMemRemove.deleteRecord(); // Deletes the membership record
        gs.info('User removed from group.');
    }
    

Exploring ServiceNow Interfaces and User Authentication

ServiceNow offers various ways for users to interact with the platform. Understanding these interfaces and how users authenticate is key to designing user-friendly experiences.

11. How many user interfaces are there in ServiceNow?

Answer: ServiceNow has evolved its user interfaces over time. Historically, we had UI15 and UI16. Currently, the platform is moving towards the Next Experience UI (formerly known as the Now Experience UI). So, you can say UI16 is the classic interface, and Next Experience is the modern, forward-looking one.

12. What is meant by a web services user in a User account?

Answer: A web services user is an account specifically designed to allow third-party applications or integrations to connect to ServiceNow programmatically, typically via REST or SOAP APIs. These users are not intended for interactive login; they cannot log into the ServiceNow GUI like a regular end-user. They are provisioned with specific credentials and permissions to perform automated tasks, data exchange, or system integrations.

13. How to get the current logged-in user’s system ID on the client side?

Answer: On the client-side (e.g., within client scripts, UI policies, or UI actions that run on the client), you can access the current user’s sys_id using the global variable g_user.userID.

14. How to get the current logged-in user’s system ID on the server side?

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

15. How to check if the current logged-in user is a member of a particular group or not?

Answer: On the server-side, you can use the gs.getUser().isMemberOf('group name'); method. This method returns true if the current user is a member of the specified group and false otherwise. It’s a very convenient way to enforce role-based access or conditional logic.

    if (gs.getUser().isMemberOf('ITIL Users')) {
        gs.info('User is part of the ITIL Users group.');
    } else {
        gs.info('User is not part of the ITIL Users group.');
    }
    

ServiceNow Incident, Problem, and Change Management Fundamentals

While this article focuses on Request Management, it’s crucial to understand its interconnectedness with other core ITIL processes like Incident, Problem, and Change Management. Interviewers often ask about these to gauge your broader IT Service Management (ITSM) knowledge.

16. Which role is required to work on access control?

Answer: To manage and create Access Control Lists (ACLs), you need the security_admin role. This role has extensive privileges and should be assigned judiciously.

17. What is impersonation?

Answer: Impersonation in ServiceNow is a powerful feature that allows an administrator or a user with the appropriate role (like impersonator) to temporarily “act as” another user. This is invaluable for testing user experiences, troubleshooting issues from a specific user’s perspective, and verifying permissions without needing to log out and back in with different credentials. You can impersonate from the user profile or the application navigator.

18. What is user preference?

Answer: User preferences allow individual users to customize certain aspects of their ServiceNow interface and experience, such as list column layouts, form banner images, or notification settings. These preferences are specific to the user making them and do not affect other users or global system settings. They are stored in the sys_user_preference table.

19. What is an incident?

Answer: An incident is an unplanned interruption to an IT service or a reduction in the quality of an IT service. For example, if a user’s email client suddenly stops working, that’s an incident. The primary goal of incident management is to restore normal service operation as quickly as possible with minimum adverse impact on business operations.

20. What is a problem?

Answer: A problem, in ITIL terms, is the underlying cause of one or more incidents. If the same incident occurs repeatedly for the same user, or if multiple users report similar issues, it suggests an underlying problem. Problem management aims to identify the root cause of these recurring incidents and provide a workaround or a permanent solution to prevent them from happening again. If the same issue affects multiple people simultaneously, it’s often initially logged as an incident, and a problem record might be created to track and resolve the root cause. In such cases, one incident might be designated as the ‘parent’ incident, with others linked as ‘child’ incidents.

21. Can we create a problem record from an incident?

Answer: Yes, absolutely. If during the resolution of an incident, it becomes apparent that the issue is recurring or has a deeper underlying cause that needs investigation, you can create a new Problem record directly from the incident form. This is a standard practice to escalate the investigation and ensure the root cause is addressed.

22. Can we create a change request from an incident?

Answer: Yes. If resolving an incident requires a modification to the IT infrastructure or applications – for instance, patching a system, upgrading software, or reconfiguring a network device – a Change Request can be initiated from the incident. This ensures that any changes made to the production environment are properly planned, approved, and executed.

23. How to create an incident record using script?

Answer: You can create an incident using GlideRecord on the incident table:

    var gr = new GlideRecord('incident');
    gr.initialize(); // Prepare a new incident record
    gr.caller_id = '86826bf03710200044e0bfc8bc05d94'; // Sys_id of the user reporting the issue
    gr.category = 'inquiry'; // Incident category
    gr.subcategory = 'antivirus'; // Incident subcategory
    gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Affected Configuration Item (CI) sys_id
    gr.short_description = 'User unable to access shared drive.'; // Concise summary of the issue
    gr.description = 'User reports receiving an access denied error when trying to connect to the \\\\fileserver\\share drive.'; // Detailed description
    gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys_id of the assignment group
    gr.insert(); // Save the new incident record
    gs.info('Incident ' + gr.number + ' created successfully.');
    

24. How to create a problem record using script?

Answer: Similar to incidents, you use GlideRecord on the problem table:

    var gr = new GlideRecord('problem');
    gr.initialize();
    gr.caller_id = '86826bf03710200044e0bfc8bc05d94'; // Reporter
    gr.category = 'network';
    gr.subcategory = 'connectivity';
    gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Affected CI
    gr.short_description = 'Intermittent network connectivity issues on Floor 3.';
    gr.description = 'Multiple users on Floor 3 are experiencing intermittent network connectivity loss throughout the day. This is causing disruption to productivity.';
    gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Assignment group for investigation
    gr.insert();
    gs.info('Problem ' + gr.number + ' created successfully.');
    

25. How to create a change request using script?

Answer: For change requests, you target the change_request table:

    var gr = new GlideRecord('change_request');
    gr.initialize();
    gr.category = 'standard'; // Or 'normal', 'emergency'
    gr.subcategory = 'application';
    gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // CI being changed
    gr.short_description = 'Upgrade Apache Web Server to latest stable version.';
    gr.description = 'Upgrade the Apache web server on production servers (DEV, QA, PROD) to version 2.4.58 to patch security vulnerabilities and improve performance.';
    gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Assignment group for change implementation
    // Additional fields like planned_start_date, planned_end_date, risk, impact, etc., would typically be set here.
    gr.insert();
    gs.info('Change Request ' + gr.number + ' created successfully.');
    

Automating Workflows with Business Rules

Business Rules are the backbone of automation in ServiceNow. They allow you to execute server-side scripts based on specific conditions, making your platform dynamic and responsive. Here’s how they can be used to enforce process integrity.

26. Write a logic for whenever a parent incident is closed, all the child incidents should also be closed.

Answer: This is a classic use case for an “After” business rule on the incident table. The rule should trigger when the incident state changes to ‘Closed’ and ensure it’s a parent incident (i.e., the ‘parent’ field is empty).

    // Business Rule: Auto-close Child Incidents
    // Table: Incident
    // When: After Update
    // Condition: current.state.changesTo(7) && current.parent == '' // Assuming state 7 is 'Closed'

    if (current.state == 7) { // Ensure it's actually closed
        // GlideRecord to find child incidents associated with this parent
        var grChild = new GlideRecord('incident');
        grChild.addQuery('parent', current.sys_id); // Query for incidents where 'parent' field matches this incident's sys_id
        grChild.query();
        while (grChild.next()) {
            // Only update if the child is not already closed
            if (grChild.state != 7) {
                grChild.state = 7; // Set the state to Closed
                grChild.update(); // Update the child incident record
                gs.info('Child incident ' + grChild.number + ' auto-closed due to parent closure.');
            }
        }
    }
    

27. There is an incident, and it has associated 2 tasks. When you try to close that incident, if any incident task is open, the employee should not be able to close the incident. Similarly for problem, and change request.

Answer: This requires a “Before” business rule or an “OnBefore” business rule on the incident table (and similar rules for problem and change_request). A “Before” rule is best because it aborts the update before it’s committed.

    // Business Rule: Prevent Closing with Open Tasks
    // Table: Incident
    // When: Before Update
    // Condition: current.state.changesTo(7) // Assuming state 7 is 'Closed'

    if (current.state == 7) { // If the user is trying to close the incident
        var grTask = new GlideRecord('incident_task');
        grTask.addQuery('incident', current.sys_id); // Find incident tasks related to this incident
        // Check for open tasks. Assuming state '3' means 'Closed'. Adjust if your 'Closed' state value is different.
        grTask.addQuery('state', '!=', 3);
        grTask.query();

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

    // You would create similar business rules for 'problem' and 'change_request' tables,
    // referencing their respective task tables (e.g., 'problem_task', 'change_task').
    

28. Whenever a problem is closed, the associated incident will also get closed.

Answer: This is another “After” business rule on the problem table. It’s similar to auto-closing child incidents but targets associated incidents.

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

    if (current.state == 7) { // If the problem is being closed
        // GlideRecord to find incidents associated with this problem
        var grIncident = new GlideRecord('incident');
        grIncident.addQuery('problem_id', current.sys_id); // Link incident to the problem record
        grIncident.addQuery('state', '!=', 7); // Ensure the incident is not already closed
        grIncident.query();
        while (grIncident.next()) {
            grIncident.state = 7; // Set the incident state to Closed
            grIncident.update(); // Update the incident record
            gs.info('Incident ' + grIncident.number + ' auto-closed due to problem closure.');
        }
    }
    

29. What is the relationship between incident, problem, and change management?

Answer: These three processes are highly interconnected within ITSM, forming a cycle of service restoration and improvement:

• Incident Management: Focuses on restoring service as quickly as possible when it’s disrupted. It’s the first point of contact for end-users reporting issues.
• Problem Management: Investigates the root cause of recurring or significant incidents. Its goal is to prevent future incidents by finding workarounds or permanent fixes. A problem can be identified from one or more incidents.
• Change Management: Manages the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services. If problem management identifies that a change to the IT environment is needed to resolve a problem (or even to prevent future incidents), a change request is created. Incidents can also trigger change requests if a fix requires a modification to the system.

Think of it this way: An incident is a fire. Problem management figures out why the fire started (e.g., faulty wiring) and how to prevent it from happening again. Change management is about safely fixing that faulty wiring.

ServiceNow Table and Field Concepts

A deep understanding of ServiceNow’s data model is essential. This section covers fundamental concepts around tables, fields, and their behavior.

30. Give me some names of out-of-the-box tables?

Answer: Out-of-the-box (OOTB) tables are those provided by ServiceNow and do not start with a custom application prefix like x_ or u_. Examples include:

• incident
• problem
• change_request
• sc_req_item (Requested Item)
• sc_cat_item (Catalog Item)
• sys_user
• sys_group
• cmdb_ci (Configuration Item base table)
• task (A base table for many task-derived tables)

31. What are some of the base tables?

Answer: Base tables are tables that are not extended by any other table but are extended by many other tables. They serve as fundamental building blocks. Common examples include:

• task: This is a core base table extended by incident, problem, change_request, sc_task, etc. It provides common fields like short description, description, state, assignment group, assigned to, etc.
• cmdb_ci: This is the base table for all Configuration Items in the CMDB. All specific CI classes (like cmdb_ci_computer, cmdb_ci_application) extend from it.
• cmdb: The top-level table for the CMDB.

32. Give me some examples of task tables?

Answer: As mentioned, tables that extend the task base table are considered task tables. These are records that typically involve work to be done. Examples include:

• incident
• problem
• change_request
• sc_task (Service Catalog Task)
• vtb_task (Virtual Task Board Task)

33. Whenever we create a table, how many access controls will get created?

Answer: By default, when you create a new table in ServiceNow and the “Create application/module” and “Create ACLs” checkboxes are selected in the table creation wizard, ServiceNow automatically generates four Access Control Lists (ACLs) for that table:

• .* (Create)
• .* (Read)
• .* (Write)
• .* (Delete)

These ACLs grant basic Create, Read, Write, and Delete permissions to users with roles like admin and potentially other specific application roles depending on the context. If you uncheck the “Create ACLs” option, these will not be automatically generated.

34. How to create a number field, like incident number?

Answer: To create an auto-numbering field, similar to the incident.number, you define it in the table’s dictionary entry. When creating or editing a field, you select the ‘Number’ field type. Then, under the ‘Control’ tab of the field’s dictionary record, you configure:

• Prefix: The starting characters for the number (e.g., ‘INC’ for incidents).
• Number of digits: How many digits the sequence should have (e.g., 7 for 0000001).
• You also check the ‘Auto-number’ checkbox.

ServiceNow then automatically manages the incrementing of these numbers.

35. What happens when you extend a table?

Answer: When you extend a table (e.g., creating the incident table by extending the task table), the child table (incident) inherits all the fields from its parent table (task). This means you don’t need to redefine common fields like ‘short_description’ or ‘state’ on the child table. Instead, these fields are managed at the parent level. A special field called CLASS is created in the parent table to store the actual type of record (e.g., ‘incident’, ‘problem’, ‘change_request’). This allows ServiceNow to effectively manage records that have inherited fields and behaviors from their respective parent tables.

36. Can you give me 10 field types?

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

1. String: For text input (single line).
2. Reference: Links to another record in a different table (e.g., User, Group, CI).
3. Choice: A dropdown list of predefined options.
4. Date/Time: For selecting a date and time.
5. Date: For selecting only a date.
6. Boolean: A true/false checkbox.
7. Integer: For whole numbers.
8. Journal: A field that records a history of entries, often used for work notes or comments.
9. Attachment: Allows users to attach files to a record.
10. List: Allows selection of multiple records from another table.
11. Email: Formatted for email addresses.

37. What is the difference between a temporary and a normal table?

Answer:

• Normal Tables: Store data permanently. These are your standard tables like incident, user, etc., where data persists until explicitly deleted or archived.
• Temporary Tables: These tables are designed for short-term data storage. They typically extend the import_set_row table and are automatically purged after a set period (often 7 days) to manage database space. They are commonly used for staging data during import processes before it’s transformed and loaded into permanent tables.

38. Can we increase the retention period in a temp table?

Answer: Yes, you can increase the retention period for temporary tables. This is typically managed through Archive Rules. You can configure archive rules to define how long data should be retained before being moved to an archive table or purged. While temp tables have a default lifecycle, archive rules provide a more granular way to manage data retention policies for tables, including those that might otherwise be auto-purged.

39. What is the difference between a remote table and normal tables?

Answer:

• Normal Tables: Data is stored directly within your ServiceNow instance’s database.
• Remote Tables: These are tables whose data resides on an external system (like another database or an external application) but are made accessible and appear as if they are part of your ServiceNow instance. ServiceNow connects to the remote data source in real-time to retrieve the data. This is often achieved using technologies like JDBC, REST, or SOAP integrations, where ServiceNow queries the external system directly to display or interact with the data. The key difference is where the data physically resides and how it’s accessed.

40. What is one-to-one and one-to-many table relationship in ServiceNow?

Answer:

• One-to-Many Relationship: This is the most common type. It means one record in Table A can be related to multiple records in Table B, but each record in Table B is related to only one record in Table A.
  
  Example: A User (Table A) can have many Incidents (Table B). Each incident is assigned to only one user. Here, the incident table would have a reference field pointing to the sys_user table.
• One-to-One Relationship: This is less common and is usually achieved by extending a table. One record in Table A relates to exactly one record in Table B, and vice-versa.
  
  Example: A User Profile table could be a one-to-one extension of the sys_user table. Each user has exactly one profile, and each profile belongs to exactly one user.
• Many-to-Many Relationship: One record in Table A can relate to multiple records in Table B, AND one record in Table B can relate to multiple records in Table A. This is typically implemented using a “many-to-many” or “join” table.
  
  Example: Incidents and Groups. An incident can be assigned to multiple groups (e.g., for different aspects of its resolution), and a group can be assigned multiple incidents. The sys_group_has_role and sys_user_grmember tables are examples of join tables creating many-to-many relationships.

Record Creation and Field Manipulation

ServiceNow offers a rich set of tools for creating and managing records, and for controlling how users interact with fields.

41. In how many ways can we create a record in a ServiceNow table?

Answer: You can create records in a ServiceNow table in several ways:

• Using the UI Form: The most direct way for end-users and administrators.
• Using Record Producers: Service Catalog items that create records in backend tables (e.g., creating an incident from a catalog item).
• Via Email: Configuring inbound email actions to create records based on incoming emails.
• Using GlideRecord Scripting: Programmatically creating records via server-side scripts (Business Rules, Script Includes, etc.).
• Importing from Excel/CSV: Using the “Load Data” or “Import Sets” functionality.
• From External Systems: Via web services (SOAP/REST APIs).
• Using UI Actions: Custom buttons or links can trigger record creation.

42. In how many ways can we make a field mandatory or read-only?

Answer: You can control field mandatory and read-only properties in several ways:

• Dictionary Properties: Directly on the field’s dictionary entry (mandatory and readonly attributes).
• Dictionary Overrides: To modify these properties for a specific child table.
• UI Policies: Client-side logic to dynamically set mandatory, read-only, or visibility based on conditions.
• Data Policies: Server-side logic (and client-side enforcement) to enforce mandatory or read-only states.
• Client Scripts: Using g_form.setMandatory('field_name', true/false); or g_form.setReadOnly('field_name', true/false);.
• ACLs (Access Controls): Can enforce read/write access at a fundamental level.

43. Can we make 2 fields display in one table?

Answer: No, you should not make more than one field as ‘Display’ in a single table. The ‘Display’ attribute on a field is intended to identify the primary, human-readable identifier for a record. It’s used in reference fields and lookups to present a meaningful name to the user. Having multiple display fields would lead to ambiguity and confusion when ServiceNow tries to determine which field to use for display purposes in reference lookups or list views.

44. All tables will be stored where?

Answer: Information about all tables in ServiceNow, including their definitions, fields, and configurations, is stored in the sys_db_object table. This is a meta-table that describes the database schema itself.

45. How to set a default value on a field?

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

• Dictionary Entry: Directly in the field’s dictionary record, there’s a ‘Default value’ field. This value is populated when a new record is created if no other value is explicitly set.
• UI Policies: You can set default values as part of a UI Policy action.
• Client Scripts (OnLoad): Using g_form.setDefaultValue('field_name', 'your_value'); in an OnLoad client script.
• Business Rules (Before Insert): Using current.field_name = 'your_value'; in a before insert business rule.

46. What is the current object?

Answer: The current object is a fundamental server-side scripting object in ServiceNow. It represents the record that is currently being processed by the script. For example, in a business rule that runs on an incident update, current refers to the incident record being updated. You use current to get and set values on that specific record.

47. How to set the field values on the current form?

Answer: On the server-side, you use methods of the current object:

• current.setValue('field_name', value);: This is the primary method to set a field’s value. For reference fields, you provide the sys_id of the referenced record as the value.
• current.setDisplayValue('field_name', value);: This method is useful for reference fields. Instead of providing the sys_id, you provide the display value (e.g., the username for a user reference field). ServiceNow will then find the corresponding sys_id and set the field. This can be more readable in scripts.

    // Setting a string field
    current.setValue('short_description', 'This is a test incident.');

    // Setting a reference field (e.g., assigning to a user)
    current.setValue('assigned_to', '62826bf03710200044e0bfc8bcbe5df1'); // Provide sys_id

    // Setting a reference field using display value
    current.setDisplayValue('assigned_to', 'Abel Tutor'); // Provide the display name
    

Reference Qualifiers and Data Relationships

Controlling the data users see in reference and list fields is critical for usability and data integrity. Reference qualifiers are key to this.

48. What is a reference qualifier, and what are its types? Explain each one in detail and the difference between simple and dynamic, dynamic and advanced, simple and advanced.

Answer: Reference Qualifiers are used to filter the records that appear in a reference field (or a list field, which is a multi-select reference field). They act like WHERE clauses for reference fields, ensuring users can only select relevant records. This significantly improves usability and data accuracy.

There are three primary types of Reference Qualifiers:

Simple Reference Qualifier:

Description: This is the most straightforward type, allowing you to define a static query using field conditions directly within the reference field’s dictionary entry. It’s good for filters that don’t change based on the current form’s context.

How to Use: In the dictionary entry for the reference field, you’ll find a “Reference qualifier” field. You select “Simple” and then build your condition (e.g., active=true^department=IT).

Example: If you have a reference field to the ‘User’ table and you only want to show active users from the ‘IT’ department, your simple reference qualifier would be active=true^department=IT.

Dynamic Reference Qualifier:

Description: This type uses a dynamic filter option that you configure separately. These options allow for more flexible filtering that can be context-aware, but they are pre-defined. A dynamic filter option is essentially a saved query that can be reused across multiple reference fields.

How to Use: You first create a “Dynamic Filter Option” under System Definition > Dynamic Filter Options. You define the conditions there. Then, in the reference field’s dictionary entry, you select “Dynamic” for the reference qualifier and choose your pre-configured dynamic filter option.

Example: You could create a dynamic filter option to show “Users in Current Assignment Group.” Then, you’d select this option for a reference field to the ‘User’ table. When the form loads, the qualifier would dynamically resolve to filter users belonging to the same group as the record’s assignment group.

Advanced Reference Qualifier (JavaScript Reference Qualifier):

Description: This is the most powerful and flexible option, allowing you to write custom JavaScript code to define complex filtering logic. This is ideal when the filtering criteria depend heavily on the current form’s values, user context, or complex calculations.

How to Use: In the reference field’s dictionary entry, you select “Advanced” for the reference qualifier and then enter your JavaScript code in the adjacent field. The script should return a query string. You can use client-side GlideForm API methods if the qualifier runs on the client, or server-side GlideRecord queries if it runs on the server.

Example: To show only incidents assigned to the current user that are still open:

    javascript: 'assigned_to=' + g_user.userID + '^state!=7'; // For client-side
    

Or a server-side equivalent could be more complex.

Differences Explained:

• Simple vs. Dynamic: Simple is static and defined directly on the field. Dynamic uses pre-configured “Dynamic Filter Options” which can be reused, offering better manageability for common, reusable filters.
• Dynamic vs. Advanced: Dynamic uses pre-defined filter options, which are good for common scenarios. Advanced allows custom JavaScript for highly specific, complex, or context-driven filtering that cannot be achieved with predefined options.
• Simple vs. Advanced: Simple is for basic, static field-value filtering. Advanced is for complex, dynamic logic that requires scripting to determine the filter criteria.

49. What is dependent value?

Answer: Dependent Values (often referred to as “Dependent Fields” in the dictionary) are used to create cascaded dropdowns. When you select a value in one field (the parent field), the available choices in another field (the dependent field) are filtered to show only relevant options. This is a common UI pattern used in Service Catalog, forms, and lists to guide users to make correct selections.

Steps to Configure:

1. Identify Parent and Dependent Fields: For example, Category (parent) and Subcategory (dependent).
2. Configure the Parent Field: Ensure the parent field has a set of choices (e.g., Category: Hardware, Software, Network).
3. Configure the Dependent Field: Go to the dictionary entry of the dependent field (Subcategory). In the ‘Attributes’ field, add dependent="parent_field_name" (e.g., dependent="category"). Then, within the ‘Choice List Specification’ for the dependent field, define choices and link them to the specific parent field values.

Example:

• Category (Parent): Hardware, Software, Network
• Subcategory (Dependent):
  • If Category = Hardware: Laptop, Desktop, Printer
  • If Category = Software: Operating System, Application, Database
  • If Category = Network: Router, Switch, Firewall

When a user selects “Hardware” for Category, the Subcategory dropdown will only show Laptop, Desktop, and Printer.

50. What is a calculated value?

Answer: A Calculated Value, defined in the Dictionary Property for a field, allows you to automatically populate a field’s value based on a formula or script that references other fields. This is achieved using the ‘Calculated’ type or by specifying a script in the ‘Calculation’ field of the dictionary entry for a field.

Example: You could have a ‘Total Cost’ field on an order form that automatically calculates its value by summing up the ‘Price’ and ‘Tax’ fields of the same record using a calculation script.

Attributes, Dictionaries, and UI Configuration

Understanding how to modify field behavior and enhance user interfaces is crucial for customization and efficiency.

51. What are attributes, and name some of the attributes that you have used?

Answer: Attributes are special tags applied to dictionary entries (fields) or tables to modify their behavior or appearance on forms and lists. They provide a declarative way to customize ServiceNow components.

Some commonly used attributes include:

• no_email: Prevents email notifications from being sent for changes to this field.
• no_attachment: Disables attachments for this specific field (or the entire table if applied to the collection).
• tree_picker: Changes a reference field to display as a tree-like structure, often used for hierarchical data like CMDB.
• ref_auto_completer=AJAXTableCompleter: Enables auto-completion for reference fields.
• ref_ac_columns=name;email: Specifies which columns to display in the auto-completion dropdown.
• dependent="field_name": Used to create dependent dropdowns (as discussed in Dependent Values).
• readonly: Makes a field read-only.
• mandatory: Makes a field mandatory.

52. What is a collection field on a table?

Answer: The “collection field” on a table’s dictionary entry actually represents the table itself, not a specific field on the table. It’s a special dictionary entry with the ‘Type’ set to ‘Collection’. Any attributes or properties applied to this collection entry affect the entire table. For instance, applying the no_attachment attribute to the collection field will disable attachments for all records in that table.

53. How to enable/disable attachment on the form using attributes?

Answer: To disable attachments on a form for a specific table, you add the no_attachment attribute to the collection field of that table’s dictionary entry. If you want to enable them, you simply remove this attribute.

54. What are dictionary overrides? What properties can we override in dictionary overrides?

Answer: Dictionary Overrides allow you to change the properties of a field that it inherited from its parent table. This is essential when you need a field to behave differently in a child table than it does in the parent table.

You can override many properties, including:

• Default Value: Change the default value of a field.
• Mandatory: Make a field mandatory or optional.
• Read Only: Make a field read-only or editable.
• Display: (Use with caution, usually not recommended for overrides).
• Max Length: Change the maximum length for a string field.
• Calculation: Override the calculation script for a calculated field.
• Reference Specification: Modify reference qualifiers, display values, etc.
• Attributes: Add or remove attributes.

Example: The task table might have a default ‘Priority’ of 4 (Low). You can create a dictionary override on the incident table to change the default ‘Priority’ to 3 (Medium).

55. What are application menus?

Answer: Application Menus (also known as Modules) are used to organize and provide access to forms, lists, and reports within the ServiceNow platform. They appear in the left-hand navigation menu. You create an Application Menu, and then within it, you define Modules. Modules link to specific tables, lists, or reports, making them easily accessible to users based on their roles and permissions.

56. What is process flow?

Answer: Process Flow (sometimes called a Flow Designer flow or a visual workflow) is a graphical representation of the steps or stages involved in a specific business process. It’s used to guide users through a workflow, showing them where they are in the process and what the next steps are. It can be displayed on forms to provide visual cues about the record’s current state.

57. What are data lookup rules?

Answer: Data Lookup Rules are a feature that allows you to automatically populate field values on a form based on the values of other fields on the same form. Unlike dictionary overrides or dependent fields that have a more direct relationship, lookup rules use a separate table (sys_data_lookup) to define the mapping. When conditions met in the lookup rule are found in the source fields, the target field is populated with the corresponding value.

Example: If you select a ‘Country’ on a form, a data lookup rule could automatically populate the ‘State/Province’ based on a predefined list.

UI Policies vs. Data Policies

These two features are often confused but serve distinct purposes. Understanding their differences is crucial for effective client-side and server-side scripting.

58. What are UI Policies?

Answer: UI Policies are client-side scripts that dynamically change the behavior of form elements based on certain conditions. They can make fields mandatory, read-only, or visible/invisible. They are configured through a user-friendly interface without requiring extensive scripting knowledge, although they do support scripting for more complex actions.

59. What is the global checkbox in UI policies?

Answer: The ‘Global’ checkbox on a UI Policy determines its scope.

• If checked (Global): The UI Policy will apply to all views of the form.
• If unchecked: You will be prompted to specify which view(s) the UI Policy should apply to. This allows for view-specific UI behavior.

60. What is reverse if false in UI policies?

Answer: When the “Reverse if false” checkbox is selected in a UI Policy, the actions defined in the UI Policy will be reversed when the condition evaluates to false. For example, if a UI Policy makes a field mandatory when a certain condition is true, and “Reverse if false” is checked, that field will become optional again when the condition becomes false. This is a very useful setting for managing field properties dynamically.

61. What is the onload checkbox in UI policy?

Answer: The “On Load” checkbox dictates when the UI Policy’s conditions and actions are evaluated.

• If checked (“On Load”): The UI Policy runs immediately when the form is loaded.
• If unchecked: The UI Policy will not run on form load. Its actions will only be triggered when a field value changes that meets the UI Policy’s conditions.

62. What is the inherit checkbox?

Answer: The “Inherit” checkbox on a UI Policy is relevant for tables that extend other tables. When checked, it means that the UI Policy will also be applied to any child tables that inherit from the table on which the UI Policy is defined. This is a powerful way to enforce consistent UI behavior across related tables.

63. Can you write script in UI policy?

Answer: Yes, you can write scripts within a UI Policy. To do this, you need to enable the “Run scripts” checkbox within the UI Policy record. Once enabled, you will see sections for “Onload script” and “On condition script” (for UI Policy Actions). These scripts allow for more complex client-side logic that goes beyond the simple conditions and actions.

64. Can we convert a UI policy as a data policy?

Answer: Yes, you can convert a UI Policy into a Data Policy. ServiceNow provides a convenient way to do this. You would typically open the UI Policy, and there will be an option or button to “Convert to Data Policy.” This process aims to translate the UI Policy’s logic into its server-side data policy equivalent.

65. Which are all the cases where a UI policy cannot be converted as a data policy?

Answer: While the conversion is often possible, there are scenarios where a UI Policy cannot be directly or perfectly converted to a Data Policy:

• Controlling Visibility: UI Policies can hide or show fields (visibility). Data Policies operate at a data level and cannot directly control the UI visibility of fields.
• Controlling Views: UI Policies can be view-specific. Data Policies apply to all views.
• Controlling Related Lists: UI Policies can show/hide related lists. Data Policies do not manage UI elements like related lists.
• Complex Client-Side Scripting: UI Policies can execute complex client-side JavaScript. While Data Policies can use scripts, they are server-side and cannot replicate the direct DOM manipulation or browser-specific interactions that client scripts might perform.
• Form Element Behavior: Some UI Policy actions might target specific form element behaviors that don’t have a direct server-side equivalent.

In these cases, you would need to manually re-implement the logic in a Data Policy or use server-side scripts (like Business Rules) in conjunction with the Data Policy.

66. What are data policies?

Answer: Data Policies are server-side (and client-enforced) rules that enforce data integrity by making fields mandatory, read-only, or visible under specific conditions. Unlike UI Policies which are client-side and view-specific, Data Policies apply consistently across all data sources (e.g., forms, imports, integrations, mobile) and are enforced on the server. They are crucial for ensuring data quality regardless of how the data is entered into ServiceNow.

By thoroughly understanding these questions and their practical implications, you’ll be well on your way to acing your next ServiceNow Request Management interview. Good luck!