Top 10 ServiceNow Virtual Agent Interview Questions You Need to Master
So, you’re gearing up for a ServiceNow Virtual Agent (VA) interview? That’s fantastic! The VA platform is a game-changer for automating workflows and enhancing user experience within ServiceNow. As organizations increasingly adopt AI-powered solutions, skilled VA developers and administrators are in high demand. To help you navigate those crucial interview moments, we’ve compiled a list of frequently asked questions, complete with practical explanations and real-world context. Think of this as your cheat sheet to confidently ace that interview and land your dream role.
These questions aren’t just about memorizing facts; they’re designed to gauge your understanding of ServiceNow’s architecture, scripting capabilities, and best practices, especially as they relate to building intelligent and efficient virtual agents. Let’s dive in!
1. Which is the current version you are working on in ServiceNow?
Answer: Washington DC – the latest one.
This is a straightforward question, but it’s important to be honest and up-to-date. Knowing the latest release (as of your interview, of course!) demonstrates your engagement with the platform’s evolution. It also helps the interviewer understand your exposure to new features and functionalities.
Interview Relevance:
Shows you’re current with the platform. Different versions have different features and APIs, so your answer might influence follow-up questions about specific capabilities.
2. From which version did you start working?
Answer: Rome, San Diego, Tokyo, Utah, Vancouver, Washington DC.
This question explores your experience depth. Listing the versions you’ve worked with highlights your journey and the breadth of your exposure to ServiceNow’s development over time. It’s particularly useful if you’ve worked through several major upgrades, as this implies a deeper understanding of how the platform evolves and how to manage those transitions.
Interview Relevance:
Demonstrates the range of your experience and your ability to adapt to platform changes across different releases.
3. Can we add permissions to users and groups? Which is the best practice?
Answer: Yes, we can add roles to users and groups manually and also via script using GlideRecord. The best practice is to add permissions to groups. This way, when an employee leaves the organization, and they are removed from the group, their roles are automatically removed.
Permissions in ServiceNow are primarily managed through Roles. Assigning roles directly to users can become a management nightmare, especially in large organizations. Best practice dictates leveraging groups. When a user is added to a group, they inherit all the roles assigned to that group. Conversely, when they are removed from the group, those inherited roles are also removed. This significantly simplifies user access management and reduces the risk of orphaned permissions.
Interview Relevance:
This question tests your understanding of fundamental ServiceNow security models and your ability to articulate best practices for efficient and secure user access management, which is critical for any application, including Virtual Agents.
4. What is the user table name?
Answer: sys_user
A fundamental question about the core data model. The `sys_user` table is where all user information is stored in ServiceNow. Knowing this is crucial for any scripting or data manipulation involving users.
Interview Relevance:
Basic but essential. If you’re going to build or configure anything related to users, you need to know where their data lives.
5. What is the group member table name?
Answer: sys_user_grmember
This table defines the relationship between users and groups. Each record in `sys_user_grmember` signifies that a particular user is a member of a specific group. This is your go-to table for querying group memberships.
Interview Relevance:
Essential for scripting scenarios involving group memberships, such as checking if a user belongs to a specific group or adding/removing users from groups.
6. How to create a user account using a script?
Answer: By using GlideRecord as follows:
var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username = 'jdoe';
userGr.first_name = 'John';
userGr.last_name = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.insert();
This demonstrates your ability to programmatically create records. `GlideRecord` is the workhorse for server-side scripting in ServiceNow. Here, we initialize a new record in the `sys_user` table, set the necessary fields, and then `insert()` it into the database.
Interview Relevance:
Proves your scripting proficiency in a core ServiceNow area. This is applicable for automated user provisioning or data import scenarios.
7. How to create a group using a script?
Answer: By using GlideRecord as follows:
var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Testing Group'; // More descriptive name
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Replace with actual sys_id of a user
newGr.email = 'testing@example.com'; // Use a valid email format
newGr.description = 'This is a test group for demonstration purposes.';
newGr.insert();
Similar to creating a user, this shows you can manage group data via scripting. You’d typically need the `sys_id` of a manager for the `manager` field. Remember to replace placeholder `sys_id` values with actual ones from your instance.
Interview Relevance:
Again, demonstrates scripting skills for administrative tasks. Useful for automated group creation, perhaps based on other system data.
8. How to add permissions to a user/group account using a script?
Answer:
To a User: When a permission (Role) is added to a user account, a record in the `sys_user_has_role` table is created. You can add a role to a user via script as follows:
var userRole = new GlideRecord('sys_user_has_role');
userRole.setValue('user', 'USER_SYS_ID'); // Replace with actual user sys_id
userRole.setValue('role', 'ROLE_SYS_ID'); // Replace with actual role sys_id
userRole.insert();
To a Group: When a permission (Role) is added to a group, a record is created inside the `sys_group_has_role` table. You can add a role to a group via script as follows:
var grpRole = new GlideRecord('sys_group_has_role');
grpRole.setValue('group', 'GROUP_SYS_ID'); // Replace with actual group sys_id
grpRole.setValue('role', 'ROLE_SYS_ID'); // Replace with actual role sys_id
grpRole.insert();
Note: Always replace placeholder `sys_id` values with actual ones from your ServiceNow instance. You can obtain these by right-clicking on a record and selecting “Copy sys_id” or by inspecting URL parameters.
Interview Relevance:
This is a crucial question for understanding how roles are programmatically assigned. It’s fundamental for setting up access for Virtual Agents and ensuring they have the necessary permissions without granting too much.
9. What exactly does user delegation mean in ServiceNow?
Answer: User delegation means allowing a user to act on behalf of another user within an organization. This is generally used when the original user is unavailable, such as on vacation or leave. The delegated user gets permissions to perform tasks and can also access resources normally available to the original user.
For example, if an employee is going on vacation, they can delegate their approval tasks to a colleague. This ensures that important tasks and workflows continue smoothly without interruption. To set this up, you navigate to the original user’s account, scroll down to “Delegates,” and provide details such as the delegate’s name, start and end dates, and specific permissions (assignments, notifications, approvals).
Interview Relevance:
Understanding delegation is important for designing VA flows that can handle situations where key users are out of office, ensuring business continuity.
10. How to add and remove a group member from a group using a script?
Answer:
Adding a Group Member:
var grMem = new GlideRecord('sys_user_grmember');
grMem.user = 'USER_SYS_ID'; // Replace with actual user sys_id
grMem.group = 'GROUP_SYS_ID'; // Replace with actual group sys_id
grMem.insert();
Removing a Group Member:
var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', 'USER_SYS_ID'); // Replace with actual user sys_id
grMem.addQuery('group', 'GROUP_SYS_ID'); // Replace with actual group sys_id
grMem.query();
if (grMem.next()) {
grMem.deleteRecord(); // Correct method for deleting a GlideRecord
}
Again, remember to substitute `USER_SYS_ID` and `GROUP_SYS_ID` with actual ServiceNow system IDs.
Interview Relevance:
Essential for automated user provisioning and de-provisioning, or for managing group memberships dynamically within VA workflows.
11. How many user interfaces are there in ServiceNow?
Answer: UI15, UI16, and Next Experience UI.
ServiceNow has evolved its user interface over time. UI15 and UI16 were previous iterations, and the Next Experience UI (often referred to as “Polaris” or the “new UI”) represents the latest modern design.
Interview Relevance:
Shows awareness of the platform’s user experience evolution. For VA development, understanding how the UI impacts user interaction is key.
12. What is meant by a web services user in a User account?
Answer: A web services user is an account granted access solely to a third-party application to connect to ServiceNow. This user cannot log in as a regular ServiceNow user into the platform.
These users are typically used for integrations where an external system needs to interact with ServiceNow via its web services APIs (like REST or SOAP) without requiring a full user license or the ability to navigate the ServiceNow UI.
Interview Relevance:
Crucial for understanding integration patterns and security. Virtual Agents often integrate with external systems, so knowing how to manage those connections securely is vital.
13. How to get the current logged-in user’s system ID on the client side?
Answer: g_user.userID;
This client-side JavaScript global variable `g_user` provides access to information about the currently logged-in user. `g_user.userID` specifically returns the `sys_id` of that user.
Interview Relevance:
Fundamental for client-side scripting in ServiceNow, which is often used in UI Policies, Client Scripts, and Service Portal widget development, all of which can interact with or be leveraged by Virtual Agents.
14. How to get the current logged-in user’s system ID on the server side?
Answer: gs.getUserID();
On the server-side (e.g., in Business Rules, Script Includes, or Workflow scripts), the `gs` (GlideSystem) object provides the `getUserID()` method to retrieve the `sys_id` of the current user. This is the equivalent of `g_user.userID` on the client side.
Interview Relevance:
Essential for server-side scripting, which powers much of the backend logic for Virtual Agents, including data retrieval, updates, and complex decision-making.
15. How to check if the current logged-in user is a member of a particular group or not?
Answer: gs.getUser().isMemberOf(‘group name’); // Returns true if part of the specified group, false otherwise.
This is a very handy server-side method. You can pass either the group name or its `sys_id` to `isMemberOf()`. This is frequently used in access control logic or to personalize VA interactions based on user group membership.
Interview Relevance:
Vital for conditional logic in VA topics and flows. You can tailor responses or trigger specific actions based on whether a user belongs to a certain support group, for instance.
16. Which role is required to work on access control?
Answer: security_admin
The `security_admin` role is the master key to managing Access Control Lists (ACLs) in ServiceNow. Without this role, you cannot create, modify, or delete ACLs, which are fundamental to securing records and fields.
Interview Relevance:
Understanding ACLs is paramount for securing sensitive data that your Virtual Agent might access or display. It ensures your VA adheres to security policies.
17. What is impersonation?
Answer: Logging in as another user for testing purposes.
Impersonation allows administrators or developers to temporarily log in as another user to test functionalities, troubleshoot issues, or verify permissions from that user’s perspective. It’s a critical tool for accurate testing and debugging.
Interview Relevance:
When building VA experiences, you’ll need to test how they behave for different user roles and permissions. Impersonation is your best friend for this.
18. What is user preference?
Answer: Users can change their preferences based on their wish. When a user changes their preferences, it only impacts that specific user and not globally.
User preferences are individual settings that a user can configure to personalize their ServiceNow experience. Examples include setting their default landing page, notification settings, or even UI theme. These settings are stored in the `sys_user_preference` table and are tied to the specific user.
Interview Relevance:
While not directly tied to VA core functionality, understanding user preferences can help in designing VA interactions that respect user customizations or even allow users to set VA-specific preferences.
19. What is an incident?
Answer: A sudden interruption in service. If an employee experiences something that suddenly stops working while they are working, they get support from a support engineer by creating an incident.
An incident is a record that captures an unplanned interruption to an IT service or a reduction in the quality of an IT service. The primary goal of incident management is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations.
Interview Relevance:
Virtual Agents are often used to log, triage, and resolve incidents. Understanding the incident lifecycle and its relationship with other ITSM processes is key.
20. What is a problem?
Answer: If the same issue is repeatedly happening to the same employee, it’s called a problem. If the same problem is happening to multiple people at the same time, it’s an incident, where we create a parent incident and the rest are child incidents. When you close the parent incident, the child incidents will also be closed.
A problem is a cause of one or more incidents. The purpose of problem management is to identify the root cause of incidents and then find a workaround or a permanent solution to prevent future occurrences. When a recurring issue is identified, a problem record is created, and related incidents are linked to it.
Interview Relevance:
Virtual Agents can help identify recurring issues by analyzing incident patterns and can even initiate the problem management process. Understanding this relationship is crucial for building comprehensive VA solutions.
21. Can we create a problem record from an incident?
Answer: Yes, if the issue is repeatedly occurring, we will create a problem from an incident.
This is a standard workflow in IT Service Management. If a support engineer is working on an incident and realizes that the underlying cause is recurring or complex, they can escalate it by creating a linked problem record directly from the incident form.
Interview Relevance:
Shows your understanding of ITSM workflows and how Virtual Agents can automate or streamline these escalations.
22. Can we create a change request from an incident?
Answer: Yes, whenever you create an incident, if the support engineer feels that some change in the software is required, they will raise a change request from that incident.
Similarly, if resolving an incident requires modifying the production environment (e.g., a software update, configuration change), a change request is initiated. This ensures that changes are managed, approved, and implemented in a controlled manner.
Interview Relevance:
Another key ITSM integration. A VA could guide users through troubleshooting that might lead to a change request, or an agent could use a VA to initiate this process.
23. How to create an incident record using a script?
Answer: Using GlideRecord as follows:
var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = 'USER_SYS_ID'; // Replace with actual caller sys_id
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'CI_SYS_ID'; // Replace with actual CI sys_id
gr.short_description = 'Test record via script';
gr.description = 'Detailed description of the test incident.';
gr.assignment_group = 'GROUP_SYS_ID'; // Replace with actual assignment group sys_id
gr.insert();
This script demonstrates how to create a new incident programmatically. It involves initializing a `GlideRecord` for the `incident` table and then populating key fields like `caller_id`, `category`, `short_description`, and `assignment_group` before inserting the record.
Interview Relevance:
Core scripting knowledge. This is essential for automating incident creation, perhaps from VA conversations or integrations.
24. How to create a problem record using a script?
Answer: Using GlideRecord as follows:
var gr = new GlideRecord('problem');
gr.initialize();
gr.caller_id = 'USER_SYS_ID'; // Replace with actual caller sys_id
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'CI_SYS_ID'; // Replace with actual CI sys_id
gr.short_description = 'Test problem via script';
gr.description = 'Detailed description of the test problem.';
gr.assignment_group = 'GROUP_SYS_ID'; // Replace with actual assignment group sys_id
gr.insert();
Similar to incident creation, this script shows how to create a problem record using `GlideRecord`. The fields and structure are analogous to incident creation, reflecting the close relationship between the two.
Interview Relevance:
Demonstrates your ability to manage problem records programmatically, which can be useful for automating problem identification and creation based on incident trends.
25. How to create a change request using a script?
Answer: Using GlideRecord as follows:
var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'CI_SYS_ID'; // Replace with actual CI sys_id
gr.short_description = 'Test change request via script';
gr.description = 'Detailed description of the test change.';
gr.assignment_group = 'GROUP_SYS_ID'; // Replace with actual assignment group sys_id
gr.insert();
This script illustrates creating a change request. Note that the fields and their purpose can differ slightly from incident and problem records, reflecting the distinct workflow of change management.
Interview Relevance:
Crucial for understanding how to automate the initiation of changes, which might be triggered by VA interactions or identified issues.
26. Write a logic for whenever a parent incident is closed, all the child incidents should also be closed.
Answer: Write an After Business Rule
When: After
Update: true
Condition: current.state.changesTo(7); // Assuming 7 is the value for ‘Closed’ state
Script:
if (current.state == 7 && current.parent == '') { // Check if it's a top-level incident being closed
var grChild = new GlideRecord('incident');
grChild.addQuery('parent', current.sys_id);
grChild.query();
while (grChild.next()) {
grChild.state = 7; // Set the state to Closed
grChild.update(); // Update the child incident
}
}
Troubleshooting: Ensure the state value for ‘Closed’ is correct for your instance. If not, update `current.state.changesTo(7)` and `grChild.state = 7;` accordingly. Verify that child incidents correctly reference their parent using the `parent` field.
Interview Relevance:
This demonstrates your ability to implement complex business logic using Business Rules, a core ServiceNow feature. Automating closures ensures data consistency and process adherence, which a VA might trigger or be part of.
27. There is an incident, and that incident has associated 2 tasks. When you try to close that incident, if any incident task is open, the employee should not be able to close the incident. Similarly, for problem and change request.
Answer: Use a Before Business Rule or an Access Control List (ACL)
Option 1: Before Business Rule (Recommended for user experience)
When: Before
Update: true
Condition: current.state.changesTo(3); // Assuming 3 is the value for ‘Closed’ state
Script:
var grTask = new GlideRecord('incident_task'); // Or 'problem_task', 'change_task'
grTask.addQuery('incident', current.sys_id); // Or 'problem', 'change_request'
grTask.addQuery('state', '!=', 3); // Assuming 3 is the state for 'Closed'
grTask.query();
if (grTask.hasNext()) {
gs.addErrorMessage('Cannot close the record because there are open tasks.');
current.setAbortAction(true);
}
Option 2: ACL (More restrictive, impacts all operations)
Create a `write` ACL on the `incident`, `problem`, or `change_request` table. In the “Advanced” tab, add a script that checks for open tasks.
// Example for Incident Write ACL
var grTask = new GlideRecord('incident_task');
grTask.addQuery('incident', current.sys_id);
grTask.addQuery('state', '!=', 3); // Closed state
grTask.query();
if (grTask.hasNext()) {
answer = false; // Prevent write operation
} else {
answer = true; // Allow write operation
}
Troubleshooting: Ensure you are using the correct table names for tasks (`incident_task`, `problem_task`, `change_task`) and the correct state values for ‘Closed’ on both the main record and the tasks. For ACLs, careful testing is crucial to avoid blocking legitimate operations.
Interview Relevance:
This question highlights your understanding of business rules and ACLs for enforcing process integrity. Virtual Agents need to adhere to these business rules, so demonstrating this knowledge is key.
28. Whenever a problem is closed, the associated incident will also get closed?
Answer: Use an After Business Rule
When: After
Update: true
Condition: current.state.changesTo(7); // Assuming 7 is the value for ‘Closed’
Script:
if (current.state == 7) {
var grIncident = new GlideRecord('incident');
grIncident.addQuery('problem_id', current.sys_id);
grIncident.addQuery('state', '!=', 7); // Assuming 7 is the state for 'Closed'
grIncident.query();
while (grIncident.next()) {
grIncident.state = 7; // Set the state to Closed
grIncident.update(); // Update the incident
}
}
Troubleshooting: Verify the state value for ‘Closed’ in your instance. Ensure that incidents correctly link to their problem using the `problem_id` field. Be mindful of potential infinite loops if not correctly implemented (e.g., if closing an incident triggers a problem closure, which then tries to close the same incident again).
Interview Relevance:
Another scenario testing your ability to implement inter-process dependencies using Business Rules. This reinforces your understanding of ITSM workflows and automation.
29. What is the relationship between incident, problem, and change management?
Answer: If a person faces some issue, they will create an incident. If the same issue happens again and again, they will create a problem. If the support team feels that some changes are required in their software, they will create a change request.
Essentially:
- Incident: Addresses an immediate disruption to service. Goal: Restore service quickly.
- Problem: Investigates the root cause of recurring incidents. Goal: Prevent recurrence.
- Change Request: Manages modifications to the IT environment. Goal: Implement changes safely and efficiently.
An incident might lead to a problem investigation. A problem resolution might involve implementing a change. A change might inadvertently cause incidents.
Interview Relevance:
This is a foundational ITSM question. For Virtual Agents to be effective in an IT context, they need to understand these core processes and how to interact with them.
30. Give me some names of out-of-the-box tables.
Answer: The tables that don’t start with `x_` or `u_` are called out-of-the-box. Examples: `incident`, `problem`, `change_request`, `sc_cat_item`, `sys_user`, `sys_group`.
Tables starting with `x_` or `u_` typically indicate custom tables created within scoped applications or global custom applications, respectively. Out-of-the-box tables are those provided by ServiceNow itself.
Interview Relevance:
Tests your familiarity with ServiceNow’s data structure and terminology. Essential for understanding where core data resides.
31. What are some of the base tables?
Answer: `task`, `cmdb_ci`. These are tables that don’t extend any other table but are extended by many tables.
`task` is a prime example, as `incident`, `problem`, and `change_request` all extend it, inheriting its common fields. `cmdb_ci` (Configuration Item) is another base table crucial for the Configuration Management Database.
Interview Relevance:
Understanding base tables is key to comprehending table hierarchies and inheritance in ServiceNow, which affects how data is structured and accessed.
32. Give me some examples of task tables.
Answer: `incident`, `problem`, `change_request`. These are examples of tables that extend the `task` table.
These tables share common fields like Assignment Group, State, Assigned to, Due Date, etc., due to their inheritance from the `task` base table.
Interview Relevance:
Reinforces your understanding of table extensions and how common fields are managed across different record types.
33. Whenever we create a table, how many access controls will get created?
Answer: By default, 4 ACLs are created if the “Create Access Control” checkbox is checked during table creation. If unchecked, no default ACLs are created.
These default ACLs typically cover `read`, `write`, `create`, and `delete` operations, providing a basic level of security out-of-the-box. You’ll often need to customize these further.
Interview Relevance:
Shows awareness of how security is applied when creating new data structures. Crucial for ensuring your Virtual Agent interacts with custom tables securely.
34. How to create a number field, like incident number?
Answer: You need to go to the “Control” tab of the field’s dictionary entry and provide a prefix and the number of digits. You also need to check the “Auto number” field when creating the field or table.
For the `incident` table, this setting is pre-configured. For custom tables, you’d define this in the field’s dictionary entry. The “Auto number” feature ensures unique, sequential numbering for records.
Interview Relevance:
Understanding how to create unique identifiers is important for any system that relies on distinct records, including those managed by a Virtual Agent.
35. What happens when you extend a table?
Answer: When you extend a table, the system fields (like sys_created_on, sys_updated_on, etc.) are not recreated in the child table; they are inherited from the parent. A field called “class” will be created in the parent table. If a table extends multiple tables, it will still have only one “class” field, referencing its direct parent.
Extending tables promotes data reusability and maintains a clear hierarchy. The `class` field is essential for distinguishing which specific table a record actually belongs to when multiple tables might be queried.
Interview Relevance:
Deep dive into ServiceNow’s data modeling. Understanding inheritance is vital for efficient database design and querying, which impacts VA performance.
36. Can you give me 10 field types?
Answer: Reference, String, List, Choice, Email, Date/Time, Date, Boolean, Integer, Journal, Attachment.
These are common and essential field types used across ServiceNow to store various kinds of data.
Interview Relevance:
Basic but crucial knowledge for understanding how data is structured and how you can leverage different field types in your Virtual Agent design.
37. What is the difference between a temporary and a normal table?
Answer: Temporary tables store data temporarily for 7 days and they extend the `import_set_row` table. Normal tables store data permanently.
Temporary tables are typically used for staging data during imports or for short-term processing. Once their purpose is served, the data is automatically purged. Normal tables are for persistent data.
Interview Relevance:
Understanding different storage mechanisms helps in designing efficient data handling for your VA, especially if it involves temporary data processing or imports.
38. Can we increase the retention period in a temporary table?
Answer: Yes, by using archive rules.
While temporary tables are designed for short-term storage, archive rules can be configured to retain data for longer periods if necessary, effectively overriding the default purging behavior.
Interview Relevance:
Shows an understanding of data lifecycle management within ServiceNow.
39. What is the difference between a remote table and a normal table?
Answer: With a remote table, you get live data from an external source. In a normal table, you have the data that you have stored within ServiceNow.
Remote tables are often used with features like Virtual Assistan Integration Hub’s Spoke integrations, where data is pulled directly from an external system in real-time, rather than being stored locally in ServiceNow.
Interview Relevance:
Important for understanding integrations and how Virtual Agents can leverage external data sources.
40. What is a one-to-one and one-to-many table relationship in ServiceNow?
Answer:
- One-to-Many Relationship: Users and Incidents, where one user can have multiple incidents, but each incident is assigned to one user.
- Many-to-Many Relationship: Incidents and Groups, where an incident can be associated with multiple groups, and a group can be associated with multiple incidents.
In ServiceNow, these relationships are established using reference fields (for one-to-many) and many-to-many fields (often managed via intermediate tables like `sys_user_has_role` or custom many-to-many tables).
Interview Relevance:
Fundamental database design concepts. Understanding these relationships is key to designing efficient and accurate data models for your Virtual Agent and its interactions.
41. In how many ways can we create a record in a ServiceNow table?
Answer: Record producer, email, GlideRecord (server-side script), form (manual entry), Excel sheet (import), and from an external system (integrations).
This question assesses your knowledge of various data input methods into ServiceNow, highlighting your understanding of different workflows and integration possibilities.
Interview Relevance:
Virtual Agents can trigger record creation through various means, so knowing these methods is essential for designing flexible VA flows.
42. In how many ways can we make a field mandatory, read-only?
Answer: From dictionary properties, dictionary overrides, UI Policies, Data Policies, and `g_form.setMandatory()` (client-side script).
Each method has its use case: dictionary properties for global defaults, UI/Data Policies for conditional client/server-side enforcement, and scripting for dynamic control.
Interview Relevance:
Crucial for form design and user experience. Virtual Agents often interact with forms, and ensuring fields are correctly set as mandatory or read-only enhances data integrity and usability.
43. Can we make 2 fields as display in one table?
Answer: No, you should not make 2 fields display because it will lead to confusion.
The “Display” checkbox in a dictionary entry is intended for a single field that uniquely identifies a record in a reference lookup. Having multiple “Display” fields would create ambiguity and break standard UI behavior.
Interview Relevance:
Tests your understanding of fundamental ServiceNow UI behavior and data modeling best practices.
44. All tables will be stored where?
Answer: `sys_db_object` table.
This meta-table contains definitions of all tables within the ServiceNow instance, including out-of-the-box tables and custom tables.
Interview Relevance:
A deep dive into ServiceNow’s internal data dictionary. Understanding this helps in querying table information programmatically.
45. How to set a default value on a field?
Answer: You can set default values in the dictionary entry for the field, or use UI Policies, Data Policies, or client-side scripts (`g_form.setDefaultValue()`).
Setting a default value pre-populates a field when a new record is created, saving users time and ensuring consistency.
Interview Relevance:
Important for streamlining user input and ensuring that common fields have sensible initial values, a pattern that Virtual Agents can also leverage.
46. What is the current object?
Answer: It is used to set and get values on the form at the server side.
The `current` object in server-side scripts (like Business Rules) refers to the record being processed (inserted, updated, deleted, etc.). You use `current.setValue()` or `current.field_name` to access and modify field values.
Interview Relevance:
Fundamental for server-side scripting. All backend automation involving record manipulation relies on understanding and using the `current` object.
47. How to set the field values on the current form?
Answer:
- `current.setValue(‘field_name’, value);` – For most field types, including reference fields where you provide the `sys_id`.
- `current.setDisplayValue(‘field_name’, value);` – Useful for reference fields where you want to set the display value (e.g., the user’s name) directly, rather than their `sys_id`.
Troubleshooting: When using `setValue` for reference fields, always ensure you are passing the correct `sys_id`. If you pass a display value, it might not work or could lead to data corruption. `setDisplayValue` is generally safer for display-friendly input.
Interview Relevance:
Essential scripting knowledge for manipulating data at the server side, directly impacting how records are created or updated by your Virtual Agent.
48. What are reference qualifiers, and their types? Explain each one in detail and what is the difference between simple and dynamic, dynamic and advanced, simple and advanced.
Answer: Reference Qualifiers are used to restrict the data displayed in reference and list type fields.
3 Types of Reference Qualifiers:
- Simple Reference Qualifier:
- Description: The most basic form, where you specify a fixed query to filter referenced records.
- Example: Displaying only active users in a reference field: `active=true`.
- How to Use: Set the reference qualifier condition directly in the reference field’s dictionary entry.
- Difference: Static and predefined; doesn’t change based on form context.
- Dynamic Reference Qualifier:
- Description: Uses a dynamically generated query that adapts based on the context, such as values of other fields on the form.
- Example: Displaying only incidents assigned to the same assignment group as the current user.
- How to Use: Create a Dynamic Filter Option via System Definition > Dynamic Filter Options and then select it in the reference field’s dictionary entry.
- Difference: Context-aware but uses a predefined dynamic filter option. Less flexible than advanced for complex logic.
- Advanced Reference Qualifier (JavaScript Reference Qualifier):
- Description: Uses custom JavaScript code for complex queries. Allows dynamic filtering based on multiple conditions and the current context.
- Example: Filtering Incidents to show only those assigned to the current user’s group and with a priority less than 3: `javascript: ‘assignment_group=’ + g_form.getValue(‘assignment_group’) + ‘^priority<3’;` (Client-side) or `javascript: ‘assignment_group=’+gs.getUser().getMyGroups()[0] + ‘^priority<3';` (Server-side, simplified example).
- How to Use: Select “Advanced” in the reference qualifier and enter JavaScript code.
- Difference: Most flexible, allows arbitrary JavaScript logic. Can be client-side or server-side.
Key Differences:
- Simple vs. Dynamic: Simple is static. Dynamic is context-aware but limited by predefined options.
- Dynamic vs. Advanced: Dynamic uses predefined dynamic filters. Advanced allows custom JavaScript for ultimate flexibility.
- Simple vs. Advanced: Simple is a fixed query. Advanced allows complex, dynamic logic through scripting.
Interview Relevance:
This is a crucial question for understanding how to refine user input and ensure data accuracy. Virtual Agents often use reference fields, and qualifiers are key to making them user-friendly and efficient.
49. What is a dependent value?
Answer: Dependent values in a dictionary entry are used to filter the available choices in one field based on the selection made in another field. This is commonly used for creating cascaded dropdown menus.
Steps to Configure:
- Identify Parent and Dependent Fields: Determine which field is the parent (e.g., Category) and which is dependent (e.g., Subcategory).
- Configure the Parent Field: Ensure it has a list of possible values.
- Configure the Dependent Field: In its dictionary entry, set the “Dependent Field” attribute to the parent field. Then, define choices for the dependent field, linking them to specific parent field values.
Example:
- Parent Field: Category (values: Hardware, Software, Network)
- Dependent Field: Subcategory (dependent on Category)
- Define Subcategory choices:
- If Category = Hardware: Laptop, Desktop, Printer
- If Category = Software: Operating System, Application, Database
- If Category = Network: Router, Switch, Firewall
The Subcategory dropdown dynamically updates based on the Category selection.
Interview Relevance:
Dependent values are vital for creating intuitive user interfaces. Virtual Agents can leverage this to guide users through complex selections, ensuring they pick valid combinations.
50. What is a calculated value?
Answer: If we want to calculate a field value based on other field values using the `current` object, we use a calculated Dictionary Property.
When you configure a field’s dictionary entry, you can set its “Type” to “Calculated” and then provide a script. This script runs server-side to compute the field’s value based on other fields in the same record.
Interview Relevance:
Demonstrates understanding of server-side data manipulation and how to derive values dynamically, which can be a feature of VA responses or data collection.
51. What are attributes, and name some of the attributes that you have used?
Answer: Attributes are used to change the field behavior on dictionary entries (fields). Examples: `no_email`, `no_attachment`, `no_add_me`, `tree_picker`, `ref_ac_columns`, `ref_ac_columns_search`, `url_type`, `reference_qual`, `display`.
Attributes provide a way to add extra functionality or modify the default behavior of fields without complex scripting.
Interview Relevance:
Attributes are a powerful, low-code way to customize ServiceNow UI and behavior. Understanding them is key to efficient development, including for Virtual Agent forms or data capture.
52. What is a collection field on a table?
Answer: Dictionary entries with the “Collection” type represent the table itself rather than a field on the table. Changes made to this entry (like attributes or read-only checkboxes) apply to the entire table. This entry is automatically created when a table is created.
The collection record essentially defines the table’s metadata. For example, you can apply table-level attributes here.
Interview Relevance:
Understanding the meta-structure of tables is important for advanced administration and development.
53. How to enable/disable attachment on the form using attributes?
Answer: In the collection field’s dictionary entry, add the `no_attachment` attribute.
Adding `no_attachment=true` to the collection field’s attributes will disable the attachment icon and functionality for all records of that table.
Interview Relevance:
Practical application of attributes for controlling form behavior, relevant if your VA needs to manage attachments in specific ways.
54. What are dictionary overrides, and what properties can we override?
Answer: Use a dictionary override to allow a field in a child table to have a different value or behavior than the same field in a parent table. For example, a dictionary override can change the default value of the priority field from 4 (in the parent table) to 5 (in the Incident table).
You can override many properties, including Default value, Maximum length, Mandatory, Read only, Display, Choice list specification, and more.
Interview Relevance:
Dictionary overrides are crucial for customizing inherited fields in child tables. This ensures that fields behave correctly within the context of specific applications like those powered by Virtual Agents.
55. What are application menus?
Answer: To make forms and lists available to end-users, we can create modules in ServiceNow using application menus.
Application menus (also known as modules) are shortcuts that appear in the left-hand navigation menu, providing users with direct access to specific forms, lists, or other application functionalities.
Interview Relevance:
Essential for making your Virtual Agent’s capabilities discoverable and accessible to users. You might create a module to link to a VA chat window or a VA-triggered process.
56. What is a process flow?
Answer: Process flow is an indication to show the state of the form we are currently on.
Process flows visually guide users through a multi-step process, showing which stage they are in and what the next steps are. They are often used for complex workflows like change management or incident resolution.
Interview Relevance:
Virtual Agents can be designed to mimic or interact with process flows, providing a guided experience for users.
57. What are data lookup rules?
Answer: To populate field values based on field values on the form, it’s a separate table.
Data lookup rules automate the population of fields based on matching criteria from other fields. For example, when a user selects a location, data lookups can automatically populate their department or cost center.
Interview Relevance:
Another powerful tool for automating data entry and ensuring accuracy, which can be leveraged by Virtual Agents to gather information efficiently.
58. What are UI policies?
Answer: UI policies are used to make a field mandatory, read-only, display, or to show related lists based on certain conditions on the client side.
They provide a dynamic and user-friendly way to control form behavior without writing JavaScript for every condition.
Interview Relevance:
Crucial for creating interactive and user-friendly forms that Virtual Agents interact with. UI policies enhance the user experience by dynamically adjusting forms based on user input.
59. What is the global checkbox in UI policies?
Answer: When this box is checked, the UI policy will work on all views. When unchecked, it asks you to give the view name, and in that case, the UI policy will work only on that specific view.
This allows you to control the scope of your UI policies, ensuring they apply universally or only to specific user interface contexts.
Interview Relevance:
Important for managing UI policy behavior across different parts of the ServiceNow platform, ensuring your VA interactions are consistent.
60. What is “Reverse if false” in UI policies?
Answer: If the “Reverse if false” checkbox is selected, the actions applied by the UI Policy will be reversed when the condition evaluates to false. For example, if a field was made mandatory when the condition was true, it will become optional again when the condition is false.
This feature simplifies UI policy creation by automatically handling the reset of actions when the primary condition is no longer met.
Interview Relevance:
A key aspect of UI policy logic that helps maintain dynamic form states correctly, which is important for user-driven interactions initiated by a VA.
61. What is the “On Load” checkbox in a UI policy?
Answer: When the “On Load” checkbox is selected, the conditions and actions specified in the UI Policy are evaluated and applied immediately when the form is loaded. If not selected, the UI Policy actions will not be applied when the form is initially loaded; they will only be triggered when a specific field or condition is met on the form.
This determines whether the UI policy’s logic runs once when the form first appears or continuously as the user interacts with the form.
Interview Relevance:
Ensures that forms are correctly configured from the moment they are displayed, which is essential for a smooth VA experience.
62. What is the “Inherit” checkbox?
Answer: When this checkbox is checked, the same UI policy will be applied to child tables as well, meaning tables that extend the table on which the UI policy was applied.
This is a powerful inheritance feature that reduces redundancy by allowing UI policies defined on a parent table to automatically apply to its child tables.
Interview Relevance:
Crucial for maintaining consistency across related tables, a common pattern in ITSM processes that Virtual Agents interact with.
63. Can you write script in a UI policy?
Answer: Yes, you can write scripts in a UI Policy. To do so, you need to enable the “Run scripts” checkbox.
Once you enable “Run scripts” for a UI policy action, you can enter client-side JavaScript code that will execute when the UI policy’s conditions are met.
Interview Relevance:
This is a key differentiator between UI policies and UI policy actions. Knowing when and how to use scripts within UI policies allows for more complex and dynamic form behaviors, which can enhance VA interactions.
64. Can we convert a UI policy into a data policy?
Answer: Yes, you can convert a UI policy into a data policy. To do this, open the data policy and click on “Convert this UI policy to a data policy” (or a similar option).
This conversion is possible for many UI policies, effectively transferring the logic to a data policy which operates on both client and server sides.
Interview Relevance:
Shows an understanding of different automation tools in ServiceNow and their convertibility, which can lead to more robust and efficient solutions for VA data handling.
65. Which are all the cases where a UI policy cannot be converted as a data policy?
Answer: When you are controlling data visibility (e.g., showing/hiding fields based on user roles directly, which is better handled by ACLs), when you are controlling views, when you are controlling related lists, or when the UI policy heavily relies on client-side-only scripting that cannot be easily translated to server-side logic.
Data policies are generally preferred for enforcing data integrity at the server level, while UI policies excel at client-side presentation logic.
Interview Relevance:
Understanding the limitations and strengths of different tools is critical for choosing the right approach for your Virtual Agent’s requirements.
66. What are data policies?
Answer: Data policies are used to make fields mandatory, read-only, or visible based on certain conditions across all data sources. They work on both the client and server sides.
Unlike UI policies (which are client-side), data policies enforce data consistency regardless of how the record is accessed (forms, imports, APIs, etc.).
Interview Relevance:
Data policies are fundamental for ensuring data integrity. Virtual Agents can benefit from data policies to ensure the information they collect or process is validated consistently, whether submitted through a form or via API calls.
Mastering these questions will significantly boost your confidence and preparedness for your ServiceNow Virtual Agent interview. Remember to explain your answers clearly, provide context where possible, and demonstrate your understanding of best practices. Good luck!