This question assesses your awareness of the latest releases. A confident answer would be:

“As of my last update, I’m familiar with the Washington DC release, which is the latest. I’m always keen to stay updated with ServiceNow’s rapid release cycle.”

This question gauges your experience trajectory. A good answer might be:

“I began my journey with ServiceNow during the Rome release. Since then, I’ve had the opportunity to work with subsequent versions like San Diego, Tokyo, Utah, Vancouver, and most recently, Washington DC. This progression has given me a great perspective on how ServiceNow evolves.”

Permissions in ServiceNow are primarily managed through Roles. You can assign roles directly to users or to groups, which then inherit those roles.

Best Practice: The recommended and most scalable approach is to assign roles to groups. When an employee leaves the organization or their role changes, you simply remove them from the relevant group(s). This automatically revokes their access without needing to individually update each user’s role assignment. It simplifies administration and reduces the chance of orphaned permissions.

How it works: Roles define what a user can see and do. Groups are collections of users. Assigning a role to a group means all members of that group inherit that role’s permissions.

The primary table that stores user information in ServiceNow is:

This table holds details like username, first name, last name, email, and other user-specific attributes.

The table that links users to groups is:

This is a many-to-many relationship table. A record in this table signifies that a specific user is a member of a specific group.

You can create user accounts programmatically using the GlideRecord API in server-side scripts (like Business Rules, Script Includes, etc.).

Note: Managing passwords directly in scripts is generally discouraged for security reasons. In a real-world scenario, password creation or reset would typically involve more secure mechanisms.

Similar to user creation, you use GlideRecord to create new groups.

Tip: Always use the actual sys_id for fields like ‘manager’ that reference other records.

Permissions are managed by roles. Assigning roles involves inserting records into specific tables:

To a User:

Roles assigned directly to users are stored in the sys_user_has_role table.

To a Group:

Roles assigned to groups are stored in the sys_group_has_role table.

Interview Tip: Emphasize the importance of using sys_ids for references and how assigning roles to groups is the preferred method.

User delegation in ServiceNow allows one user to perform tasks or act on behalf of another user. This is incredibly useful when a user is on leave, on vacation, or otherwise unavailable.

Example: If Sarah, a manager, is going on vacation, she can delegate her approval tasks to her colleague, John. John can then approve or reject requests in ServiceNow as if he were Sarah, ensuring business continuity. This delegation can be time-bound and specific to certain types of tasks (approvals, notifications, etc.).

How to Set Up: The delegating user navigates to their user profile, scrolls down to the ‘Delegates’ related list, and adds the delegate’s name, the start and end dates of the delegation, and specifies the permissions granted (e.g., approvals, notifications).

Interview Relevance: This shows you understand how ServiceNow supports operational continuity and user experience during absences.

Adding and removing members from groups involves manipulating the sys_user_grmember table.

Adding a Group Member:

Removing a Group Member:

To remove a member, you first need to find the specific record in the sys_user_grmember table that links the user and the group, and then delete that record.

Troubleshooting: Ensure you are using the correct sys_ids for both the user and the group. If the query doesn’t find a record, `grMem.next()` will be false, and no deletion will occur.

ServiceNow has evolved its user interface over the years. The main ones you’ll encounter are:

• UI15/UI16: Older, classic interfaces.
• Next Experience UI (previously known as Polaris): The modern, responsive, and user-friendly interface that most newer instances use.

Understanding the differences and how to navigate them can be important, especially if you’re working with older instances or need to support different user experiences.

A “web services user” (often referred to as a “system user” or “integration user”) is a special type of user account in ServiceNow that is primarily used for integrations and automated processes. These users cannot log in to the ServiceNow graphical user interface (GUI) like a regular user. Instead, they are used by external applications or scripts to authenticate and interact with ServiceNow via its APIs (like REST or SOAP).

Key Characteristics:

• Cannot log in via the standard ServiceNow portal.
• Used for programmatic access (e.g., pushing data from an HR system into ServiceNow).
• Typically assigned specific roles required for the integration, adhering to the principle of least privilege.

On the client-side (e.g., within Client Scripts, UI Policies, UI Actions), you can access the current user’s system ID using the global JavaScript object g_user.

Note: `g_user.userID` (or `g_user.getUserID()`) is the client-side equivalent of `gs.getUserID()` on the server.

On the server-side (e.g., within Business Rules, Script Includes, Workflow Scripts), you use the gs (GlideSystem) object.

This is a fundamental method for identifying the user performing an action on the server.

This is a common requirement for security checks and conditional logic. You can use the gs.getUser().isMemberOf() method on the server-side.

Interview Tip: Be ready to explain if you can use a group name or its sys_id. Both are generally supported, but using the sys_id is often more robust against naming changes.

To create, modify, or delete Access Control Lists (ACLs) in ServiceNow, you need the security_admin role.

This is a powerful role, designed to restrict access to security configurations, ensuring that only authorized administrators can make changes that impact system-wide security.

Impersonation in ServiceNow is a feature that allows an administrator or a user with specific privileges (like the impersonator role) to temporarily log in and act as another user. This is an invaluable tool for troubleshooting, testing, and demonstrating functionality from a specific user’s perspective.

Use Cases:

• Testing if a user can see a particular record or menu item.
• Troubleshooting an issue a specific user is experiencing.
• Demonstrating a workflow or feature to a client or colleague as if you were them.

How it works: You typically find an impersonation option in the user menu (often at the top right of the header), where you can select another user to impersonate. You can then perform actions as that user. When done, you ‘stop impersonating’ to return to your own session.

User preferences in ServiceNow allow individual users to customize certain aspects of their interface and experience without affecting other users. These settings are stored per user.

Examples:

• List Columns: Users can personalize which columns appear in list views.
• Theme: Some instances allow users to select preferred color schemes or themes.
• Language: Users can set their preferred language.
• Notification Settings: While many notification settings are controlled by admins, users may have some personal control.

Technical Detail: User preferences are stored in the sys_user_preference table. When a user changes a preference, a record is created or updated in this table for their specific user ID and the preference name.

Interview Relevance: Shows you understand user personalization capabilities within the platform.

An Incident in ServiceNow is defined as an unplanned interruption to an IT service or a reduction in the quality of an IT service. The goal of incident management is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations, ensuring that the best possible levels of service quality and availability are maintained.

In simple terms: When something breaks or stops working as expected for an employee or a service, it’s an incident. The immediate goal is to fix it and get things running again.

Example: An employee cannot print documents, or a critical business application is unavailable. These are incidents.

A Problem in ServiceNow is an underlying cause of one or more incidents. While incident management focuses on restoring service, problem management aims to identify the root cause of recurring incidents and find a permanent solution to prevent them from happening again. A problem record is created when it’s suspected that multiple incidents share a common root cause.

Example: If the same printing issue (an incident) keeps happening to multiple employees, or even repeatedly to the same employee, it might indicate a problem with the print server configuration or a faulty printer driver. A problem record would be created to investigate this underlying cause.

Key Distinction: Incidents are about fixing the immediate impact; Problems are about fixing the root cause to prevent future incidents.

Yes, absolutely. This is a core workflow in IT Service Management (ITSM). When a support engineer is working on an incident and realizes that this incident is part of a recurring issue, or has a suspected underlying root cause that needs investigation, they can create a Problem record directly from the Incident form. Typically, the incident record will then be linked to the newly created problem record.

How: On the Incident form, there’s usually a ‘Create Problem’ button or a related link that allows you to initiate this process. The system pre-populates the problem record with details from the incident.

Yes, this is another common and important workflow. If resolving an incident requires making a change to the IT environment (e.g., updating a server configuration, deploying a new patch, modifying application settings), a Change Request must be created. This ensures that changes are properly planned, authorized, tested, and implemented to avoid introducing new incidents.

How: Similar to creating a problem, there’s typically a ‘Create Change Request’ option on the Incident form. The incident details are carried over to the change request, and the incident might be closed or put on hold pending the completion of the change.

Interview Relevance: Understanding these relationships shows you grasp ITSM processes and how ServiceNow supports them.

Using GlideRecord for creating incidents is a standard practice for automation.

Similar to incidents, problems can be created via script.

Creating change requests programmatically is vital for automated deployment pipelines or integration workflows.

This is a classic scenario for a Business Rule.

Type: After Business Rule

Table: Incident [incident]

When to run: after update

Condition: current.state.changesTo(7) && current.parent == '' (Assuming state 7 is ‘Closed’ and we only want to process top-level incidents that are closing)

Troubleshooting: Ensure the ‘state’ value for ‘Closed’ is correct for your instance. If you encounter infinite loops, verify the condition carefully and consider using `grChild.autoSysFields(false)` and `grChild.setWorkflow(false)` if needed, though often not required for simple state changes.

This is a perfect use case for a Before Business Rule.

Table: Incident [incident]

When to run: before update

Condition: current.state.changesTo(3) (Assuming state 3 is ‘Closed’. Adjust as per your instance’s state values.)

Interview Tip: Mentioning that this needs to be a ‘Before’ business rule to prevent the update is crucial. Also, highlight the use of gs.addErrorMessage() and current.setAbortAction(true).

This is typically handled by an After Business Rule on the Problem table.

Table: Problem [problem]

When to run: after update

Condition: current.state.changesTo(7) (Assuming state 7 is ‘Closed’ for Problems)

Troubleshooting: Make sure the `problem_id` field is correctly populated on the incident when it’s linked to a problem. Also, verify your ‘Closed’ state value for both tables.

These three are fundamental pillars of IT Service Management (ITSM) and are tightly integrated within ServiceNow:

• Incident Management: Focuses on restoring normal service operation as quickly as possible. When an incident occurs, the immediate priority is to resolve the user’s disruption.
• Problem Management: Investigates the root cause of one or more incidents. If an incident (or multiple similar incidents) points to an underlying issue, a problem record is created to find and fix that root cause, preventing recurrence.
• Change Management: Controls the lifecycle of all changes. When a change to the IT infrastructure or services is required (often to resolve a problem or improve a service), a change request is initiated. This ensures changes are evaluated, authorized, scheduled, and implemented in a controlled manner.

The Flow:

1. An Incident is reported due to a service disruption.
2. If the incident is recurring or part of a larger issue, a Problem record is created to find the root cause.
3. To fix the root cause identified in the problem, a Change Request is created to implement the necessary modifications.

This interconnectedness ensures a systematic approach to IT service delivery and improvement.

Out-of-the-box (OOTB) tables are those that are part of the ServiceNow platform by default, without any custom development. They typically do not start with `x_` or `u_` (which denote custom tables).

Examples:

• incident
• problem
• change_request
• sys_user
• sys_user_group
• cmdb_ci (Configuration Item)
• task
• sc_req_item (Requested Item)
• sc_catalog_item (Catalog Item)

Base tables are tables that do not extend (inherit from) any other table. They are the foundation upon which other tables are built. Tables that extend a base table are children of that base table and inherit its fields.

Key Base Tables:

• task: This is a very common base table. Incident, Problem, Change Request, and many other task-oriented records extend the task table. This allows them to share common fields like Assignment Group, State, Assigned To, etc.
• cmdb_ci: The base table for the Configuration Management Database (CMDB). All configuration items (servers, applications, devices, etc.) extend this table.
• sys_security_acl: The base table for Access Control Lists.
• sys_documentation: A base table for form/field definitions.

Interview Tip: Understanding table hierarchies is crucial for understanding how data is structured and shared in ServiceNow.

As mentioned, many records that represent work to be done extend the task base table. These are commonly referred to as “Task tables”.

Examples:

• incident
• problem
• change_request
• sc_task (Service Catalog Task)
• sc_req_item (Requested Item – though it also extends sc_cat_item, it has task-like qualities)
• ப்படுகின்றன (Knowledge Article – often managed with task-like workflows)

These tables inherit fields like short_description, description, state, assignment_group, assigned_to, etc., from the parent task table.

When you create a new table in ServiceNow, by default, four Access Control Lists (ACLs) are automatically generated if the “Create ACLs” checkbox is selected during the table creation process.

These four ACLs typically provide basic CRUD (Create, Read, Update, Delete) permissions, usually allowing users with roles like admin or specific table-level roles to perform these actions.

Important: If you uncheck the “Create ACLs” box, no default ACLs will be generated, and you’ll need to manually create them to grant any access to the new table.

To create an auto-numbering field, like the incident.number, you configure it in the table’s definition and its dictionary entry.

Steps:

1. Table Definition: When creating or editing a table, there’s an “Add a new field” section. For an auto-number field, you’d select “Auto-number” as the Type.
2. Dictionary Entry: Once the field is created (or if you’re modifying an existing one), go to its dictionary entry.
3. Control Tab: Within the dictionary entry, navigate to the “Control” tab.
4. Auto-Number Configuration:
   • Check the “Auto number” checkbox.
   • Define the “Prefix” (e.g., ‘INC’ for incident).
   • Specify the “Number of digits” (e.g., ‘7’ to ensure numbers like INC0000001).

When a new record is inserted into the table, ServiceNow will automatically generate a unique number based on this configuration.

Extending a table (inheritance) means creating a new table that inherits all the fields and properties from a parent table. This is a powerful way to reuse existing data structures and logic.

Key consequences:

• Field Inheritance: The child table automatically gets all the fields from the parent table. You don’t need to recreate them.
• No Sys Fields in Child: System fields like `sys_id`, `created`, `updated`, `sys_updated_by`, etc., are not duplicated in the child table. They reside in the parent table, and the child record is essentially a specific view or extension of the parent’s data.
• ‘Class’ Field in Parent: A field called class is automatically added to the parent table. This field stores the sys_id of the actual table the record belongs to (e.g., for an Incident record, the class field in the `task` table would point to the `incident` table’s `sys_id`).
• Single Class Field: Even if a table extends multiple tables through a complex hierarchy, it will still only have one class field in its ultimate parent table pointing to its specific table type.

Example: Incident extends Task. The Incident table gets all Task fields plus its own specific fields. The Task table gets a ‘class’ field that will identify a record as an Incident.

ServiceNow offers a wide variety of field types to store different kinds of data. Here are 10 common ones:

1. String: For text input (short or long).
2. Integer: For whole numbers.
3. Decimal: For numbers with decimal points.
4. Boolean: For true/false values (often displayed as a checkbox).
5. Date: For storing dates.
6. Date/Time: For storing dates and times.
7. Choice: For predefined lists of options (dropdowns).
8. Reference: To link to another record in a different table (e.g., linking a User field to the sys_user table).
9. List: A many-to-many reference field, allowing a record to be linked to multiple records in another table.
10. Journal: For logging comments or work notes, allowing multiple entries over time.

Other important ones include Email, URL, HTML, Attachment, etc.

The primary difference lies in data persistence and purpose:

• Normal Tables: These are your standard, everyday tables (like incident, sys_user). Data stored in these tables is permanent and persists until explicitly deleted or archived. They are designed for long-term data storage and business operations.
• Temporary Tables: These tables are designed to hold data for a limited period, typically for staging or processing purposes. They often extend the import_set_row table (or similar). Data in temporary tables is automatically purged after a defined retention period (often 7 days, but configurable). They are commonly used during data import processes or for intermediate storage during complex scripting operations.

Use Case: When performing large data imports, you might first import data into a temporary staging table, clean and transform it, and then insert it into your normal business tables.

Yes, you can increase the retention period for data in temporary tables. This is typically managed using Archive Rules or specific system properties that control data purging for temporary storage tables.

While the default is often 7 days, administrators can configure archive rules to retain data for longer periods if required for auditing, historical analysis, or specific compliance needs. However, it’s important to balance this with storage considerations, as prolonged retention can increase database size.

The core difference is where the data resides and how it’s accessed:

• Normal Tables: The data is stored directly within the ServiceNow instance’s database. When you query a normal table, you are querying local data.
• Remote Tables: These are tables that represent data residing in an external system, not within your ServiceNow instance’s database. ServiceNow connects to this external system (e.g., via REST or other integrations) to retrieve or display the data in real-time. The data isn’t stored in ServiceNow; it’s fetched as needed.

Use Case: A remote table could display live inventory data from an external warehouse management system, or customer data from an external CRM, without replicating all that data into ServiceNow. This is often achieved using integrations like REST Message and Scripted REST APIs, or specific Remote Table features.

These terms describe how records in different tables can relate to each other.

• One-to-Many Relationship: This is the most common relationship. It means one record in Table A can be associated with zero, one, or many records in Table B, but each record in Table B is associated with *at most one* record in Table A.

  Example: A User (Table A) can have many Incidents (Table B). Each incident, however, is typically assigned to only one user (the caller or assigned to). This is implemented using a reference field on the “many” side (e.g., caller_id on the incident table referencing the sys_user table).

• Many-to-Many Relationship: This means 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 requires an intermediate “join” table.

  Example: Incidents (Table A) and Groups (Table B). An incident might need to be worked by multiple groups (e.g., network team and server team), and a group (like “IT Support”) works on many different incidents. This relationship is managed by a join table, such as sys_user_group.incident_id or a custom table, where records link specific incidents to specific groups.

• One-to-One Relationship: This is less common but means one record in Table A is associated with exactly one record in Table B, and vice-versa. This is often achieved by having a reference field on one table that points to the other, and then scripting or constraints to ensure only one record can be linked.

  Example: A User record and a User Profile Details record (if stored in a separate table). Each user has one profile details record, and each profile details record belongs to one user.

ServiceNow provides numerous ways to create records, catering to different user types and automation needs:

1. Through Forms: The most common way for end-users and administrators is by navigating to a list and clicking “New” or using the “Create New” module.
2. Via Record Producers: These are special types of catalog items that create records in a target table based on user input from a service catalog form.
3. Using GlideRecord (Server-Side Scripting): As demonstrated in previous examples, this is fundamental for automation via Business Rules, Script Includes, Workflow Scripts, etc.
4. Client-Side Scripting (e.g., g_form.save() with specific logic): While less direct for creating entirely new, independent records without a form context, client scripts can trigger record creation indirectly or update existing ones that then might lead to new record creation.
5. Email Ingestion: ServiceNow can be configured to automatically create records (like Incidents or Requests) from incoming emails.
6. Import Sets / Data Sources (Excel, CSV, etc.): For bulk data loading, you can use Import Sets to map and import data from files like Excel or CSV into ServiceNow tables.
7. External Systems via APIs (REST/SOAP): Other applications can create records in ServiceNow by calling its web service APIs.
8. UI Actions: Custom buttons or links created via UI Actions can also trigger the creation of new records, often based on the context of the current record.

ServiceNow offers multiple mechanisms to control field behavior (mandatory, read-only, display, etc.), depending on whether the control needs to be client-side or server-side:

1. Dictionary Properties: You can set “Mandatory” or “Read only” flags directly on the field’s dictionary entry. This is a global setting for that field.
2. Dictionary Overrides: If a field is inherited from a parent table, you can use a dictionary override on the child table to change its properties (e.g., make an inherited field mandatory in a child table).
3. UI Policies: These are client-side scripts that run on the form. They can make fields mandatory, read-only, visible/hidden, set values, etc., based on conditions evaluated while the form is open.
4. Data Policies: These are similar to UI Policies but can run on both the client and server sides. They enforce data consistency and can make fields mandatory or read-only regardless of how the data is entered (form, import, API).
5. Client Scripts (using g_form.setMandatory(), g_form.setReadOnly()): You can use JavaScript within Client Scripts to dynamically control mandatory and read-only states based on complex logic.
6. Business Rules (Server-Side): While Business Rules primarily enforce server-side logic, they can set field values. For read-only, they typically don’t enforce it directly as a property, but can ensure data integrity. For mandatory, a Before Business Rule can check for values and use current.setAbortAction(true) if a required field is empty.
7. ACLs (Access Control Lists): ACLs can enforce read/write access at a field level, effectively making a field read-only or inaccessible for certain roles.

No, you should not make more than one field as “display” in a table.

The “Display” checkbox on a field’s dictionary entry is used to designate a human-readable field that ServiceNow uses to represent a record when it’s shown in related lists, search results, or as a reference display value. ServiceNow relies on this flag to provide a meaningful representation of a record.

If you check “Display” for multiple fields in the same table, it leads to:

• Ambiguity: ServiceNow won’t know which field to prioritize for display purposes.
• Confusion: Users will see inconsistent or unexpected behavior when referencing records.
• System Errors: It can lead to internal errors or unexpected behavior in searches and related lists.

Therefore, only one field per table should be marked as “Display”. Typically, this is a name or an identifier field.

Information about all tables defined in your ServiceNow instance, including custom tables and out-of-the-box tables, is stored in a meta-data table itself called:

This table contains details about each table, such as its name, label, schema information, and whether it’s active. It’s essentially a catalog of your database schema.

Setting a default value for a field ensures that when a new record is created and the form is loaded, the field is pre-populated with a specific value. This improves user experience and data consistency.

Methods:

1. Dictionary Entry: The most common method. On the field’s dictionary entry, there’s a “Default value” field. You can enter a static value, a JavaScript expression, or a reference to another field’s value.
2. UI Policies: You can set default values as part of a UI Policy’s actions. This allows the default value to be conditional (e.g., set a different default based on the value of another field).
3. Client Scripts: Using g_form.setValue('field_name', 'default_value'); in an OnLoad Client Script. This offers the most dynamic control based on complex client-side logic.
4. Business Rules: In a Before Insert Business Rule, you can set `current.field_name = ‘default_value’;` before the record is saved. This is useful for server-side defaults or values derived from server-side logic.

Example (Dictionary Entry): For a ‘State’ field on an Incident, you might set the default value to ‘1’ (New).

The current object is a fundamental global JavaScript object available in server-side scripts (like Business Rules, Workflow Scripts, Script Includes) when operating on a specific record. It represents the record that is currently being processed.

Key Uses:

• Getting Field Values: You use `current.field_name` to read the value of a field on the current record.
• Setting Field Values: You use `current.setValue(‘field_name’, value);` to change a field’s value on the current record before it’s saved.
• Accessing Record Information: You can get the sys_id (`current.sys_id`), table name (`current.getTableName()`), and other record-level properties.

Analogy: Think of it as the “record you’re holding in your hand” during a server-side operation.

You’re asking about setting values on the current record in server-side scripting. If you mean setting values on the client-side form, that’s handled by g_form.

Server-Side (using current object):

• For most field types:

  current.setValue(‘field_name’, ‘your_value’);

• For Reference fields: You must provide the sys_id of the referenced record.

  current.setValue(‘assigned_to’, ‘USER_SYS_ID’);

• To set the display value for a Reference field (useful when inserting related data but want ServiceNow to display it correctly):

  current.setDisplayValue(‘assigned_to’, ‘John Doe’);

  // Note: setDisplayValue is less common for setting *default* values in server scripts and more for manipulation during complex logic or transformations.

Client-Side (using g_form object):

• For most field types:

  g_form.setValue(‘field_name’, ‘your_value’);

• For Reference fields: You must provide the sys_id.

  g_form.setValue(‘assigned_to’, ‘USER_SYS_ID’);

• To set the display value for a Reference field:

  g_form.setDisplayValue(‘assigned_to’, ‘John Doe’);

Interview Relevance: The distinction between current.setValue() (server) and g_form.setValue() (client) is critical.

Reference Qualifiers are powerful tools used to filter the list of available choices in a reference or list field. They restrict the records that a user can select, making data entry more efficient and accurate.

Types of Reference Qualifiers:

1. Simple Reference Qualifier

Description: This is the most straightforward type. It uses a simple, hardcoded query condition based on field values in the referenced table. It’s ideal for static filtering.

How to Use: You define conditions directly in the “Reference qualifier” field of the reference field’s dictionary entry. These conditions follow ServiceNow’s query builder syntax.

Example: To show only active users in a reference field pointing to the sys_user table, you would set the qualifier to:

Or to show users in a specific department:

2. Dynamic Reference Qualifier

Description: This type uses a dynamically generated query that can adapt based on the context of the current record or user. It leverages “Dynamic Filter Options” to create reusable filter logic.

How to Use:

1. Create a “Dynamic Filter Option” under System Definition > Dynamic Filter Options.
2. Define the conditions and make it available for use in reference qualifiers.
3. In the reference field’s dictionary entry, select the “Dynamic” radio button and choose your created Dynamic Filter Option.

Example: Displaying only incidents assigned to the same assignment group as the current user.

Difference from Simple: A simple qualifier is static. A dynamic qualifier can adapt based on the current form’s context (e.g., the logged-in user’s group, or values in other fields on the form). It’s more flexible than a hardcoded query but less complex than advanced JavaScript.

3. Advanced Reference Qualifier (JavaScript Reference Qualifier)

Description: This is the most powerful and flexible type. It uses custom JavaScript code to define complex, dynamic queries. It allows for intricate filtering logic that can depend on multiple fields, related records, and complex calculations.

How to Use: In the reference field’s dictionary entry, select the “Advanced” radio button and enter your JavaScript code. The code must return a valid query string.

Example: Filtering the cmdb_ci table to show only Configuration Items that are in a specific location AND are of a particular type.

Or a more complex example using gs.getUserID():

Differences Summarized:

• Simple vs. Dynamic: Simple is static. Dynamic uses pre-defined “filter options” which can be somewhat contextual.
• Dynamic vs. Advanced: Dynamic uses pre-defined options. Advanced allows you to write custom JavaScript for ultimate flexibility.
• Simple vs. Advanced: Simple is a fixed query string. Advanced is a JavaScript function that generates the query string, enabling dynamic logic and context-aware filtering.

Interview Tip: Be prepared to explain *why* you would choose one over the other. Simple for basic filters, Dynamic for reusable contextual filters, and Advanced for complex, custom logic.

Dependent Values in ServiceNow refer to the configuration where the available options in one field (the dependent field) are filtered based on the selection made in another field (the parent field). This is a crucial mechanism for creating cascaded dropdowns and ensuring data relevance.

How it Works:

1. Identify Parent and Dependent Fields: Determine which field’s selection will control the choices in another field.
2. Configure the Parent Field: Ensure the parent field has a set of defined choices (e.g., a Choice list field).
3. Configure the Dependent Field:
   • Go to the dictionary entry of the dependent field.
   • In the “Dependent Field” attribute, specify the name of the parent field.
   • For each choice in the dependent field, you can link it to a specific value of the parent field. This is often done in the “Dependent value” field of the choice’s definition.

Example:

Parent Field: Category on the Incident table (e.g., values: “Hardware”, “Software”, “Network”).

Dependent Field: Subcategory on the Incident table.

When you configure the choices for Subcategory:

• Choice: “Laptop”, Dependent value: “Hardware”
• Choice: “Printer”, Dependent value: “Hardware”
• Choice: “Operating System”, Dependent value: “Software”
• Choice: “Application”, Dependent value: “Software”
• Choice: “Router”, Dependent value: “Network”

When a user selects “Hardware” for Category, the Subcategory dropdown will only show “Laptop” and “Printer”. If they select “Software”, it will show “Operating System” and “Application”.

Technical Note: This configuration is often managed within the Choice list of the dependent field, where you can specify the parent field and the dependent value for each choice.

A calculated value in ServiceNow refers to a field whose value is not entered directly by a user but is automatically computed based on a formula or other field values. This is typically achieved through the field’s dictionary entry.

How it works:

1. Go to the dictionary entry of the field you want to make calculated.
2. On the “Control” tab, you’ll find a “Calculation” field.
3. Enter a JavaScript expression or a simple formula in this field.

Example:

If you have a “Total Price” field on a custom table, and you have “Quantity” and “Unit Price” fields, you can make “Total Price” a calculated field:

In the “Calculation” field for “Total Price”, you would enter:

Whenever the “Quantity” or “Unit Price” fields are updated and the record is saved, the “Total Price” will automatically recalculate.

Note: For more complex calculations that involve multiple steps, server-side logic (like Business Rules) might be more appropriate.

Attributes in ServiceNow are key-value pairs (or just keys) that can be added to a field’s dictionary entry or to a table’s definition (collection field) to modify or control its behavior or appearance. They provide a way to extend functionality without extensive scripting.

Where they are used:

• Field Dictionary Entry: To control field-specific behavior.
• Collection Field Dictionary Entry (Table Definition): To control table-level behavior.

Examples of Attributes I Have Used:

• no_email: Prevents email notifications from being sent for changes to this field. Useful for fields that are automatically updated or not relevant for notifications.
• no_attachment: Prevents users from attaching files to records of this table. Added to the collection field definition.
• tree_picker: Transforms a reference field into a tree-like picker, useful for hierarchical selections (e.g., selecting a location from a company hierarchy).
• ref_auto_completer=...: Controls the auto-completion behavior for reference fields.
• readonly: Makes a field read-only (similar to setting read-only in dictionary, but can be dynamic).
• required: Makes a field mandatory (similar to setting mandatory in dictionary).

Interview Relevance: Demonstrates understanding of configuration options beyond basic field properties.

A collection field in the context of a table’s dictionary entry actually refers to the table itself, not a field on the table. When you look at the dictionary entry where the “Type” is “Collection”, it represents the table definition, not a specific data field within the table.

Purpose: Any attributes or properties set on this “Collection” dictionary entry apply to the entire table, rather than a single field. This is where you would configure table-level settings.

Example:

• Adding the no_attachment attribute to the Collection field’s dictionary entry disables attachments for all records in that table.
• Setting table-level ACLs or other metadata.

Automatic Creation: When a new table is created, ServiceNow automatically generates a dictionary entry of type “Collection” for it.

You can enable or disable the attachment functionality for a form (table) by using an attribute on the collection field’s dictionary entry.

• To Disable Attachments:

Navigate to the Dictionary entry for the table (where Type is “Collection”). In the “Attributes” field, add the attribute:

no_attachment

This will hide the attachment paperclip icon and prevent users from adding attachments to any record of this table.

• To Enable Attachments:

If attachments were previously disabled using no_attachment, you simply remove this attribute from the collection field’s dictionary entry. By default, attachments are enabled.

A Dictionary Override is a configuration that allows you to modify the properties of a field in a child table without altering the original field definition in its parent table. This is essential for customization when you need a field to behave differently in a specific extended table.

Purpose: Imagine the priority field on the base task table. It might have default values and behaviors. If, for the incident table, you need the priority field to have different default values, different choices, or be mandatory, you create a Dictionary Override for the priority field on the incident table.

Properties that can be overridden: You can override most of the properties found in a field’s dictionary entry, including:

• Default value: Set a different default value for the field in the child table.
• Mandatory: Make the field mandatory or optional.
• Read only: Make the field read-only or editable.
• Display: Change whether it’s a display field (though best practice is one display field per table).
• Max Length: Restrict the maximum character length.
• Choices: Define a different set of choices for a Choice field.
• Reference Specification: Modify reference qualifiers or related lists.
• Attributes: Add or remove attributes.
• Help text: Change the help text shown to users.
• Label: Change the field’s display label.

Example: You can override the priority field in the incident table to make it mandatory, whereas on the base task table, it might not be mandatory.

Application Menus in ServiceNow are navigational elements that appear in the main application navigator (the left-hand side menu). They are used to organize modules (which link to forms, lists, reports, etc.) into logical groups, providing users with easy access to different parts of the platform.

Purpose:

• Organization: Group related modules under a common application (e.g., “Incident” application menu containing modules like “Open Incidents”, “All Incidents”, “Create New”).
• Navigation: Allow users to quickly find and access the forms, lists, and other functionalities they need.
• Access Control: Application Menus and their associated modules can be controlled by roles, ensuring users only see applications and modules they are authorized to access.

When you create a new custom application or configure existing ones, you define Application Menus and then create Modules within them.

A Process Flow (also known as a “Flow Designer flow” or sometimes referred to in context of older “Process Flow Designer”) visually represents the steps and stages of a business process. It helps users understand the current status of a record and the sequence of actions required to complete a workflow.

Key Characteristics:

• Visual Representation: Typically shown as a series of boxes or stages on a form, indicating the current step and upcoming steps.
• Workflow Guidance: Guides users through a defined process, ensuring they complete tasks in the correct order.
• Status Indicator: Clearly shows where a record stands within its lifecycle.

Example: On an Incident form, a process flow might show stages like “New”, “In Progress”, “On Hold”, “Resolved”, and “Closed”. As the incident’s state changes, the flow visual updates to reflect its current stage.

Data Lookups in ServiceNow provide a way to automatically populate fields on a form based on values entered in other fields on the same form. They are configured in a separate table (sys_data_lookup) and define mappings between source field values and target field values.

Purpose: To reduce manual data entry and ensure consistency by automatically filling in related information. This is often used to populate fields like Assignment Group, Caller information, or Category/Subcategory based on initial selections.

How it works:

1. You define a Data Lookup Rule.
2. Specify the Source Table (usually the table the form is on).
3. Define Source Fields and their values.
4. Specify the Target Table and Target Fields to populate.
5. When a user enters values in the source fields on a form, ServiceNow checks the data lookup rules. If a match is found, it populates the specified target fields.

Example: If a user selects “Network” as the Category and “Router” as the Subcategory on an Incident, a data lookup rule could automatically set the “Assignment Group” to “Network Operations”.

UI Policies are a powerful client-side scripting mechanism in ServiceNow used to dynamically change the behavior and appearance of form fields. They are an alternative to Client Scripts for many common form manipulations, offering a more user-friendly, low-code approach.

Key Actions UI Policies can perform:

• Make fields mandatory.
• Make fields read-only.
• Set fields to visible/hidden.
• Set default values for fields.
• Set the order of fields.
• Show or hide related lists.

How they work: UI Policies are based on conditions. When the conditions are met on a form, the defined actions are executed. They are ideal for controlling what users see and can do on a form in real-time.

Example: A UI Policy might make the “Resolution Notes” field mandatory only when the Incident’s “State” changes to “Resolved”.

The “Global” checkbox in a UI Policy determines whether the UI Policy applies to all views of a form or only to a specific view.

• When Checked (Global = True): The UI Policy’s conditions and actions will be evaluated and applied regardless of which view the user is currently using to access the form. This is the most common setting for general form behavior.
• When Unchecked (Global = False): If unchecked, you will be prompted to specify which View(s) the UI Policy should apply to. The UI Policy will then only execute when the form is viewed using one of those specified views. This is useful for tailoring form behavior for different user roles or specific workflows that utilize custom views.

Interview Relevance: Shows understanding of how to control form behavior across different user interfaces (views).

The “Reverse if False” checkbox in a UI Policy is a crucial setting that dictates what happens to the UI Policy’s actions when the defined condition evaluates to false.

• If Checked: When the UI Policy’s condition is NOT met (evaluates to false), the actions that were applied when the condition was true will be reversed. For example, if a field was made mandatory when the condition was true, it will become optional again when the condition is false. If a field was set to visible, it will become hidden.
• If Unchecked: When the condition is false, the UI Policy’s actions have no effect. Any previous state of the fields remains as it was. For instance, if a field was made mandatory and the condition later becomes false, it will remain mandatory.

Example: Consider a UI Policy that makes a “Discount Amount” field mandatory only when “Discount Percentage” is checked. If “Reverse if False” is checked, when “Discount Percentage” is unchecked, the “Discount Amount” field will revert to being not mandatory. If “Reverse if False” is unchecked, it would remain mandatory even after “Discount Percentage” is unchecked.

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

• If Checked: The UI Policy runs as soon as the form is opened. This is useful for setting initial states, default values, or making fields mandatory/read-only right from the start.
• If Unchecked: The UI Policy does NOT run when the form is first loaded. Its conditions and actions will only be triggered when a specific event occurs on the form, such as a field value changing (an “on change” event).

Use Cases:

• On Load Checked: Set the initial state of fields, ensure required fields are marked correctly from the moment the form appears.
• On Load Unchecked: Implement dynamic behavior that reacts to user input as they fill out the form (e.g., showing additional fields only when a certain option is selected).

The “Inherit” checkbox on a UI Policy (and also on Data Policies) determines whether that UI Policy will be applied to child tables that extend the table on which the UI Policy is defined.

• If Checked: The UI Policy will be inherited by child tables. This means if you create a UI Policy on the task table, and the incident table extends task, the UI Policy will also run on the incident form.
• If Unchecked: The UI Policy will only apply to the table it is defined on and will NOT be inherited by child tables.

Benefit: This allows administrators to define common UI behaviors once at a base table level and have them automatically applied to all extended tables, promoting consistency and reducing redundant configuration.

Example: A UI Policy on the task table to hide a specific field named “Internal Notes” for all users who do not have a particular role. If this UI Policy has “Inherit” checked, it will also apply to Incidents, Problems, and Changes.

Yes, you can write scripts within UI Policies, but it’s important to understand where and how.

UI Policies primarily operate through “UI Policy Actions”. For each UI Policy Action, there is an option to enable “Run scripts”.

How it works:

1. Create a UI Policy with your conditions.
2. Define UI Policy Actions (e.g., make a field mandatory, set it to read-only).
3. For a specific UI Policy Action, enable the “Run scripts” checkbox.
4. You can then enter client-side JavaScript code in the “Script” field that will execute when the UI Policy’s conditions are met and this specific action is triggered.

Use Cases for Scripts in UI Policies:

• More complex logic for setting field values than simple defaults.
• Dynamically controlling the visibility or behavior of multiple fields based on intricate conditions.
• Calling other client-side functions.

Interview Tip: While UI Policies are low-code, their scripting capability makes them very powerful. However, for very complex client-side logic, dedicated Client Scripts might sometimes be preferred for better organization.

Yes, you can convert a UI Policy into a Data Policy. ServiceNow provides a convenient feature to do this.

How:

1. Open the UI Policy you wish to convert.
2. Look for a related link or a button, often labeled “Convert to Data Policy” or similar.
3. Clicking this will prompt you to confirm the conversion. ServiceNow will then create a new Data Policy based on the conditions and actions defined in your UI Policy.

Benefit: This is useful because Data Policies can run on both the client and server, offering broader data consistency enforcement than UI Policies, which are purely client-side.

While most UI Policies can be converted, there are certain functionalities that are inherently client-side and cannot be directly translated into a Data Policy (which also needs server-side applicability). These include:

• Controlling Data Visibility (Display/Hide): UI Policies can make fields visible or hidden. Data Policies are primarily for data integrity (mandatory, read-only) and don’t control UI visibility.
• Controlling Views: UI Policies can sometimes be used to adjust form layout or related lists based on views, a function not directly handled by Data Policies.
• Controlling Related Lists: Making related lists visible or hidden based on conditions is a UI-specific action.
• Controlling Script Execution (within UI Policy Actions): If a UI Policy Action relies on custom client-side JavaScript (e.g., calling specific client-side functions, manipulating complex DOM elements) that doesn’t directly map to data enforcement, it may not convert well.
• Setting Field Order: UI Policies can reorder fields on a form, a purely visual client-side action.

If your UI Policy’s primary function is to manipulate the user interface’s appearance or behavior, it’s less likely to be a direct candidate for Data Policy conversion. Data Policies are best suited for enforcing data constraints (mandatory, read-only) across all data entry points.

Data Policies in ServiceNow are server-side (and can be client-side) rules that enforce data integrity by making fields mandatory or read-only based on specific conditions. They are a robust way to ensure data consistency across all data sources – whether the data is entered via a form, an integration, or an API.

Key Features:

• Enforce Data Constraints: Make fields mandatory or read-only.
• Cross-Platform: They apply consistently whether the record is being accessed via the desktop UI, mobile UI, or through APIs. This is their main advantage over UI Policies, which are purely client-side.
• Conditions: Like UI Policies, they are driven by conditions.

Use Cases:

• Ensuring critical fields (like Configuration Item or Category) are always filled in for Incidents.
• Making a “Resolution Notes” field read-only once an Incident is in a “Resolved” state, regardless of how the state was changed.

Data Policy UI Actions: Data Policies also have “Data Policy Rules” which define the specific actions (like making a field mandatory or read-only) to be performed when the Data Policy’s conditions are met.