Mastering ServiceNow Development: Your Top 50 Interview Questions Answered

Breaking into the world of ServiceNow development, or looking to level up your career? You know that the interview process is a crucial step. It’s not just about reciting facts; it’s about demonstrating your understanding, your problem-solving skills, and your ability to apply knowledge in real-world scenarios. This article dives deep into 50 frequently asked ServiceNow developer interview questions, providing comprehensive, human-like answers that go beyond simple definitions. We’ll explore the ‘why’ behind the ‘what,’ offer practical examples, and equip you with the confidence to ace your next interview.

Let’s get started!

I. ServiceNow Fundamentals & Versions

Understanding the platform’s evolution and your personal experience with it is a common starting point. This section explores core concepts and your journey with ServiceNow.

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

Answer: “I’m currently working with the Washington DC release. It’s exciting to be on the latest version, as it brings some fantastic new features and performance enhancements, especially in areas like AI and workflow automation.”

2. From which version did you start working?

Answer: “My ServiceNow journey began with the Rome release. Since then, I’ve had hands-on experience with San Diego, Tokyo, Utah, Vancouver, and now Washington DC. This progression has given me a great perspective on how the platform has matured and the continuous innovation ServiceNow brings with each release.”

II. User and Group Management: The Core of Access Control

User and group management are fundamental to security and workflow in ServiceNow. These questions assess your understanding of how access is granted and managed.

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

Answer: “Absolutely, permissions are primarily managed through roles in ServiceNow. You can assign roles directly to individual users, or more effectively, assign them to groups. The best practice is undeniably to assign roles to groups. Why? Because when an employee joins, you add them to relevant groups, and they inherit the necessary roles. When they leave, you simply remove them from the group, and all their associated roles are automatically revoked. This drastically simplifies user lifecycle management, reduces errors, and enhances security.”

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 (i.e., the group membership table) is sys_user_grmember.

6. How to create a user account using script?

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

var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username = 'jdoe';
userGr.first_name = 'John'; // Note: Field names are typically lowercase with underscores
userGr.last_name = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.insert();
    

7. How to create a group using script?

Answer: Creating a group via script uses GlideRecord as well:

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Testing Team'; // Use a descriptive name
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Sys ID of the manager
newGr.email = 'testing@tcs.com';
newGr.description = 'This group handles testing activities.';
newGr.insert();
    

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

Answer: Adding roles involves interacting with specific association tables:

For Users: A record in the sys_user_has_role table is created. You can add a role to a user programmatically:

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

For Groups: A record is created in the sys_group_has_role table:

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

9. What exactly does user delegation mean in ServiceNow?

Answer: “User delegation in ServiceNow allows one user to act on behalf of another user. This is incredibly useful when a user is unavailable, perhaps on vacation, extended leave, or even just out of office for a few days. The delegated user gains the necessary permissions to perform tasks, access resources, and importantly, act on approvals that would normally be handled by the original user. For example, a manager might delegate their approval tasks to their executive assistant while they’re attending a conference. You configure this by navigating to the original user’s record, scrolling down to the ‘Delegates’ related list, and specifying who the delegate is, the duration of the delegation, and what specific actions they can perform (assignments, notifications, approvals).”

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

Answer: This involves the sys_user_grmember table:

Adding a Group Member:

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

Removing a Group Member:

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

11. How many user interfaces are there in ServiceNow?

Answer: “Historically, ServiceNow has had several major UI frameworks. The most prominent ones you’ll encounter are UI15 (an older, widely adopted version), UI16 (the more modern and feature-rich evolution of UI15), and the Next Experience UI (the latest, streamlined, and highly customizable interface, often referred to as Polaris).”

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

Answer: “A ‘web services user,’ often referred to as an ‘integration user’ or ‘system user,’ is an account created specifically for non-human access. When a third-party application or another system needs to connect to ServiceNow to exchange data (e.g., via REST APIs), it authenticates using the credentials of a web services user. Crucially, these users typically cannot log in to the ServiceNow graphical user interface (GUI) as a regular end-user would. Their purpose is purely programmatic interaction.”

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

Answer: On the client-side (e.g., in client scripts or UI Policies), you can get the current user’s Sys ID using the global variable g_user.userID. So, it would be 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), you use the gs object: gs.getUserID().

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

Answer: On the server-side, you can use gs.getUser().isMemberOf('group_name_or_sys_id'). This method returns true if the user is a member of the specified group, and false otherwise. For example: if (gs.getUser().isMemberOf('ITIL Users')) { /* do something */ }.

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

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

17. What is impersonation?

Answer: “Impersonation in ServiceNow is a powerful feature that allows a user with appropriate permissions (typically admin or impersonator role) to temporarily log in and act as another user. This is invaluable for testing. It allows developers and support staff to see exactly what a specific user would see and experience when interacting with the platform, helping to diagnose issues related to roles, permissions, or user-specific configurations.”

18. What is a user preference?

Answer: “User preferences are personal settings that individual users can configure to customize their ServiceNow experience. These preferences are specific to that user and do not affect anyone else on the platform. Examples include setting default list columns, preferred language, homepage layout, or even theme colors. These are stored in the sys_user_preference table.”

III. ITSM Processes: Incident, Problem, and Change Management

These three pillars of IT Service Management (ITSM) are core to ServiceNow’s functionality. Understanding their relationships and how to script within them is essential.

19. What is an incident?

Answer: “An incident is defined as an unplanned interruption to an IT service or a reduction in the quality of an IT service. Essentially, it’s when something breaks or stops working as expected for an end-user, preventing them from performing their job. The goal of incident management is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations, often by resolving the incident or providing a workaround.”

20. What is a problem?

Answer: “A problem is the underlying cause of one or more incidents. While an incident focuses on restoring service quickly, problem management aims to identify the root cause of recurring incidents and prevent them from happening again. For example, if multiple users report slow internet access (multiple incidents), problem management would investigate the network infrastructure to find the root cause (e.g., an overloaded router). If the same issue is happening to multiple people simultaneously, it’s an incident where we might create a parent incident, and the rest are child incidents. Resolving the parent incident resolves the children.”

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

Answer: “Yes, absolutely. This is a common and recommended practice. When a support engineer is working on an incident and identifies that the issue is recurring or potentially has a deeper underlying cause, they can create a problem record directly from the incident. This action usually links the incident to the newly created problem, allowing for better tracking and root cause analysis.”

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

Answer: “Yes, indeed. If resolving an incident requires a modification to the IT infrastructure, software, or any IT service – essentially, making a change – a change request can be initiated from the incident. This ensures that any changes made are properly assessed, planned, approved, and implemented, reducing the risk of introducing new incidents.”

23. How to create an incident record using script?

Answer: Using GlideRecord on the incident table:

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = '86826bf03710200044e05d94'; // Sys ID of the caller
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys ID of the Configuration Item
gr.short_description = 'Antivirus scan failed on user workstation';
gr.description = 'The scheduled antivirus scan on user workstation XYZ did not complete successfully.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys ID of the assignment group
gr.insert();
    

24. How to create a problem record using script?

Answer: Similar to incidents, using GlideRecord on the problem table:

var gr = new GlideRecord('problem');
gr.initialize();
gr.reported_by = '86826bf03710200044e0bfc8be5d94'; // Example: Reported by field, might be caller_id or similar depending on configuration
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys ID of the Configuration Item
gr.short_description = 'Recurring antivirus failures across multiple users';
gr.description = 'Multiple users are reporting intermittent failures with the endpoint antivirus solution.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys ID of the assignment group
gr.insert();
    

25. How to create a change request using script?

Answer: Using GlideRecord on the change_request table:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'normal'; // Or 'standard', 'emergency'
gr.type = 'standard'; // Example: Type of change
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys ID of the Configuration Item affected
gr.short_description = 'Update Antivirus definitions';
gr.description = 'Scheduled update of endpoint antivirus definitions across the enterprise.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys ID of the assignment group responsible
gr.insert();
    

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

Answer: This is a classic use case for an after business rule on the incident table.

// Business Rule: Close Child Incidents
// Table: Incident
// When: after
// Update: true
// Condition: current.state.changesTo(7) // Assuming state 7 is 'Closed'

(function executeRule(current, previous /*, gsc, role */ ) {

    // Check if the current incident is a parent and is being closed
    if (current.state == 7 && current.parent == '') {
        gs.info('Parent incident ' + current.number + ' is closing. Attempting to close child incidents.');

        var grChild = new GlideRecord('incident');
        grChild.addQuery('parent', current.sys_id);
        grChild.query();

        while (grChild.next()) {
            // Ensure child is not already closed before attempting to close
            if (grChild.state != 7) {
                gs.info('Closing child incident: ' + grChild.number);
                grChild.state = 7; // Set the state to Closed
                grChild.update(); // Update the child incident
            }
        }
    }

})(current, previous);
    

27. There is an incident with associated 2 tasks. When attempting to close the incident, if any incident task is open, the employee should not be able to close the incident. Similar for problem and change request.

Answer: This requires a before business rule on the incident table (or problem/change_request with appropriate task tables).

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

(function executeRule(current, previous /*, gsc, role */ ) {

    // Check if the incident is attempting to be closed
    if (current.state.changesTo(7)) {
        var grTask = new GlideRecord('incident_task');
        grTask.addQuery('incident', current.sys_id);
        grTask.addActiveQuery(); // A simpler way to check for non-closed states
        // Alternatively: grTask.addQuery('state', '!=', 3); // Assuming 3 is the state value for 'Closed'
        grTask.query();

        if (grTask.hasNext()) {
            gs.addErrorMessage('Cannot close the incident because there are open incident tasks.');
            current.setAbortAction(true); // Prevent the update
        }
    }

})(current, previous);
    

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

Answer: This would be an after business rule on the problem table.

// Business Rule: Close Associated Incidents on Problem Closure
// Table: Problem
// When: after
// Update: true
// Condition: current.state.changesTo(7) // Assuming state 7 is 'Closed'

(function executeRule(current, previous /*, gsc, role */ ) {

    // Check if the problem is being closed
    if (current.state == 7) {
        gs.info('Problem ' + current.number + ' is closing. Closing associated incidents.');

        var grIncident = new GlideRecord('incident');
        grIncident.addQuery('problem_id', current.sys_id); // Link to the problem
        grIncident.addQuery('state', '!=', 7); // Ensure incident is not already closed
        grIncident.query();

        while (grIncident.next()) {
            gs.info('Closing incident associated with problem: ' + grIncident.number);
            grIncident.state = 7; // Set the state to Closed
            grIncident.update(); // Update the incident
        }
    }

})(current, previous);
    

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

Answer: “These three processes form the backbone of effective IT Service Management and are closely interconnected:

• Incident Management: Focuses on restoring service as quickly as possible. When something breaks, users report it as an incident.
• Problem Management: Investigates recurring or significant incidents to find and eliminate the root cause, preventing future occurrences. If an incident is widespread or happens repeatedly, it can be linked to a problem.
• Change Management: Manages all changes to the IT environment. If a problem’s root cause requires a modification, or if an incident’s resolution involves a change, a change request is created. This ensures changes are controlled and don’t introduce new risks or incidents.

Think of it this way: Incidents are the immediate fires to put out. Problems are the underlying faulty wiring that causes those fires. Changes are the controlled actions taken to fix that wiring and prevent future fires.”

IV. ServiceNow Data Model & Table Management

A deep understanding of tables, fields, and the data model is fundamental for any ServiceNow developer. These questions explore that knowledge.

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

Answer: “Out-of-the-box tables are those that are part of the core ServiceNow platform and do not start with a custom prefix like x_ or u_. Common examples include: incident, problem, change_request, sc_req_item (Service Catalog Request Item), sys_user, sys_group, cmdb_ci (Configuration Item), and task.”

31. What are some of the base tables?

Answer: “Base tables are tables that don’t extend any other table but are often extended by many other tables. They form the foundational layers of the ServiceNow data model. Key examples are cmdb_ci (the base for all Configuration Items) and task (the base for incidents, problems, changes, etc.).”

32. Give me some examples of task tables.

Answer: “Any table that extends the base task table is considered a task table. Common examples include incident, problem, change_request, and sc_task (Service Catalog Task).”

33. Whenever we create a table, how many access controls (ACLs) are created by default?

Answer: “By default, when you create a new table in ServiceNow (especially through the visual table builder), four ACLs are created automatically if the ‘Create ACLs’ checkbox is selected. These typically include read, write, create, and delete ACLs, which grant basic access to administrators. You can uncheck this box if you intend to manually create your own custom ACLs.”

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

Answer: “To create an auto-numbering field, like the incident number (e.g., INC0010001), you typically configure this in the Dictionary Entry for that field. On the ‘Control’ tab of the field’s dictionary record, you’d select the ‘Auto Number’ checkbox. You can then define a prefix (like ‘INC’) and the number of digits for the sequential part of the number. This ensures unique, sequential numbering for records.”

35. What happens when you extend a table?

Answer: “When you extend a table (i.e., create a child table that inherits from a parent table), the child table automatically inherits all the fields from the parent. You don’t need to recreate those fields in the child. ServiceNow handles this through the `sys_class_name` field in the parent table, which stores the specific table name of the record. This `sys_class_name` field is crucial for proper record identification and query behavior. You don’t create separate `sys_class_name` fields for each child; one in the parent suffices for all its descendants.”

36. Can you give me 10 field types?

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

1. Reference: Links to another record in a different table.
2. String: For text input (single or multi-line).
3. List: Allows selecting multiple references from another table.
4. Choice: A dropdown list of predefined options.
5. Email: Specifically formatted for email addresses.
6. Date/Time: For capturing both date and time.
7. Date: For capturing only the date.
8. Boolean: A true/false or checkbox field.
9. Integer: For whole numbers.
10. Journal: For accumulating text entries, often used for work notes or comments.
11. Attachment: Allows users to upload files.

(Oops, that’s 11! You can pick your favorite 10.)”

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

Answer: “Normal tables are your standard ServiceNow tables where data is stored permanently until explicitly deleted. They are used for core business data like incidents, users, and configuration items. Temporary tables, on the other hand, are designed for short-term data storage. They often extend the import_set_row table and are typically used for staging data during import operations. The data in these tables is usually purged automatically after a set period, often around 7 days, to manage database size.”

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

Answer: “Yes, you can. While temporary tables have a default retention period, you can extend this by configuring archive rules or other scheduled data cleanup jobs. However, it’s crucial to understand the implications, as extending retention for temporary data might impact performance and storage. It’s generally best practice to let temporary tables purge as designed unless there’s a very specific business requirement.”

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

Answer: “The key difference lies in where the data resides and how it’s accessed. With normal tables, the data is stored directly within your ServiceNow instance’s database. When you query these tables, you’re retrieving data from your local instance. Remote tables, however, are essentially pointers or integrations to data that resides *outside* your ServiceNow instance, often in another database or application. When you query a remote table, ServiceNow fetches the live data from that external source in real-time. This is achieved through mechanisms like data sources and transform maps, or sometimes via specific integration technologies.”

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

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

• One-to-Many Relationship: This is the most common. It means one record in Table A can be associated with *many* records in Table B, but each record in Table B is associated with only *one* record in Table A. A classic example is the relationship between the sys_user table and the incident table. One user can have many incidents, but each incident is assigned to only one user (the caller). This is implemented by placing a reference field to Table A on Table B.
• One-to-One Relationship: In ServiceNow, true one-to-one relationships are less common and often achieved by placing a unique reference field on one table that points to the other, or by extending a table. For instance, a custom ‘User Profile’ table might have a reference field back to the sys_user table, and you’d ensure only one profile exists per user, making it effectively one-to-one.
• Many-to-Many Relationship: One record in Table A can be associated with *many* records in Table B, *and* one record in Table B can be associated with *many* records in Table A. This is typically implemented using an intermediary or ‘join’ table. An example is the relationship between incident and sys_user via the sys_user_incident table (though more commonly seen with groups), or more directly, between incident and sys_group. An incident can be assigned to multiple groups, and a group can be assigned to multiple incidents.

It’s also worth noting that ServiceNow has built-in many-to-many relationship capabilities, for example, when associating multiple tasks to a single parent record.

”

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

Answer: “There are numerous ways to create records:

1. Forms: The most common way, by manually filling out a form and submitting it.
2. Record Producers: Catalog items that create records in backend tables.
3. Scripts: Using GlideRecord (as we’ve seen in previous examples).
4. Email: Inbound email actions can create records based on incoming emails.
5. Imports: Using Import Sets and Transform Maps from files like Excel or CSV.
6. Integrations: Via REST APIs or SOAP web services from external systems.
7. UI Actions: Custom buttons or links that trigger record creation.
8. Workflows: Activities within a workflow can create records.

“

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

Answer: “You can achieve mandatory and read-only field states in several ways:

1. Dictionary Properties: For a field to be always mandatory or read-only, you can set these properties directly in the field’s Dictionary Entry.
2. Dictionary Overrides: If a field is on a parent table and you want to change its behavior (e.g., make it mandatory) in a child table, you use a Dictionary Override.
3. UI Policies: These execute on the client-side and can dynamically set fields as mandatory, read-only, visible/invisible, or change their values based on conditions.
4. Data Policies: Similar to UI Policies but can execute on both client and server sides, enforcing mandatory or read-only states more robustly.
5. Client Scripts (g_form.setMandatory() / g_form.setReadOnly()): For dynamic control in client scripts, you can use these methods to programmatically set the mandatory or read-only state of fields.
6. Access Control Lists (ACLs): For controlling write access (making a field read-only) at a more granular security level.

“

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

Answer: “You can have multiple fields marked as ‘Display’ in a table’s dictionary entry. However, it’s strongly discouraged and considered bad practice. ServiceNow’s ‘Display’ field is intended for identifying a record in a user-friendly way in related lists, choice lists, and search results. If you have more than one, it can lead to confusion and inconsistent behavior, especially in how records are represented. Typically, there should only be one primary display field per table.”

44. Where are all tables stored?

Answer: “All table definitions in ServiceNow are stored in a system table called sys_db_object. This table contains metadata about every table in the instance, including its name, label, columns, and other configuration details.”

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

Answer: “You can set a default value for a field in a couple of primary ways:

1. Dictionary Entry: The most straightforward method is to define a ‘Default value’ directly in the Dictionary Entry for the field. This value will be pre-populated whenever a new record is created for that table.
2. UI Policies/Client Scripts: You can also use UI Policies or Client Scripts to set a default value dynamically when a form loads, based on certain conditions.
3. Business Rules: For server-side default values, a business rule can set a default value on insert.

Using the Dictionary Entry is generally preferred for static default values.”

46. What is the current object?

Answer: “The current object is a fundamental server-side object in ServiceNow. It represents the record that is currently being processed in a server-side script (like a business rule, workflow activity, or script include). You use it to get and set values for the fields on that specific record before it’s saved to the database or updated.”

47. How to set field values on the current form (server-side)?

Answer: “On the server-side, you use the current object to set field values:

• current.setValue('field_name', value);: This is used for most field types. For reference fields, you provide the sys_id of the target record as the value.
• current.setDisplayValue('field_name', value);: This is useful for reference fields. You can set the display value directly (e.g., the username for a reference to sys_user) without needing to look up the Sys ID. ServiceNow will handle the backend lookup.

For example:

current.setValue('state', 1); // Sets the state field to 'New' (assuming 1 is the value for New)
current.setValue('assigned_to', '62826bf03710200044e0bfc8bcbe5df1'); // Assigning to a specific user
current.setDisplayValue('assigned_to', 'Abel Tutor'); // Setting the display value for assignment
    

”

48. What are reference qualifiers, and their types? Explain each one and the differences.

Answer: “Reference qualifiers are used to dynamically filter the records that can be selected in a reference or list field. They restrict the choices a user sees, making data selection more accurate and efficient.

Types of Reference Qualifiers:

1. Simple Reference Qualifier:

• Description: This is the most basic type. You define a fixed query string directly in the reference field’s Dictionary Entry, similar to a WHERE clause in SQL.
• Example: To show only active users in a reference field pointing to the sys_user table, you’d set the qualifier to active=true.
• Use Case: Filtering based on static conditions.

2. Dynamic Reference Qualifier:

• Description: This type uses a predefined ‘Dynamic Filter Option’ which can adapt its query based on the context of the form or user. These dynamic filter options are managed under System Definition.
• Example: Displaying only users who are members of the *same assignment group* as the current record’s assignment group.
• How to Use: Create a Dynamic Filter Option (e.g., “Users in current assignment group”) and then select it in the reference field’s Dictionary Entry.
• Use Case: Filtering based on context-aware conditions, often related to other fields on the form.

3. Advanced Reference Qualifier (JavaScript Reference Qualifier):

• Description: This is the most powerful type, allowing you to write custom JavaScript code that generates the query string dynamically. It can handle complex logic, cross-table lookups, and leverage client-side scripting.
• Example: Filtering a list of configuration items (CIs) to show only those managed by the current user’s department and that are in a ‘production’ environment.
• How to Use: In the reference field’s Dictionary Entry, select ‘Advanced’ for the reference qualifier and enter your JavaScript code. The script must return a valid query string.
• Example Script Snippet: javascript: 'assignment_group=' + g_form.getValue('assignment_group') + '^state=production'; (This example is client-side; server-side advanced qualifiers are also possible and often more performant for complex logic.)

Differences:

• Simple vs. Dynamic: Simple is static; Dynamic adapts based on system configurations (Dynamic Filter Options).
• Dynamic vs. Advanced: Dynamic uses pre-built filter options. Advanced lets you write custom JavaScript for maximum flexibility, handling complex logic that predefined options might not cover.
• Simple vs. Advanced: Simple uses a static query string. Advanced uses JavaScript to build a query string, allowing for dynamic conditions based on script logic.

”

49. What is a dependent value?

Answer: “Dependent values are a configuration in the field’s Dictionary Entry that creates a cascading effect in dropdowns. When a user selects a value in one field (the parent field), the choices available in another field (the dependent field) are filtered to show only relevant options. This is widely used for creating intuitive dropdown menus, for example, selecting a ‘Category’ first, and then having the ‘Subcategory’ field only show subcategories related to the chosen category.”

50. What is a calculated value?

Answer: “A calculated value is set up in a field’s Dictionary Entry where the field’s value is automatically computed based on a script. When the record is saved or updated, the specified script runs, and the result of that script becomes the value for the field. This is useful for fields that need to dynamically derive their value from other fields, such as calculating a due date based on an open date and a duration.”

V. ServiceNow Configuration & Customization

This section covers various configuration elements and customization techniques used by developers.

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

Answer: “Attributes are special parameters added to a Dictionary Entry (for fields or tables) that modify the behavior or appearance of that field or table. They act like modifiers or flags. Some attributes I’ve frequently used include:

• no_email: Prevents email notifications from being sent for updates to this field.
• no_attachment: Disables the attachment functionality for a specific field or the entire form.
• no_add_me: Used in assignment groups to prevent users from adding themselves.
• tree_picker: Configures a reference field to appear as a tree structure, useful for hierarchical data.
• ref_auto_completer=...: Controls the auto-completion behavior in reference fields.
• readonly: Makes a field read-only.
• mandatory: Makes a field mandatory.
• collapse_filtered_list: Used on list fields.

”

52. What is a collection field on a table?

Answer: “In the context of a table’s Dictionary Entries, a collection field entry actually represents the table itself, not a field on the table. When you configure attributes or set properties like ‘Read only’ on a collection field entry, these settings apply to the entire table. For example, using the no_attachment attribute on the collection entry for the incident table would disable attachments for all incident records. This entry is automatically created when a table is created.”

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

Answer: “You can disable attachments on a form by using the no_attachment attribute. This attribute is typically added to the collection field entry for the table (e.g., the Dictionary Entry for the incident table itself). By adding no_attachment to the ‘Attributes’ field of the collection’s Dictionary Entry, you prevent users from adding attachments to records of that table.”

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

Answer: “A dictionary override allows you to change the behavior or attributes of a field that is inherited from a parent table for a specific child table. This is incredibly powerful for tailoring standard fields to specific application needs without altering the original OOB table. You can override almost any property of the original dictionary entry, including:

• Default value
• Mandatory flag
• Read-only flag
• Display flag
• Max length for strings
• Reference qualifier
• Attributes
• Display Value
• Calculation script
• Choice list specifications

For example, you might make the ‘priority’ field mandatory on the incident table, even though it’s optional on the parent task table.”

55. What are application menus?

Answer: “Application menus, often referred to as modules, are navigation items that appear in the ServiceNow application navigator (the left-hand side menu). They provide end-users and administrators with easy access to specific forms, lists, or other content within an application. You create an application menu to make your custom tables, reports, or dashboards discoverable and accessible.”

56. What is a process flow?

Answer: “A process flow (often visually represented as a ‘Process Flow Designer’ or a ‘Flow Designer’ visual) provides a graphical representation of the stages or steps involved in a particular workflow or process. It helps users understand the current status of a record as it moves through its lifecycle, showing which stages are complete, which are active, and which are upcoming. This is often seen on forms for tasks, incidents, or changes.”

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 entered in other fields on the same form. For example, if a user selects a ‘Department’ and a ‘Location’, a data lookup rule could automatically populate the ‘Support Group’ field based on a predefined mapping. They are configured separately from UI/Data Policies and offer a dedicated way to manage these auto-population scenarios.”

58. What are UI policies?

Answer: “UI Policies are client-side scripts that dynamically control the behavior of form fields. They are a low-code alternative to client scripts for common tasks. You can use them to make fields mandatory, read-only, visible or invisible, set field values, and even display related lists, all based on specific conditions evaluated on the client-side when the form loads or when field values change.”

59. What is the ‘Global’ checkbox in UI policies?

Answer: “When the ‘Global’ checkbox is checked on a UI Policy, it means the UI Policy will be evaluated and applied across all views of the form. If it’s unchecked, you’ll be prompted to specify a particular view (or views) where the UI Policy should apply. This allows for view-specific form behaviors.”

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

Answer: “The ‘Reverse if false’ checkbox is a powerful feature of UI Policies. When checked, it means that if the conditions of the UI Policy evaluate to false, the actions defined in the UI Policy will be reversed. 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 is false. This simplifies defining opposing behaviors.”

61. What is the ‘On Load’ checkbox in UI policy?

Answer: “The ‘On Load’ checkbox determines whether the UI Policy’s conditions and actions are evaluated and applied immediately when the form initially loads. If checked, the UI Policy runs as soon as the form is rendered. If unchecked, the UI Policy’s actions will only be triggered when a specific event occurs (like a field value changing) that meets the UI Policy’s conditions.”

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

Answer: “When the ‘Inherit’ checkbox is checked on a UI Policy, it means that the same UI Policy will be applied to any child tables that extend the table on which the UI Policy is defined. This is a great way to propagate UI behavior down the table hierarchy without having to recreate policies for each child table.”

63. Can you write scripts in UI policies?

Answer: “Yes, you absolutely can. To enable scripting within a UI Policy, you need to check the ‘Run scripts’ checkbox. This option is available on the UI Policy itself. Once enabled, you can write scripts in the ‘On Load’, ‘On Change’, or ‘On Submit’ sections of the UI Policy. This allows for more complex client-side logic that goes beyond simple field manipulations.”

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

Answer: “Yes, ServiceNow provides a convenient way to convert UI Policies into Data Policies. When you are viewing a UI Policy, there is often a related link or button like ‘Convert this UI Policy to a Data Policy’. Clicking this will create a corresponding Data Policy based on the UI Policy’s conditions and actions.”

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

Answer: “While conversion is generally possible, there are scenarios where a UI Policy’s actions cannot be directly replicated by a Data Policy, or where a Data Policy isn’t the right tool:

• Controlling Data Visibility (Client-side UI Elements): UI Policies can hide/show fields or sections on the form (client-side UI). Data Policies operate on the data itself, not the visual elements of the UI.
• Controlling Views: UI Policies can sometimes be used to manipulate view-specific elements, which is outside the scope of Data Policies.
• Controlling Related Lists: UI Policies can show or hide related lists based on conditions, a UI element not managed by Data Policies.
• Complex Client-Side Scripting: If a UI Policy relies heavily on complex client-side JavaScript interactions that don’t directly translate to data manipulation (e.g., custom UI components), direct conversion might not be feasible.
• UI Actions and Related Links: Directly manipulating UI Actions or Related Links based on conditions is typically done via UI Policies or Client Scripts.

”

66. What are data policies?

Answer: “Data Policies are server-side (and can execute client-side) scripts that enforce data integrity and consistency across all data sources. They make fields mandatory, read-only, or set their values based on conditions, regardless of whether the data is entered via a form, an integration, an email, or a script. This provides a more robust way to ensure data quality compared to UI Policies, which are primarily client-side and can be bypassed.”

This comprehensive list should give you a solid foundation for your ServiceNow developer interviews. Remember to practice these answers, think about real-world scenarios where you’ve applied these concepts, and be ready to elaborate. Good luck!