Ace Your Next Interview: Top ServiceNow Admin Questions You Need to Master

So, you’re eyeing that coveted ServiceNow Administrator role? Fantastic! As the digital backbone of many organizations, ServiceNow admins are in high demand. But landing that dream job isn’t just about knowing your way around the platform; it’s about demonstrating your depth of understanding, problem-solving skills, and a knack for best practices during the interview.

Interviewers aren’t just looking for textbook answers; they want to see how you think, how you’d tackle real-world challenges, and whether you genuinely grasp the ‘why’ behind the ‘what’. This article is your personal cheat sheet, packed with common (and some not-so-common) ServiceNow admin interview questions, expanded answers, practical insights, and pro tips to help you shine.

Let’s dive in and transform those potential interview jitters into confident conversation!

Getting Started: Your ServiceNow Journey & Foundational Knowledge

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

Answer: “Currently, I’m working with the Washington D.C. release, which is the latest version. I always make sure to keep myself updated with new features and changes introduced in each release.”

2. From which version did you start working on ServiceNow?

Answer: “My journey with ServiceNow began with the Rome release. Since then, I’ve gained hands-on experience across multiple versions, including San Diego, Tokyo, Utah, Vancouver, and now Washington D.C. This progression has given me a comprehensive understanding of how the platform has evolved.”

Mastering User and Group Management

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

Answer: “Yes, absolutely! We can assign roles (which define permissions) to both individual users and groups. This can be done manually through the UI or programmatically using GlideRecord scripts. However, the unequivocal best practice is to assign roles to groups, not directly to individual users.“

“Why? Imagine an employee leaves the organization. If roles were assigned directly, you’d have to meticulously remove each role from that user. If roles are assigned to groups, simply removing the user from their respective groups automatically revokes all associated permissions. This dramatically simplifies user lifecycle management, reduces administrative overhead, and minimizes the risk of orphaned permissions. It’s all about maintainability and security.”

4. What is the user table name?

Answer: “The user table is named sys_user.”

5. What is the group member table name?

Answer: “The table that defines which users belong to which groups is sys_user_grmember.”

6. How to create a user account using a script?

Answer: “You can create a user account programmatically using a GlideRecord script, which is particularly useful for bulk imports or integrations. Here’s a common example:”

var userGr = new GlideRecord('sys_user');
userGr.initialize(); // Prepares a new record for insertion
userGr.user_name = 'jdoe'; // Unique username
userGr.first_name = 'John';
userGr.last_name = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.insert(); // Inserts the new record into the database
gs.info("User jdoe created successfully.");
    

7. How to create a group using a script?

Answer: “Creating a group via script follows a similar GlideRecord pattern:”

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@example.com';
newGr.description = 'Test group for development purposes.';
newGr.insert();
gs.info("Group 'Testing Group' created successfully.");
    

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

Answer: “Permissions (roles) are managed through specific relationship tables. When a role is added to a user, a record is created in sys_user_has_role. For groups, it’s sys_group_has_role. Adding roles via script involves creating records in these respective tables:”

Adding a Role to a User:

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
userRole.setValue('user', '62826bf03710200044e0bfc8bcbe5df1'); // Sys_id of the user
userRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Sys_id of the role
userRole.insert();
gs.info("Role added to user successfully.");
    

Adding a Role to a Group:

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
grpRole.setValue('group', '477a05d153013010b846ddeeff7b1225'); // Sys_id of the group
grpRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Sys_id of the role
grpRole.insert();
gs.info("Role added to group successfully.");
    

9. What exactly does user delegation mean in ServiceNow?

Answer: “User delegation in ServiceNow allows one user to act on behalf of another. This is typically implemented when an employee is temporarily unavailable, such as being on vacation or leave. The delegated user gains specific permissions to perform tasks, access resources, or approve items that the original user normally would.”

“A classic example is an employee going on vacation and delegating their approval tasks to a colleague. This ensures critical workflows continue uninterrupted. To configure this, an administrator (or the user themselves, if granted permission) navigates to the original user’s profile, scrolls down to the ‘Delegates’ related list, and adds a new delegate. Here, you define the delegate’s name, start and end dates, and specify which permissions they receive (e.g., approvals, assignments, notifications).”

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

Answer: “Adding or removing a user from a group involves manipulating records in the sys_user_grmember table.”

Adding Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
grMem.user = '62826bf03710200044e0bfc8bcbe5df1'; // Sys_id of the user
grMem.group = '477a05d153013010b846ddeeff7b1225'; // Sys_id of the group
grMem.insert();
gs.info("User added to group successfully.");
    

Removing Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1'); // Query for the specific user
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // Query for the specific group
grMem.query();

if (grMem.next()) { // Check if the record exists
    grMem.deleteRecord(); // Delete the record
    gs.info("User removed from group successfully.");
} else {
    gs.warn("User not found in the specified group.");
}
    

Understanding ServiceNow User Interfaces and Context

11. How many user interfaces are there in ServiceNow?

Answer: “While older versions had UI15 and UI16, the main interfaces we talk about today are UI16 (the standard backend UI that most admins and fulfillers use) and the newer Next Experience UI, which is the future of ServiceNow’s user interface, offering a more modern and intuitive experience.”

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

Answer: “A web services user is a specific type of user account granted access solely for third-party applications or external systems to connect and interact with ServiceNow via web services (e.g., REST, SOAP). Crucially, this user cannot log in interactively to the ServiceNow instance through the UI. It’s a non-interactive account, designed purely for system-to-system communication, enhancing security by limiting direct user access while enabling necessary integrations.”

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

Answer: “On the client side (e.g., in a Client Script or UI Policy script), you can retrieve the current user’s system ID using g_user.userID;. This returns the sys_id of the user.”

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

Answer: “On the server side (e.g., in a Business Rule, Script Include, or Workflow script), you use gs.getUserID();. This also returns the sys_id.”

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 easily check group membership using gs.getUser().isMemberOf('group name');. This method returns true if the user is a member of the specified group and false otherwise.”

if (gs.getUser().isMemberOf('Service Desk')) {
    gs.info("User is a member of the Service Desk group.");
} else {
    gs.info("User is NOT a member of the Service Desk group.");
}
    

16. Which role is required to work on Access Control (ACLs)?

Answer: “To create, modify, or delete Access Control Lists (ACLs), the security_admin role is required. This is a highly privileged role, usually elevated temporarily, to ensure strict control over instance security.”

17. What is impersonation?

Answer: “Impersonation is a powerful feature in ServiceNow that allows an administrator or a user with the impersonator role to ‘log in’ as another user without needing their credentials. This is primarily used for testing purposes, such as verifying how the UI appears for a specific user, checking if ACLs or UI policies are working correctly for their roles, or troubleshooting issues they are experiencing. It’s a critical tool for validation and support.”

18. What is user preference?

Answer: “User preferences allow individual users to customize certain aspects of their ServiceNow experience based on their personal wishes. These changes—like setting a default homepage, theme, or the number of rows displayed in a list—are stored in the sys_user_preference table and only impact that specific user’s view; they do not affect other users or the global settings of the instance.“

IT Service Management (ITSM) Core Concepts

19. What is an Incident?

Answer: “An Incident represents an unplanned interruption to an IT service or a reduction in the quality of an IT service. Essentially, if an employee encounters something that has suddenly stopped working or is not functioning as expected and needs immediate support, they will create an Incident. The goal is to restore normal service operation as quickly as possible and minimize the business impact.”

20. What is a Problem?

Answer: “A Problem is the underlying cause of one or more Incidents. If the same issue repeatedly occurs for a single employee, it might point to a Problem. More critically, if the same issue impacts multiple users concurrently, it’s typically identified as an Incident, but the root cause behind those multiple incidents would be investigated as a Problem. In such cases, a ‘parent’ Incident might be created, linking several ‘child’ incidents to it. When the root Problem is resolved and closed, all associated Incidents (both parent and children, if configured) are subsequently resolved or closed.”

21. Can we create a Problem record from an Incident?

Answer: “Yes, absolutely! This is a very common and recommended practice in ITIL best practices. If a support engineer identifies that an Incident is recurring or is indicative of a deeper, underlying issue, they will create a Problem record directly from that Incident. This links the two records, allowing for root cause analysis to begin while the Incident might still be active.”

22. Can we create a Change Request from an Incident?

Answer: “Yes, this is also a standard workflow. If, during the resolution of an Incident, the support engineer or technical team determines that a modification to an IT service, component, or system is required to prevent future occurrences or improve service quality, they can initiate a Change Request directly from the Incident. For instance, an incident might reveal a bug requiring a software patch, which would be managed through a Change Request.”

Scripting ITSM Records

23. How to create an Incident record using a script?

Answer: “Creating an Incident uses GlideRecord, similar to users and groups:”

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // Sys_id of the caller
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys_id of the Configuration Item
gr.short_description = 'Test Incident created via script';
gr.description = 'This incident was created programmatically for testing purposes.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys_id of the assignment group
gr.insert();
gs.info("Incident " + gr.number + " created successfully.");
    

24. How to create a Problem record using a script?

Answer: “The process for creating a Problem record via script is very similar to an Incident, just targeting the problem table:”

var gr = new GlideRecord('problem');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // If linking to a user, otherwise may be blank
gr.category = 'software';
gr.subcategory = 'database';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys_id of the CI experiencing the problem
gr.short_description = 'Test Problem created via script';
gr.description = 'Investigate recurring database connection failures.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();
gs.info("Problem " + gr.number + " created successfully.");
    

25. How to create a Change Request using a script?

Answer: “For a Change Request, you target the change_request table:”

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'network';
gr.subcategory = 'router';
gr.cmdb_ci = 'affd3c8437201000deeabfcbe5dc3'; // Sys_id of the CI being changed
gr.short_description = 'Test Change Request via script';
gr.description = 'Upgrade firmware on core router to resolve stability issues.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();
gs.info("Change Request " + gr.number + " created successfully.");
    

Advanced ITSM Logic & Business Rules

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

Answer: “This is a classic scenario handled with an ‘After’ Business Rule. The rule should trigger after an update to an Incident, specifically when its state changes to ‘Closed’ (assuming ‘7’ is the value for Closed) and it is indeed a parent incident (no parent itself).”

Business Rule Configuration:
Name: Close Child Incidents on Parent Closure
Table: Incident [incident]
When: After
Update: true
Condition: current.state.changesTo(7) && current.parent.nil()

Script:
if (current.state == 7 && current.parent.nil()) { // Ensure it's the parent incident being closed

    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id); // Query for children of the current incident
    grChild.addQuery('state', '!=', 7); // Only close open child incidents
    grChild.query();

    while (grChild.next()) {
        grChild.state = 7; // Set the state to Closed
        grChild.comments = "Automatically closed as parent incident " + current.number + " was closed.";
        grChild.update(); // Update the child incident
        gs.info("Child incident " + grChild.number + " closed due to parent closure.");
    }
}
    

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

Answer: “This validation should be handled by a ‘Before’ Business Rule to prevent the record from being saved in the ‘Closed’ state if open tasks exist. This rule runs before the database update.”

Business Rule Configuration:
Name: Prevent Closure with Open Tasks
Table: Incident [incident]
When: Before
Update: true
Condition: current.state.changesTo(7) // Trigger when incident state changes to Closed

Script:
var grTask = new GlideRecord('incident_task');
grTask.addQuery('incident', current.sys_id);
grTask.addQuery('state', '!=', 3); // Assuming 3 is the state value for 'Closed' or 'Complete'
grTask.query();

if (grTask.hasNext()) {
    gs.addErrorMessage('Cannot close Incident ' + current.number + ' because there are open tasks associated with it.');
    current.setAbortAction(true); // Aborts the save operation
}
    

“You would implement similar ‘Before’ Business Rules for the problem and change_request tables, adjusting the query to target problem_task or change_task tables, respectively, and linking them via their appropriate reference fields.”

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

Answer: “This is another ‘After’ Business Rule scenario, ensuring consistency between Problem and Incident records.”

Business Rule Configuration:
Name: Close Incidents on Problem Closure
Table: Problem [problem]
When: After
Update: true
Condition: current.state.changesTo(7) // Trigger when Problem state changes to Closed

Script:
if (current.state == 7) {

    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Query for incidents linked to this problem
    grIncident.addQuery('state', '!=', 7); // Only close open incidents
    grIncident.query();

    while (grIncident.next()) {
        grIncident.state = 7; // Set the state to Closed
        grIncident.close_code = 'Solved (Work Around)'; // Or appropriate close code
        grIncident.close_notes = 'Automatically closed due to resolution of Problem ' + current.number + '.';
        grIncident.update(); // Update the incident
        gs.info("Incident " + grIncident.number + " closed due to problem closure.");
    }
}
    

29. What is the relationship between Incident, Problem, and Change Management?

Answer: “They form a crucial triad in ITSM. An Incident is typically the initial symptom an end-user reports—something is broken. If that ‘something broken’ is a recurring issue or affects many users, it might indicate an underlying root cause, which is then investigated as a Problem. Finally, if resolving that Problem requires a modification, upgrade, or alteration to an IT service or component, that modification is managed through a Change Request. In essence, Incidents identify issues, Problems find root causes, and Changes implement solutions.”

ServiceNow Data Model and Tables

30. Give me some names of out-of-the-box (OOB) tables.

Answer: “Out-of-the-box tables are those that come pre-built with ServiceNow and are part of the core platform. Examples include incident, problem, change_request, sys_user, sys_group, cmdb_ci, and task. A quick way to identify them is that they generally don’t start with u_ (for custom tables) or x_ (for scoped application tables).”

31. What are some of the base tables?

Answer: “Base tables are fundamental tables that do not extend any other table but are often extended by many other tables. They act as the root for many important hierarchies. Key examples are the task table, which is extended by Incident, Problem, Change, Service Catalog Request, etc.; and the cmdb_ci table, which forms the base for all Configuration Items (servers, applications, networks, etc.).”

32. Give me some examples of task tables.

Answer: “Task tables are any tables that extend the base task table. The most common examples are incident, problem, and change_request. Others include sc_req_item (Requested Item), sc_task (Catalog Task), and hr_task (HR Task), among many others.”

33. Whenever we create a table, how many Access Controls (ACLs) get created by default?

Answer: “When you create a new table through the ‘Tables’ module and the ‘Create access controls’ checkbox is selected (which it is by default), ServiceNow automatically creates four ACLs for that table: read, write, create, and delete. These ACLs typically grant access to users with the admin role by default.”

34. How to create a number field, like an Incident number?

Answer: “When creating a new table, you configure its auto-numbering scheme in the ‘Controls’ tab. Here, you define the prefix (e.g., ‘INC’ for Incident, ‘PRB’ for Problem), the number of digits (e.g., 7 or 8 digits), and ensure the ‘Auto-number’ checkbox is checked. ServiceNow will then automatically generate unique numbers for new records in that table.”

35. What happens when you extend a table?

Answer: “When you extend a table (create a child table), several key things happen:

1. Field Inheritance: The child table inherits all fields from its parent table. This is why you don’t see system fields like sys_id, sys_created_on, etc., directly created in the child table; they are inherited.
2. Class Field: A special field called sys_class_name (often referred to simply as ‘class’) is added to the parent table. This field stores the name of the actual table where the record was created (e.g., ‘incident’ or ‘problem’ if they extend ‘task’). If a table is extended multiple times, the parent table will still only have one sys_class_name field, which distinguishes the type of child record.
3. Data Model: Data for both parent and child tables is stored in the respective tables, but they are linked. When you query the parent table, it can retrieve records from all its child tables.

”

36. Can you give me 10 field types?

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

1. String: For short text (e.g., Short Description).
2. String (Multi-line): For longer text (e.g., Description).
3. Reference: Links to another record in a different table (e.g., Caller on an Incident linking to a User).
4. List: Allows selection of multiple records from another table (e.g., Watch list).
5. Choice: A dropdown list with predefined options (e.g., State, Category).
6. Date/Time: Stores both date and time values.
7. Date: Stores only date values.
8. Boolean: A checkbox for true/false values.
9. Integer: For whole numbers.
10. Journal: For historical notes or comments, appending new entries (e.g., Work Notes, Comments).
11. Attachment: Allows files to be attached to a record.
12. Email: Specifically for email addresses.

”

37. What is the difference between temporary and normal tables?

Answer: “The main difference lies in data retention. Normal tables (like incident or sys_user) are designed for permanent data storage. Data stored here persists indefinitely unless explicitly deleted.

Temporary tables, on the other hand, are designed for transient data. They typically extend the Import Set Row [import_set_row] table. Data in these tables is usually retained for a short, predefined period (often 7 days by default) and then automatically purged. They are commonly used for import sets, staging data, or other operations where data is not meant to be kept long-term.”

38. Can we increase the retention period in the temporary table?

Answer: “Yes, we can. While temporary tables have a default retention period, you can extend it by configuring Archive Rules. By creating an archive rule for the specific temporary table, you can define how long records should be kept before they are moved to an archive table or permanently deleted, effectively increasing the retention period.”

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

Answer: “Normal tables in ServiceNow store data directly within the ServiceNow database. When you query a normal table, you’re accessing data that resides physically within your instance.

Remote tables, introduced to enhance integration capabilities, allow you to interact with data stored in an external system (e.g., another database, an HR system, or a CRM) as if it were a native ServiceNow table. The key difference is that remote tables don’t store the data locally. Instead, when you query a remote table, ServiceNow makes a live call to the external system to retrieve the data. This provides real-time access to external data without replication, though it might have performance implications depending on the external system’s responsiveness.”

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

Answer: “Relationships define how records across different tables are connected:

• One-to-Many Relationship: This is the most common type. One record in a ‘parent’ table can be associated with multiple records in a ‘child’ table, but each child record can only be associated with one parent. A classic example is Users and Incidents: One user can create multiple incidents, but each incident is typically ‘called by’ only one user. Another is Departments and Users: One department can have many users, but a user usually belongs to one primary department.
• Many-to-Many Relationship: Here, multiple records in one table can be associated with multiple records in another table. This is implemented using a junction table (or ‘many-to-many’ table) that links the sys_ids of records from both tables. An example is Incidents and Configuration Items (CIs): An incident can affect multiple CIs, and a single CI can be associated with multiple incidents (through the task_ci table). Similarly, Users and Roles (through sys_user_has_role) or Groups and Roles (through sys_group_has_role) are many-to-many.

”

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

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

1. Form Submission: Manually filling out and submitting a form in the UI.
2. Record Producer: A Service Catalog item that creates a record in a target table (e.g., ‘Report an Incident’ creates an Incident record).
3. Scripting (GlideRecord): Using server-side scripts (e.g., Business Rules, Script Includes, background scripts).
4. Email Inbound Actions: Configuring the system to parse incoming emails and create records (e.g., an email to the service desk creating an Incident).
5. Import Sets: Importing data from external sources (Excel, CSV, XML) into a staging table, then transforming it into target tables.
6. Web Services/APIs: External systems creating records via REST or SOAP APIs.
7. Flow Designer / Workflows: Automated flows or workflows can create records as part of their logic.

”

Controlling Fields: UI Policies, Data Policies, & Dictionary

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

Answer: “You can control field mandatoriness and read-only states in several ways, each with its own scope and precedence:

1. Dictionary Properties: Directly on the field’s dictionary entry (most foundational).
2. Dictionary Overrides: To set different behaviors for child tables extending a parent’s field.
3. UI Policies: Client-side logic for dynamic changes based on user interaction or form state.
4. Data Policies: Can enforce rules on both client and server sides, affecting all data input sources (forms, imports, web services).
5. Client Scripts (g_form.setMandatory/setReadOnly): Programmatic control on the client side for highly dynamic or complex scenarios.

43. Can we make 2 fields as ‘Display’ in one table?

Answer: “No, you should not configure two fields as the ‘Display’ field in a single table. The ‘Display’ field is a special dictionary attribute (display=true) that designates one field as the primary identifier for a record when it’s referenced by another table or displayed in lists and auto-completion. Having two display fields would lead to confusion and unpredictable behavior within the platform, as it wouldn’t know which one to use for record identification.”

44. All tables will be stored where?

Answer: “Metadata about all tables, including their names, descriptions, and relationships, is stored in the sys_db_object table. This is the ‘dictionary’ of your database schema within ServiceNow.”

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

Answer: “You can set a default value for a field directly on its dictionary entry. When a new form is loaded, this default value will automatically populate the field, saving user effort and ensuring data consistency. You can either hardcode a value or use a JavaScript expression (e.g., javascript:gs.getUserID() to default to the current user).”

46. What is the current object?

Answer: “The current object is a server-side JavaScript object that represents the record being inserted, updated, or queried in the database. It provides access to all the fields and their values on that record. It’s predominantly used in server-side scripts like Business Rules, Script Includes, and Workflow scripts to set, get, or manipulate field values before or after a database operation.”

47. How to set the field values on the current form (using the current object)?

Answer: “Using the current object (server-side):

• For most field types (String, Choice, Integer, etc.):

  current.field_name = 'value';

  Example: current.short_description = 'My new description';

• For Reference fields (when you have the sys_id):

  current.reference_field_name = 'sys_id_of_referenced_record';

  Example: current.caller_id = '6816f79cc0a8016401c5a33be04be441';

• For Reference fields (when you want to set by display value, which is generally less performant and not recommended for critical logic, but useful sometimes):

  current.setDisplayValue('reference_field_name', 'Display Value');

  Example: current.setDisplayValue('caller_id', 'John Doe'); (The system will then look up the sys_id based on this display value).

”

48. What are reference qualifiers, and their types? Explain each one in detail, and what is the difference in simple and dynamic, dynamic and advanced, simple and advanced.

Answer: “Reference Qualifiers are mechanisms used to filter the data displayed in ‘Reference’ and ‘List’ type fields. They restrict the selection options available to the user, ensuring data accuracy and improving user experience. There are three main types:

Simple Reference Qualifier:

• Description: This is the most straightforward type. You define a fixed query string using standard ServiceNow query operators (e.g., active=true, department=IT). The filter remains constant regardless of other fields on the form.
• Example: Display only active users in the ‘Caller’ field: active=true
• Use Case: When you need a static, unchanging filter for a reference field.
• Difference from Advanced: No JavaScript or complex logic needed; it’s a simple key-value query.

Dynamic Reference Qualifier:

• Description: This type uses a pre-defined ‘Dynamic Filter Option’ script that can generate a query based on contextual information (like the current user, group, or other field values on the form). The actual logic is encapsulated in a reusable script.
• Example: Display only incidents assigned to the current user’s assignment groups. You’d have a Dynamic Filter Option that builds a query like assignment_groupIN(javascript:gs.getUser().getMyGroups()).
• Use Case: When you need a dynamic, reusable filter that depends on context but don’t want to embed complex JS directly in the dictionary.
• Difference from Simple: It’s dynamic and context-aware, not static.
• Difference from Advanced: The JavaScript logic is stored separately in a ‘Dynamic Filter Option’ record, making it reusable and cleaner than inline advanced JavaScript.

Advanced Reference Qualifier (JavaScript Reference Qualifier):

• Description: This is the most flexible type, allowing you to write custom JavaScript code directly in the dictionary entry to generate a complex query string. It provides full control to dynamically filter based on multiple conditions, current record values, or any server-side logic.
• Example: Filter Configuration Items (CIs) to show only those related to the current Incident’s caller’s department, and are also ‘Operational’.

  javascript: 'install_status=1^department=' + current.caller_id.department;

  (Assuming install_status=1 means operational, and department is a field on the caller’s user record).

• Use Case: For highly specific, complex, or single-use dynamic filtering requirements that might not warrant a reusable Dynamic Filter Option.
• Difference from Simple: Uses JavaScript for dynamic, complex filtering, unlike simple’s static query.
• Difference from Dynamic: JavaScript is written inline in the dictionary entry, rather than being referenced from a ‘Dynamic Filter Option’.

”

49. What is a dependent value?

Answer: “Dependent values in ServiceNow are used to create cascaded dropdown menus, where the available choices in one field (the dependent field) are filtered based on the selection made in another field (the parent field). This greatly improves data entry accuracy and user experience.

Steps to Configure:

1. Parent Field: Ensure your parent field (e.g., ‘Category’) is a Choice field with predefined options.
2. Dependent Field: Navigate to the dictionary entry of your dependent field (e.g., ‘Subcategory’).
3. Set Dependent Field: In the dictionary entry, set the ‘Dependent field’ attribute to the parent field (e.g., ‘Category’).
4. Define Choices: When you add choices for the dependent field, you’ll see a ‘Dependent value’ column. Here, you specify which parent field value must be selected for that choice to become available.

Example: If ‘Category’ is ‘Hardware’, ‘Subcategory’ choices like ‘Laptop’, ‘Desktop’, ‘Printer’ appear. If ‘Category’ is ‘Software’, ‘Subcategory’ choices like ‘Operating System’, ‘Application’ appear. This relationship is managed entirely through dictionary entries for Choice fields.”

50. What is a calculated value?

Answer: “A calculated value is a dictionary property that allows a field’s value to be automatically computed based on other field values on the same record using a server-side script. When configured, instead of storing a static value, the field will execute a JavaScript expression whenever the record is queried or displayed, showing a dynamically calculated result. This is useful for derived data that doesn’t need to be persistently stored but should reflect real-time calculations based on other fields. You access the current object within this script to get other field values for the calculation.”

51. What are attributes? Name some of the attributes that you used.

Answer: “Attributes are special key-value pairs added to dictionary entries to modify the behavior or appearance of fields, forms, or even tables beyond standard dictionary settings. They provide fine-grained control over various aspects of the platform.

Some commonly used attributes include:

• no_email: Prevents a field’s value from being included in email notifications.
• no_attachment: Disables the attachment icon for a field (or the entire table if applied to the collection record).
• no_add_me: Prevents a user from being able to ‘Add me to Watch list’ (for list-type fields).
• tree_picker=true: Displays a tree-like hierarchy for reference fields, often used with CMDB.
• ref_ac_columns=field1;field2: Specifies additional columns to show in the auto-complete dropdown for a reference field.
• max_length=X: Specifies the maximum number of characters for a string field.

”

52. What is a collection field on a table?

Answer: “The Collection field is a special dictionary entry that represents the entire table itself, rather than a specific field within the table. Every table in ServiceNow has a ‘Collection’ dictionary entry (you can find it by filtering dictionary entries for [your_table_name] and then selecting the record where ‘Type’ is ‘Collection’). Any attributes or settings applied to this collection entry (e.g., no_attachment, table_view) will affect the entire table globally, rather than just a single field. It’s automatically created when a table is created and serves as the overarching metadata container for the table’s behavior.”

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

Answer: “To control attachments for an entire form/table, you would add or remove the no_attachment attribute to the Collection field’s dictionary entry for that table. If no_attachment is present, attachments will be disabled. Removing it (or ensuring it’s not present) will enable attachments.”

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

Answer: “Dictionary Overrides provide a powerful way to allow a field in a child table to behave differently from the same inherited field in its parent table. This is crucial for customizing behavior without altering the parent table’s definition, which would impact all its children.

For example, the ‘Priority’ field is inherited from the task table. You might want its default value to be ‘4 – Low’ for a standard Task, but for an Incident, you want the default to be ‘3 – Moderate’. A Dictionary Override on the incident table for the ‘Priority’ field would allow you to achieve this.

Properties you can override include:

• Default Value
• Read Only
• Mandatory
• Reference Qualifier
• Display (rarely needed)
• Column label (changes the label for that specific child table)
• Max length
• Active (deactivate the field for the child table)
• Attributes
• Dependent field (for choice fields)

”

UI and Data Control: Policies and Menus

55. What are application menus?

Answer: “Application Menus (also known as Applications) are the high-level navigators on the left-hand navigation pane in ServiceNow. They act as containers for ‘Modules.’ For example, ‘Incident,’ ‘Problem,’ ‘Change,’ and ‘User Administration’ are all Application Menus. They organize related functionality and provide access to lists, forms, or other pages for end-users, fulfillers, or administrators.”

56. What is a process flow?

Answer: “A Process Flow (or ‘Process Flow Formatter’) is a visual indicator that appears at the top of a record form, typically for ITSM records like Incident, Problem, or Change. It displays the current stage or state of the record in a clear, step-by-step manner. For example, an Incident might show stages like ‘New,’ ‘Assigned,’ ‘In Progress,’ ‘Resolved,’ and ‘Closed.’ It helps users quickly understand where a record is in its lifecycle and what the next steps might be.”

57. What are data lookup rules?

Answer: “Data Lookup Rules (and Data Lookup Definitions) allow you to automatically set field values on a form based on the values of other fields, often without needing complex scripting. It’s like having a miniature decision table. For example, you can configure a rule that says: ‘If Category is ‘Hardware’ and Subcategory is ‘Laptop’, then automatically set the ‘Assignment Group’ to ‘Hardware Support’. They are defined in a separate table and offer a low-code way to enforce business logic for field population.”

58. What are UI policies?

Answer: “UI Policies are client-side logic that allows you to dynamically modify the behavior of fields on a form based on certain conditions. They run in the user’s browser and are used to:

• Make fields mandatory or optional.
• Make fields read-only or editable.
• Hide or show fields.
• Show or hide related lists based on conditions.

They are a great low-code way to enhance form usability and data quality.”

59. What is the global checkbox in UI policies?

Answer: “When the ‘Global’ checkbox in a UI Policy is selected, the UI Policy applies to all views of the form for that table. If you uncheck ‘Global’, a ‘View’ field appears, allowing you to specify a particular form view (e.g., ‘Default’, ‘Self-Service’, ‘Agent Workspace’) for which the UI Policy should be active. This provides flexibility to have different field behaviors across different user experiences.”

60. What is ‘Reverse if false’ in UI policies?

Answer: “If the ‘Reverse if false’ checkbox is selected in a UI Policy, it means that when the UI Policy’s conditions evaluate to false, the actions previously applied by the UI Policy (when the conditions were true) will be automatically reversed. For example, if a field was made mandatory when a condition was true, it will become optional again when that condition becomes false. This saves you from writing separate UI Policies to undo the effects.”

61. What is the ‘On load’ checkbox in UI policies?

Answer: “When the ‘On load’ checkbox is selected, the UI Policy’s conditions and actions are evaluated and applied immediately when the form initially loads. If it’s not selected, the UI Policy actions will only be triggered when a field value on the form changes that matches one of its conditions. It dictates whether the policy’s rules are active from the moment the form appears or only after user interaction.”

62. What is the ‘Inherit’ checkbox in UI policies?

Answer: “When the ‘Inherit’ checkbox is selected, the UI Policy will also apply to all tables that extend the current table. For instance, if you create a UI Policy on the task table with ‘Inherit’ checked, that policy will also run on incident, problem, and change_request forms (since they all extend task).”

63. Can you write a script in a UI policy?

Answer: “Yes, you absolutely can! UI Policies offer a ‘Run scripts’ checkbox. When checked, two script fields appear: ‘Execute if true’ and ‘Execute if false’. This allows you to write client-side JavaScript that executes when the UI Policy’s conditions are met (or not met), enabling more complex form manipulations that go beyond simple mandatory/read-only/visibility changes, such as making AJAX calls, displaying custom alerts, or interacting with other elements on the page.”

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

Answer: “Yes, ServiceNow provides a convenient way to convert a UI Policy into a Data Policy. You can open an existing UI Policy and look for an option like ‘Convert to Data Policy’ or ‘Create Data Policy’ (the exact wording might vary slightly by version or context menu). This is useful when you’ve already defined complex client-side rules and realize they need to be enforced at the server level for all data input sources.”

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

Answer: “A UI Policy cannot be directly converted into a Data Policy if it contains actions that are purely client-side or related to display, such as:

• When you are controlling data visibility (i.e., hiding/showing fields or sections).
• When you are controlling form views.
• When you are controlling the visibility of related lists.
• When you are using the ‘Run scripts’ functionality within the UI Policy to execute custom client-side JavaScript.

Data Policies focus purely on data integrity (mandatory/read-only) regardless of the source, whereas UI Policies have broader client-side visual and interactive control.”

66. What are data policies?

Answer: “Data Policies are rules used to enforce data consistency and integrity across all data entry points in ServiceNow. Unlike UI Policies, which are primarily client-side and affect only forms, Data Policies operate at both the client-side (form) and server-side (all data sources). This means they can make fields mandatory or read-only not only when a user fills out a form but also when data is imported, submitted via web services, or updated through scripts. They ensure that data adheres to business rules no matter how it enters the system.”

Conclusion: Your Path to ServiceNow Admin Excellence

Navigating a ServiceNow Admin interview requires more than just memorizing definitions; it demands a practical understanding of how the platform works, how to apply best practices, and how to troubleshoot common scenarios. By deeply understanding the concepts covered in these questions, you’re not just preparing for an interview—you’re cementing your foundation as a capable and confident ServiceNow professional.

Remember, the ServiceNow ecosystem is constantly evolving. Staying curious, continuously learning about new features and updates (like the latest Washington D.C. release!), and practicing your scripting skills will keep you at the top of your game. Good luck with your interview—go out there and ace it!