Question: Which is the current version you are working on in ServiceNow?

Answer: “I’m currently working with the Washington DC release, which is the latest. Prior to that, my experience spans across Rome, San Diego, Tokyo, Utah, and Vancouver. This continuous engagement with recent releases ensures I’m up-to-date with the latest features and best practices.”

Interview Relevance: This question gauges your current exposure and the breadth of your experience across different releases. Mentioning the latest version shows you’re actively engaged, and listing previous versions highlights your journey and adaptability.

Question: Can we add permissions to users and groups? Which is the best practice?

Answer: “Absolutely! Permissions in ServiceNow are managed through roles. You can assign roles directly to individual users, or more effectively, assign roles to groups. The clear best practice is to manage permissions through groups. Here’s why: When an employee leaves the organization or changes roles, you simply remove them from the relevant groups. This automatically revokes all the associated permissions, significantly reducing the risk of orphaned access and simplifying administration. Manually assigning roles to individual users becomes cumbersome and error-prone at scale.”

Interview Relevance: This probes your understanding of security principles and administration. The focus on groups highlights your grasp of efficiency and maintainability.

Question: What is the user table name?

Answer: “The user table in ServiceNow is named sys_user.”

Question: What is the group member table name?

Answer: “The table that links users to groups, essentially storing group membership, is sys_user_grmember.”

Interview Relevance: Fundamental knowledge of core tables is crucial. This shows you know where the system stores essential data.

Question: How to create a user account using a script?

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();
                

Question: How to create a group using a script?

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Testing Group';
// Assuming 'sys_id_of_manager' is the sys_id of a user record
newGr.manager = 'sys_id_of_manager';
newGr.email = 'testing@tcs.com';
newGr.description = 'A group for testing purposes';
newGr.insert();
                

Interview Relevance: Demonstrates your ability to automate administrative tasks, a key skill for ServiceNow developers and administrators.

Question: How to add permissions (roles) to a user account using a script?

var userRole = new GlideRecord('sys_user_has_role');
userRole.setValue('user', 'sys_id_of_user'); // Replace with actual user sys_id
userRole.setValue('role', 'sys_id_of_role'); // Replace with actual role sys_id
userRole.insert();
                

Question: How to add permissions (roles) to a group account using a script?

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.setValue('group', 'sys_id_of_group'); // Replace with actual group sys_id
grpRole.setValue('role', 'sys_id_of_role'); // Replace with actual role sys_id
grpRole.insert();
                

Interview Relevance: Essential for understanding how to programmatically manage access control, critical for integrations and bulk updates.

Question: What exactly does user delegation mean in ServiceNow?

Answer: “User delegation in ServiceNow is a powerful feature that allows one user to perform actions and manage tasks on behalf of another user. This is incredibly useful when a user is unavailable due to leave, vacation, or other reasons, ensuring business continuity. The delegated user can be granted specific permissions to handle approvals, notifications, or assignments. For example, if a manager is on vacation, they can delegate their approval tasks to a senior team member so that critical requests aren’t delayed. This is configured by the original user under their profile settings by specifying the delegate, the date range, and the specific permissions they are granting.”

Interview Relevance: This tests your understanding of features that improve user experience and operational efficiency.

Question: How to add and remove a group member from a group using a script?

Adding a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.user = 'sys_id_of_user'; // Replace with actual user sys_id
grMem.group = 'sys_id_of_group'; // Replace with actual group sys_id
grMem.insert();
                

Removing a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', 'sys_id_of_user'); // Replace with actual user sys_id
grMem.addQuery('group', 'sys_id_of_group'); // Replace with actual group sys_id
grMem.query();
if (grMem.next()) {
    grMem.deleteRecord();
}
                

Interview Relevance: Practical scripting skills for user administration.

Question: How many user interfaces are there in ServiceNow?

Answer: “ServiceNow has evolved its user interfaces over time. The primary interfaces are:

• UI15/UI16: The classic interfaces that were prevalent for many years.
• Next Experience UI: This is the modern, redesigned interface that most instances are migrating to, offering a cleaner, more intuitive user experience.

It’s worth noting that while these are the main ones, mobile interfaces and specialized UIs for specific applications also exist.”

Interview Relevance: Shows awareness of the platform’s evolution and current UI trends.

Question: What is meant by a web services user in ServiceNow?

Answer: “A web services user, often referred to as a system user or integration user, is an account specifically created to allow third-party applications or other systems to interact with ServiceNow via its web services APIs (like REST or SOAP). Crucially, these users are typically configured without the ability to log in directly to the ServiceNow UI. Their sole purpose is programmatic access for data exchange or process automation. This enhances security by limiting the attack surface.”

Interview Relevance: Understanding integration patterns and security for system-to-system communication.

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

Answer: “On the client-side (e.g., in UI policies, client scripts, or service portal widgets), you use the global JavaScript variable g_user.userID. For example, alert(g_user.userID); would display the sys_id of the currently logged-in user.”

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

Answer: “On the server-side (e.g., in business rules, script includes, or workflows), you use the gs.getUserID() method. For instance, var currentUserID = gs.getUserID(); would achieve the same.”

Interview Relevance: Differentiates client-side and server-side scripting capabilities, a fundamental concept.

Question: How to check if the current logged user is a member of a particular group or not?

Answer: “On the server-side, you can use the gs.getUser().isMemberOf('group_sys_id_or_name') method. It returns true if the user is a member of the specified group, and false otherwise. For example, if (gs.getUser().isMemberOf('itil')) { gs.log('User is an ITIL member'); }.”

Interview Relevance: Crucial for conditional logic in server-side scripts, like access control or workflow routing.

Question: Which role is required to work on Access Control Lists (ACLs)?

Answer: “The primary role required to create, modify, and manage ACLs in ServiceNow is the security_admin role. Without this role, you won’t have the necessary permissions to enforce granular security policies across the platform.”

Interview Relevance: Tests your understanding of ServiceNow’s security model and administrative roles.

Question: What is impersonation?

Answer: “Impersonation is a feature in ServiceNow that allows an administrator or a user with appropriate permissions to temporarily log in as another user. This is invaluable for testing functionality from a specific user’s perspective, debugging issues that only occur for certain users, or verifying that Access Controls are working as expected. You can access impersonation from the user menu in the platform header.”

Interview Relevance: Demonstrates practical knowledge of testing and troubleshooting methodologies within ServiceNow.

Question: What are user preferences?

Answer: “User preferences in ServiceNow refer to settings that individual users can configure to personalize their experience within the platform. These can include things like the default theme, notification settings, list layout preferences, or even specific shortcuts. The key aspect is that these preferences are user-specific; changes made by one user do not affect others. This allows for a highly tailored user experience without impacting the global configuration.”

Interview Relevance: Shows awareness of user-centric features and personalization capabilities.

Question: What is an incident?

Answer: “An incident is essentially any unplanned interruption to an IT service or a reduction in the quality of an IT service. For an end-user, it’s something that stops them from working as usual. The primary goal of incident management is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations.”

Question: What is a problem?

Answer: “A problem, in contrast to an incident, is the underlying cause of one or more incidents. If the same incident or similar incidents are occurring repeatedly, it suggests an underlying problem that needs to be identified and resolved permanently. The goal of problem management is to find the root cause and prevent future incidents. In scenarios where multiple incidents stem from a single problem, the problem record often acts as a parent, and the related incidents are child records. Resolving the problem typically resolves all associated incidents.”

Interview Relevance: Critical to understanding ITIL processes and how ServiceNow supports them. Differentiating these is fundamental.

Question: Can we create a problem record from an incident?

Answer: “Yes, absolutely. If a support engineer identifies that an incident is recurring or might have a broader underlying cause, they can initiate a problem investigation directly from the incident record. This typically involves creating a new problem record and linking it back to the incident(s) that triggered the investigation.”

Question: Can we create a change request from an incident?

Answer: “Yes. When resolving an incident, if the support team determines that a permanent fix requires a change to the IT infrastructure or application, they can create a change request directly from the incident. This ensures that the necessary change process is followed to implement the solution, and the incident can be linked to the change for traceability.”

Interview Relevance: Demonstrates understanding of the interconnectedness of ITSM processes within ServiceNow.

Question: How to create an incident record using a script?

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = 'sys_id_of_caller'; // Replace with actual user sys_id
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'sys_id_of_ci'; // Replace with actual Configuration Item sys_id
gr.short_description = 'Test record created via script';
gr.description = 'This is a test incident record.';
gr.assignment_group = 'sys_id_of_assignment_group'; // Replace with actual group sys_id
gr.insert();
                

Question: How to create a problem record using a script?

var gr = new GlideRecord('problem');
gr.initialize();
gr.caller_id = 'sys_id_of_caller';
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'sys_id_of_ci';
gr.short_description = 'Test problem record via script';
gr.description = 'This is a test problem record.';
gr.assignment_group = 'sys_id_of_assignment_group';
gr.insert();
                

Question: How to create a change request using a script?

var gr = new GlideRecord('change_request');
gr.initialize();
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'sys_id_of_ci';
gr.short_description = 'Test change request via script';
gr.description = 'This is a test change request.';
gr.assignment_group = 'sys_id_of_assignment_group';
gr.insert();
                

Interview Relevance: Essential for automating the creation of core ITSM records, common in integrations and workflow automation.

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

Answer: “This can be effectively implemented using an After Update Business Rule on the incident table.

// Business Rule Name: Close Child Incidents on Parent Close
// Table: Incident
// When: After
// Update: true

(function executeRule(current, previous /*, gComplement*/) {

    // Check if the state has changed to 'Closed' and it's not already a child incident.
    // Assuming state value '7' represents 'Closed'. Adjust if your workflow differs.
    if (current.state.changesTo(7) && current.parent == '') {

        // GlideRecord to find child incidents associated with the current parent incident.
        var grChild = new GlideRecord('incident');
        grChild.addQuery('parent', current.sys_id);
        grChild.query();

        while (grChild.next()) {
            // Set the state of the child incident to Closed.
            grChild.state = 7; // Set to 'Closed'
            grChild.update(); // Update the child incident
        }
    }

})(current, previous);
                

Explanation: This rule triggers after an incident is updated. It checks if the incident’s state has changed to ‘Closed’ (assuming 7 is the value for Closed) and if it’s a parent incident (i.e., `parent` field is empty). If these conditions are met, it queries for all incidents where the `parent` field matches the `sys_id` of the current incident, sets their state to ‘Closed’, and updates them.

Interview Relevance: This demonstrates a practical application of business rules for process automation and enforcing business logic. Understanding `changesTo()` is key here.

Question: There is an incident with associated incident tasks. When trying to close the incident, the user should not be allowed to close it if any incident task is still open. Apply similar logic for problem and change requests.

Answer: “This scenario requires a Before Update Business Rule on the incident table (and similarly on problem and change_request tables). This ensures the check happens before the record is actually updated to the closed state.

For Incidents:

// Business Rule Name: Prevent Incident Close with Open Tasks
// Table: Incident
// When: Before
// Update: true
// Filter Conditions: State changes to Closed (or your specific Closed state)

(function executeRule(current, previous /*, gComplement*/) {

    // Check for open incident tasks
    var grTask = new GlideRecord('incident_task');
    grTask.addQuery('incident', current.sys_id);
    // Assuming state value '3' represents 'Closed'. Adjust if your workflow differs.
    grTask.addQuery('state', '!=', 3);
    grTask.query();

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

})(current, previous);
                

For Problem and Change Requests: You would create similar business rules on their respective tables, checking for associated open tasks (e.g., `problem_task`, `change_task`). The logic would be analogous.

Explanation: The business rule runs before an incident is updated. It checks the incident_task table for any tasks linked to the current incident that are not in a ‘Closed’ state. If open tasks are found, it displays an error message using gs.addErrorMessage() and uses current.setAbortAction(true) to prevent the update from completing. This ensures data integrity and process compliance.

Interview Relevance: This is a classic example of implementing business logic to enforce process rules and data integrity, showcasing your ability to design robust solutions.

Question: Whenever a problem is closed, all associated incidents will also get closed.

Answer: “This is another scenario for an After Update Business Rule on the problem table.

// Business Rule Name: Close Incidents on Problem Close
// Table: Problem
// When: After
// Update: true

(function executeRule(current, previous /*, gComplement*/) {

    // Assuming state value '7' represents 'Closed'. Adjust if your workflow differs.
    if (current.state.changesTo(7)) {

        // GlideRecord to find incidents associated with this problem.
        var grIncident = new GlideRecord('incident');
        grIncident.addQuery('problem_id', current.sys_id); // Assuming 'problem_id' links incident to problem
        grIncident.addQuery('state', '!=', 7); // Ensure we only close open incidents
        grIncident.query();

        while (grIncident.next()) {
            grIncident.state = 7; // Set the state to Closed
            grIncident.update(); // Update the incident
        }
    }

})(current, previous);
                

Explanation: When a problem record’s state changes to ‘Closed’, this rule queries the incident table for all incidents linked to this problem (via the `problem_id` field, assuming this is your linkage) and which are not already closed. It then updates their state to ‘Closed’ as well.”

Interview Relevance: Demonstrates understanding of how to automate cross-module dependencies and enforce process flow.

Question: What is the relationship between incident, problem, and change management?

Answer: “These three are core components of IT Service Management (ITSM) and are intricately linked in ServiceNow:

• Incident Management: Focuses on restoring normal service operations as quickly as possible after an unplanned interruption. When a user reports an issue, an incident is created.
• Problem Management: Deals with identifying the root cause of recurring incidents and finding permanent solutions to prevent future occurrences. If multiple incidents point to the same underlying issue, a problem record is created to investigate and resolve the root cause.
• Change Management: Manages all changes to the IT infrastructure in a controlled manner to minimize disruption and risk. If resolving a problem requires making changes to systems, applications, or infrastructure, a change request is initiated.

In essence, an incident is the immediate disruption, a problem is the underlying cause of one or more incidents, and a change is the action taken to fix the problem permanently.”

Interview Relevance: Tests your conceptual understanding of ITSM frameworks and how they are implemented in ServiceNow.

Question: Give me some names of out-of-the-box tables.

Answer: “Out-of-the-box (OOB) tables are those that are part of the core ServiceNow platform and typically do not start with a custom prefix like ‘x_’ or ‘u_’. Common examples include:

• incident
• problem
• change_request
• task
• sys_user
• sys_user_group
• cmdb_ci (and its many extensions)
• sc_req_item (Service Catalog Request Item)

Tables created within scoped applications usually start with ‘x_’ (for global applications) or a custom prefix defined by the scope.”

Interview Relevance: Basic knowledge of ServiceNow’s data model structure.

Question: What are some of the base tables?

Answer: “Base tables are foundational tables in ServiceNow’s data hierarchy. They typically don’t extend other tables themselves but serve as parent tables that are extended by many other tables. They often contain common fields and functionalities. Key examples include:

• task: The parent table for many ITSM records like Incident, Problem, Change Request, and Task.
• cmdb_ci: The base table for the Configuration Management Database, from which all Configuration Item (CI) classes inherit.
• cmdb: The overarching base table for the CMDB.
• sys_user: The base table for user information.

Understanding these helps in comprehending table inheritance and how fields cascade down.”

Interview Relevance: Demonstrates understanding of the ServiceNow data model and inheritance.

Question: Give me some examples of task tables.

Answer: “As mentioned, many tables in ServiceNow extend the task table. This means they inherit common fields like ‘Short Description’, ‘Description’, ‘Assigned To’, ‘Assignment Group’, ‘State’, ‘Due Date’, etc. Examples include:

• incident
• problem
• change_request
• sc_task (Service Catalog Task)
• sn_customerservice_case_task (Customer Service Case Task)
• pm_task (Project Task)

This common structure simplifies scripting and reporting across different task-oriented modules.”

Interview Relevance: Reinforces understanding of table extensions and common data structures.

Question: Whenever we create a table, how many access controls (ACLs) will get created by default?

Answer: “By default, when you create a new table and the ‘Create ACLs’ checkbox is selected (which it is by default when creating a table via the UI), ServiceNow automatically generates four base Access Control Lists (ACLs). These typically provide:

• Read access for everyone (or based on specific roles if configured).
• Write access for specific roles (often Admin).
• Create access for specific roles.
• Delete access for specific roles.

These are fundamental for basic record access. If you uncheck the ‘Create ACLs’ option during table creation, you’ll need to manually define all necessary ACLs.”

Interview Relevance: Crucial for understanding security by design and the setup process for new data structures.

Question: How to create a number field, like the incident number?

Answer: “To create an auto-numbering field, similar to the `number` field on the Incident table, you configure it in the field’s dictionary entry. When defining or editing a field in the Table configuration (System Definition > Tables), under the ‘Control’ tab, you’ll find the ‘Auto-number’ section. Here, you can:

• Enable the ‘Auto number’ checkbox.
• Specify a ‘Prefix’ (e.g., ‘INC’ for incidents).
• Define the ‘Number of digits’ (e.g., 7 digits for INC0000001).

When a new record is created, ServiceNow will automatically generate a unique number following this pattern.”

Interview Relevance: Essential for creating unique identifiers for records, a common requirement.

Question: What happens when you extend a table?

Answer: “When you extend a table in ServiceNow, you’re creating a child table that inherits fields and properties from a parent table. The key consequences are:

• Inheritance: The child table automatically gains all the fields and configurations from its parent. For instance, an Incident table (extending Task) inherits fields like ‘Short Description’, ‘State’, etc.
• No Duplicate System Fields: System fields (like `sys_id`, `sys_created_on`, `sys_updated_on`) are not duplicated in the child table; they are managed by the parent.
• ‘Class’ Field: A field named class is automatically added to the parent table. This field stores the sys_id of the actual table the record resides in (e.g., for an incident record, the `class` field in the `task` table would store the `sys_id` of the `incident` table). This is crucial for dynamic queries that need to consider all types of tasks, for example.
• Single Class Field: Even if a table extends multiple tables (though direct multi-table extension isn’t common; it’s usually via a chain), it typically has only one ‘class’ field in its ultimate parent table.

This inheritance model promotes reusability and a structured data architecture.”

Interview Relevance: Fundamental to understanding ServiceNow’s data model and how to design efficient, reusable structures.

Question: Can you give me 10 field types?

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

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

“

Interview Relevance: Basic but essential knowledge of data modeling.

Question: What is the difference between a temporary and a normal table?

Answer: “The primary difference lies in data retention and purpose:

• Normal Tables: These are standard tables designed to store data permanently. Data remains in these tables until explicitly deleted or archived. Examples include incident, problem, sys_user.
• Temporary Tables: These tables are designed for short-term data storage, often used for staging data during imports or temporary processing. Data in temp tables typically has a limited retention period, often around 7 days, after which it’s automatically purged. They often extend the import_set_row table or similar staging tables. An example is tables created by Import Sets before transformation.

Think of normal tables as your database, and temporary tables as a scratchpad.”

Interview Relevance: Understanding of data management strategies and lifecycle within the platform.

Question: Can we increase the retention period in the temp table?

Answer: “Yes, you can effectively extend the retention period for data in temporary tables or manage the lifecycle of data in any table using Archive Rules. Archive rules allow you to define criteria for moving older data from active tables (including temporary ones, though it’s less common for their intended purpose) to an archive table, which is more cost-effective for long-term storage and keeps the primary tables leaner. While not directly increasing the *automatic purge* of a temp table, archiving achieves a similar outcome of managing data longevity.”

Interview Relevance: Knowledge of data lifecycle management and platform tools like archiving.

Question: What is the difference between a remote table and normal tables?

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

• Normal Tables: These are standard ServiceNow tables where data is stored directly within the ServiceNow instance’s database. You query and manipulate this data locally.
• Remote Tables: These are tables where the data is not stored within your ServiceNow instance. Instead, ServiceNow connects to an external data source (e.g., an external database, an API) to retrieve the data in real-time. When you query a remote table, ServiceNow makes a call to the external source. This is often used for integrating with other systems without replicating all their data.

The key distinction is ‘live’ external data versus ‘stored’ local data.”

Interview Relevance: Understanding of integration strategies and data access patterns.

Question: What is a one-to-one and one-to-many table relationship in ServiceNow?

Answer: “These describe how records in different tables 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 multiple records in Table B, but each record in Table B is associated with only one record in Table A.
  • Example: A sys_user record (Table A) can have multiple incident records (Table B) associated with it (via the caller_id field). One user can open many incidents, but one incident is opened by only one user.
• One-to-One Relationship: Here, one record in Table A can be associated with exactly one record in Table B, and vice-versa. This is less common and often achieved through specific configurations or by using a reference field that is also marked as unique, or by creating a table that extends another.
  • Example: While not a perfect direct example of a built-in one-to-one for core ITSM tables, you might see this if a user profile has a single ‘preferred contact method’ record that is exclusively linked. Or, custom scenarios where a specific configuration detail is tied to one main record. A more precise example would be linking a sys_user to a single `user_preferences` record via a direct `sys_id` mapping.
• Many-to-Many Relationship: One record in Table A can be associated with multiple records in Table B, and vice-versa. These are typically implemented using a “junction” or “linking” table.
  • Example: An incident record can be assigned to multiple sys_user_group records (though usually just one primary assignment group), and a sys_user_group can be assigned to multiple incident records. The `sys_user_grmember` table is a perfect example of a junction table creating a many-to-many relationship between users and groups.

In ServiceNow, relationships are primarily managed using Reference fields, List fields, or through junction tables.”

Interview Relevance: Fundamental database design concepts applied to ServiceNow.

Question: In how many ways can we create a record in a ServiceNow table?

Answer: “There are several common ways to create records in ServiceNow tables:

1. Forms: The most direct way, by navigating to the table list and clicking ‘New’.
2. Record Producers: A type of catalog item that creates a record on a specific table based on user input from a form.
3. Email: Using inbound email actions to create records from incoming emails.
4. Scripting (GlideRecord): Using server-side JavaScript to programmatically create records, as we’ve seen in previous examples.
5. Integrations/Web Services: Creating records via REST or SOAP APIs from external systems.
6. Import Sets: Loading data from files (Excel, CSV) into staging tables and then transforming it into records on target tables.
7. Service Catalog: Ordering a service which might trigger the creation of multiple related records (like Requested Items, Catalog Tasks).

“

Interview Relevance: Shows breadth of knowledge about platform capabilities for data ingestion and creation.

Question: In how many ways can we make a field mandatory or read-only?

Answer: “You can achieve mandatory or read-only field behavior in ServiceNow through multiple methods:

• Dictionary Properties: Directly on the field’s dictionary entry, you can set ‘Mandatory’ or ‘Read only’ flags. This is a global setting for that field unless overridden.
• Dictionary Overrides: For child tables, you can override the default ‘Mandatory’ or ‘Read only’ settings from the parent table.
• UI Policies: These are client-side scripts that can dynamically set fields as mandatory, read-only, visible, or hidden based on specific conditions on the form. They are evaluated when the form loads and when field values change.
• Data Policies: These are similar to UI Policies but can run on both the client-side and the server-side. They are excellent for enforcing data consistency regardless of how the record is accessed (form, API, import).
• Client Scripts: Using JavaScript with g_form.setMandatory('field_name', true/false); or g_form.setReadOnly('field_name', true/false); for dynamic client-side control.
• Access Control Lists (ACLs): You can define read and write ACLs that effectively make fields read-only or inaccessible based on roles and conditions.

The choice depends on whether the requirement is static (dictionary), dynamic and client-side (UI Policy/Client Script), or applies across all data sources (Data Policy/ACLs).”

Interview Relevance: Demonstrates understanding of how to control user interaction and data integrity using various platform features.

Question: Can we make two fields display in one table?

Answer: “The platform technically allows you to set the ‘Display’ attribute on multiple fields within a table’s dictionary definition. However, it is strongly discouraged and considered a bad practice. ServiceNow’s design intends for a single field to be the primary display value for a reference field lookup. Having multiple display fields can lead to confusion in reference pickers and reports, and may cause unexpected behavior or performance issues. Stick to one designated display field per table.”

Interview Relevance: Tests understanding of best practices and potential pitfalls in data modeling.

Question: All tables will be stored where?

Answer: “Information about all tables defined in ServiceNow, including custom tables and out-of-the-box tables, is stored in the sys_db_object table. This table contains metadata about each table, such as its name, label, description, and whether it’s an extension of another table.”

Interview Relevance: Knowledge of ServiceNow’s internal meta-data management.

Question: How to set a default value on a field?

Answer: “You can set default values for fields in a few ways:

• Dictionary Entry: The most common method is to enter a default value directly in the ‘Default value’ field on the field’s dictionary entry. This value will be pre-populated when a new record is created via a form.
• UI Policies: You can use a UI Policy to set a default value based on certain conditions when the form loads or when other fields change.
• Client Scripts: Similarly, a client script can set a default value using g_form.setValue('field_name', 'default_value');, often triggered by `onLoad`.
• Business Rules: A ‘before’ business rule can set a default value when a new record is inserted if it’s not handled by the dictionary or other client-side logic.

The dictionary entry is the simplest for a static default value.”

Interview Relevance: Essential for improving user experience and data consistency.

Question: What is the ‘current’ object?

Answer: “In server-side scripting (like Business Rules, Script Includes executed in a server context, or Workflow scripts), the current object represents the record that is currently being processed. Whether it’s being inserted, updated, or deleted, current provides access to the values of all fields on that specific record at that moment in time. It’s also mutable, meaning you can change field values using current.setValue() before the operation completes (especially in ‘before’ business rules).”

Interview Relevance: Fundamental to server-side scripting in ServiceNow.

Question: How to set the field values on the ‘current’ object?

Answer: “You can set field values on the current object using two primary methods:

• current.setValue('field_name', value);
  This is the standard method. For regular fields (String, Integer, Choice, etc.), you pass the value directly. For reference fields, you pass the sys_id of the related record.
• current.setDisplayValue('field_name', value);
  This method is useful for reference fields. Instead of passing the sys_id, you pass the human-readable display value. ServiceNow will then look up the corresponding sys_id and set the field. This is particularly helpful when you only know the display value and not the sys_id.

It’s important to remember that `current` is a server-side object, so these methods are used in server-side scripts.”

Interview Relevance: Practical scripting techniques for manipulating record data.

Question: What are reference qualifiers, their types, and the differences between simple, dynamic, and advanced?

Answer: “Reference Qualifiers are used to filter the records that appear in a reference field’s dropdown or lookup. They ensure users select only relevant related records. There are three main types:

1. Simple Reference Qualifier:
   • Description: This is the most straightforward type, where you define a fixed query using field conditions, similar to a `where` clause in SQL.
   • Example: To show only ‘Active’ users in a reference field pointing to the sys_user table, you’d use active=true.
   • How to Use: You configure this directly in the reference field’s dictionary entry by selecting ‘Simple’ and entering your query conditions (e.g., `state=1^assignment_group=abc123xyz`).
2. Dynamic Reference Qualifier:
   • Description: This type uses a dynamically generated query that can adapt based on context, such as values of other fields on the current form.
   • Example: Displaying only users who are members of the same group as the one selected in another field on the form.
   • How to Use: You create a ‘Dynamic Filter Option’ (System Definition > Dynamic Filter Options) and then select this option in the reference field’s dictionary entry.
3. Advanced Reference Qualifier (JavaScript Reference Qualifier):
   • Description: This is the most powerful type, allowing you to write custom JavaScript code to define complex filtering logic. It offers the greatest flexibility.
   • Example: Filtering incidents to show only those assigned to the current user’s assignment group, with a priority less than 3, and created in the last 30 days.
   • How to Use: In the reference field’s dictionary entry, select ‘Advanced’ and provide your JavaScript code, often returning a query string. For example:

     
     javascript: 'assignment_group=' + current.assignment_group + '^priority<3^active=true';
                                     

Differences:

• Simple vs. Dynamic: Simple is static; Dynamic adapts to form context without custom scripting, using pre-defined filters.
• Dynamic vs. Advanced: Dynamic is good for common contextual filters. Advanced is for highly custom, complex logic that cannot be achieved with dynamic filters alone.
• Simple vs. Advanced: Simple is for basic, fixed criteria. Advanced is for dynamic, complex, or conditional filtering that requires JavaScript logic.

“

Interview Relevance: A crucial topic for anyone working with data relationships and form usability.

Question: What is a dependent value?

Answer: “Dependent values, also known as cascading dropdowns, are a feature where the choices available in one field (the dependent field) are filtered based on the selection made in another field (the parent field). This is commonly used to create logical selections, like choosing a ‘Subcategory’ based on a selected ‘Category’.

How it works:

1. Parent Field: This field has a set of defined choices (e.g., Category: Hardware, Software, Network).
2. Dependent Field: This field’s choices are dynamically filtered. You configure this by going to the dictionary entry of the dependent field and setting the ‘Dependent Field’ attribute to the name of the parent field.
3. Choice Configuration: For the dependent field, you then define its choices, and for each choice, you specify which parent field value it should appear under. For example, for Subcategory: ‘Laptop’ would be a choice under ‘Hardware’, ‘Operating System’ under ‘Software’.

Example: If you select ‘Hardware’ in the Category field, the Subcategory dropdown will only show options like ‘Laptop’, ‘Desktop’, ‘Printer’. If you select ‘Software’, it might show ‘Operating System’, ‘Application’.”

Interview Relevance: Essential for creating user-friendly and logical forms.

Question: What is a calculated value?

Answer: “A calculated value is a field whose value is not entered directly by the user but is automatically computed based on a formula or logic applied to other fields. This is configured directly on the field’s dictionary entry under the ‘Calculation’ tab. You can use simple dot-walking or JavaScript expressions to define how the field’s value is derived. For instance, you might have a ‘Total Price’ field calculated by multiplying ‘Quantity’ by ‘Unit Price’.”

Interview Relevance: Understanding how to automate calculations and ensure data consistency.

Question: What are attributes, and name some of the attributes that you have used?

Answer: “Attributes are special keywords used in ServiceNow’s dictionary entries that modify the behavior of fields or tables. They are applied in the ‘Attributes’ field on the dictionary record. They provide a declarative way to customize functionality without writing extensive code. Some common attributes I’ve used include:

• no_email: Prevents email notifications from being sent for updates to this field.
• no_attachment: Disables attachments for records in this table.
• no_add_me: Hides the ‘Add Me’ button on list views.
• tree_picker: Changes the reference field UI to a tree-like picker, useful for hierarchical data.
• read_only: Makes the field read-only (similar to the Read only checkbox but can be applied dynamically via attributes).
• ref_ac_disabled: Disables access control checks for reference fields.
• ref_auto_completer=...: Configures the auto-completion behavior for reference fields.

Attributes offer a concise way to tweak field functionality.”

Interview Relevance: Shows knowledge of advanced configuration options and how to subtly control UI and behavior.

Question: What is a collection field on a table?

Answer: “In ServiceNow’s data model, a ‘collection field’ entry in the dictionary actually represents the table itself, not an individual field on the table. When you look at a dictionary entry for a table (e.g., `sys_db_object` record for the ‘Incident’ table), the entry with `sys_class_name` set to ‘sys_dictionary’ and where `name` matches the table name is considered the ‘collection’ entry. Any attributes or properties set on this collection entry apply to the table as a whole, such as enabling or disabling attachments for all records in that table.”

Interview Relevance: Understanding the meta-data structure and how table-level properties are managed.

Question: How to enable/disable attachments on the form using attributes?

Answer: “You can control attachment functionality using attributes on the collection field entry for the table.

• To disable attachments for a table, you add the no_attachment attribute to the collection field’s dictionary entry.
• To enable attachments (if they were previously disabled or if you want to ensure they are enabled), you would ensure the no_attachment attribute is *not* present. If it was added, you’d remove it. There isn’t a specific ‘enable_attachment’ attribute; its presence or absence dictates the functionality.

This is a quick and declarative way to manage attachment capabilities for an entire table.”

Interview Relevance: Practical application of attributes for common UI controls.

Question: What are dictionary overrides, and what properties can we override?

Answer: “Dictionary overrides are used to change the default properties of a field inherited from a parent table for a specific child table. They allow you to customize field behavior without altering the original parent table definition. You can override a wide range of properties, including:

• Default Value
• Mandatory flag
• Read-only flag
• Max length
• Display flag
• Reference specification (e.g., reference qualifier)
• Attributes
• Label
• Help text
• Choice list specifications

For example, if the ‘Priority’ field on the parent `task` table has a default value of 4, you could use a dictionary override on the `incident` table to change this default to 5, or make it mandatory specifically for incidents. This is crucial for tailoring fields to the specific needs of different modules.”

Interview Relevance: Key to understanding how to customize inherited data structures effectively.

Question: What are application menus?

Answer: “Application menus, often referred to as modules, are navigational elements that organize forms, lists, and other views within the ServiceNow platform’s left-hand navigation pane. They group related functionalities under a parent application (like ‘Self-Service’, ‘ITSM’, ‘Security Operations’). Users interact with these menus to access different parts of the system. For instance, ‘All Incidents’ under the ‘Incident’ application menu is an application menu item.”

Interview Relevance: Understanding how users navigate and access functionality within ServiceNow.

Question: What is a process flow?

Answer: “A process flow, often visualized as a ‘flow designer’ or a ‘process engine’ view, is a graphical representation that indicates the current state or stage of a record within a defined workflow. It helps users understand where they are in a multi-step process and what the next steps might be. For instance, in a change request, a process flow might visually show stages like ‘New’, ‘Assessment’, ‘Authorize’, ‘Scheduled’, ‘Implement’, ‘Review’, ‘Closed’.”

Interview Relevance: Understanding how ServiceNow visualizes and manages complex processes.

Question: What are data lookup rules?

Answer: “Data lookup rules (though sometimes confused with Data Lookups defined in global properties, they are distinct) are used to automatically populate field values on a form based on the values of other fields on that same form. They operate similarly to dependent dropdowns but can populate any field with any value, not just pre-defined choices. They are configured by defining a table of lookup rules where you specify source fields, target fields, and the mapping logic. For example, you could set up a rule where selecting a specific ‘Product Model’ automatically populates the ‘Configuration Item’ field with the corresponding CI record.”

Interview Relevance: Shows knowledge of automating data entry and ensuring data consistency through mapping.

Question: What are UI Policies?

Answer: “UI Policies are client-side scripts used to dynamically change the behavior of form fields based on certain conditions. They are a declarative alternative to client scripts for many common scenarios. They can make fields:

• Mandatory
• Read-only
• Visible or Hidden
• Set their value

UI Policies are executed when the form loads (`onLoad`) and when field values change. They are generally preferred over client scripts for these types of dynamic form manipulations due to their declarative nature and ease of maintenance.”

Interview Relevance: Core knowledge for front-end form configuration and user experience design.

Question: What is the ‘Global’ checkbox in UI Policies?

Answer: “When the ‘Global’ checkbox is checked on a UI Policy, it means that the UI Policy will apply to all views of the form. If it’s unchecked, you can specify particular views where the UI Policy should run. This is useful if you have different view configurations for different user groups or purposes and want UI Policies to behave differently across them.”

Interview Relevance: Understanding how to control the scope of UI Policy execution.

Question: What is ‘Reverse if false’ in UI Policies?

Answer: “The ‘Reverse if false’ checkbox on a UI Policy Action is very useful. If selected, it means that when the UI Policy’s condition evaluates to false, the actions defined within that specific UI Policy Action will be reversed. For example, if an action makes a field mandatory when the condition is true, and ‘Reverse if false’ is checked, that field will become optional again when the condition is false. This simplifies managing alternating states.”

Interview Relevance: Practical application for dynamic form behavior control.

Question: What is the ‘On Load’ checkbox in a UI Policy?

Answer: “The ‘On Load’ checkbox 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 loads, setting the initial state of fields (e.g., making a field mandatory, setting a default value).
• If unchecked: The UI Policy will *not* run when the form initially loads. Its actions will only be triggered when a specific field’s value changes that meets the UI Policy’s conditions.

This is important for controlling the initial appearance and behavior of your forms.”

Interview Relevance: Understanding form initialization and dynamic behavior.

Question: What is the ‘Inherit’ checkbox?

Answer: “When the ‘Inherit’ checkbox is checked on a UI Policy, it means that this UI Policy will also be applied to any child tables that extend the table on which the UI Policy is defined. For example, if you have a UI Policy on the task table with ‘Inherit’ checked, that UI Policy will automatically be applied to incident, problem, and change_request records as well, ensuring consistent client-side behavior across related tables.”

Interview Relevance: Understanding how to apply UI logic across table hierarchies.

Question: Can you write script in UI Policy?

Answer: “Yes, you can! UI Policies allow you to run client-side scripts for more complex logic. To do this, you need to enable the ‘Run scripts’ checkbox on the UI Policy itself. Then, within the UI Policy Actions, you can find a related list for ‘Script’. Once you enable ‘Run scripts’ in the UI Policy Action, you can enter JavaScript code that will execute when the UI Policy conditions are met. This is where you’d use `g_form.setValue()`, `g_form.setMandatory()`, etc., for dynamic control that goes beyond simple show/hide or mandatory/read-only settings.”

Interview Relevance: Demonstrates the flexibility of UI Policies beyond declarative settings.

Question: Can we convert a UI Policy as a Data Policy?

Answer: “Yes, you can convert many UI Policies into Data Policies. ServiceNow provides a convenient feature for this. When you open a UI Policy, there’s typically a button or an option like ‘Convert to Data Policy’ or ‘Convert this as Data Policy’. Clicking this will create a corresponding Data Policy based on the UI Policy’s conditions and actions. This is beneficial because Data Policies can run on both client and server, ensuring data consistency across all entry points.”

Interview Relevance: Understanding platform tools for modernizing and consolidating logic.

Question: Which are all the cases where a UI Policy cannot be converted as a Data Policy?

Answer: “While the conversion is powerful, there are scenarios where a UI Policy cannot be fully converted into a Data Policy, or the conversion might not be ideal:

• Controlling Data Visibility (Show/Hide Fields): Data Policies are primarily for enforcing data constraints (mandatory, read-only, calculated values), not for controlling the visual visibility of fields on a form. UI Policies excel at this.
• Controlling Views: UI Policies can sometimes influence what’s displayed in certain views, but Data Policies do not operate at the view level.
• Controlling Related Lists: Managing the display or behavior of related lists is typically a UI Policy function.
• Complex Scripting Involving `g_form` specific methods: While Data Policies have server-side scripting capabilities, some UI Policy scripts that rely heavily on client-specific `g_form` methods might require manual rework or may not translate directly.

In these cases, you’d keep the UI Policy for client-side form manipulation and create a Data Policy for server-side data enforcement if needed.”

Interview Relevance: Understanding the strengths and limitations of different platform features.

Question: What are Data Policies?

Answer: “Data Policies are powerful tools used to enforce data consistency and integrity across all layers of the ServiceNow platform – client-side, server-side, and via APIs. They define rules for fields that can be mandatory, read-only, or hidden. Unlike UI Policies, which primarily affect the form’s user interface, Data Policies enforce data constraints regardless of how the record is accessed. This ensures that critical data requirements are met, whether a user is interacting via a form, an integration, or a bulk import.”

Interview Relevance: Understanding robust data governance and validation mechanisms.