ServiceNow Scripting Interview Questions & Answers Guide

Navigating the ServiceNow Scripting Interview Labyrinth: Your Comprehensive Guide

So, you’ve landed that coveted ServiceNow developer interview! Congratulations! But as the date approaches, you’re probably wondering what kind of scripting challenges await you. ServiceNow interviews aren’t just about syntax; they’re about understanding the platform’s architecture, its best practices, and how to apply your scripting knowledge in real-world scenarios. It’s less about memorizing code snippets and more about demonstrating a deep, practical understanding of how things work under the hood.

This article dives deep into some of the most common and crucial ServiceNow scripting interview questions, offering not just answers but detailed explanations, practical examples, and the underlying “why” behind each concept. We’ll cover everything from core platform features to advanced scripting techniques, ensuring you’re well-equipped to impress your interviewers. Think of this as your personalized coaching session for mastering ServiceNow scripting interviews.

ServiceNow Platform Fundamentals: Setting the Stage

Before diving into complex scripts, interviewers often gauge your familiarity with the platform’s evolution and basic terminology. It shows you’re not just a coder, but a true ServiceNow enthusiast.

What’s Your ServiceNow Journey? (Versions & UI)

Interviewers love to hear about your experience, and knowing your way around ServiceNow versions is a great indicator. Each release brings new features and improvements, so staying current is key.

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

Answer: As of this writing, the latest major release is typically Washington D.C. Always check the official ServiceNow product documentation for the absolute latest version. In an interview, confidently state the version you are *actively* working with or the very latest one if you’re tracking releases.

2. From which version did you start working?

Answer: This question assesses your journey. Listing a progression like Rome, San Diego, Tokyo, Utah, Vancouver, Washington D.C. shows continuous engagement. If you started earlier, mention those too! The key is to show progression and adaptation to new features over time.

11. How many user interfaces are there in ServiceNow?

Answer: While the underlying platform is robust, ServiceNow has evolved its user experience significantly. You’ll primarily encounter:

UI15/UI16: These are the classic UIs, though UI16 is the standard “classic” experience most long-term users are familiar with. It’s known for its consistent look and feel across modules.
Next Experience: This is the modern, redesigned UI (often referred to as Polaris) that ServiceNow is pushing towards. It offers a more intuitive, personalized, and efficient user experience, focusing on productivity and accessibility. It’s essential to be familiar with both, as many instances are still on UI16 while newer implementations or upgrades leverage Next Experience.

Mastering User, Group, and Role Management

One of the most frequent tasks in ServiceNow involves managing who can do what. This requires a solid grasp of users, groups, and roles, both through the UI and via scripting.

The Essentials: User and Group Tables

Understanding the fundamental tables is the bedrock of effective scripting in ServiceNow.

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

Answer: Absolutely, you can add roles (permissions) to both users and groups, either manually through the UI or programmatically using GlideRecord scripts. The undisputed best practice is to add permissions to groups, not directly to individual users. Why?

Scalability: Managing roles for a large number of users becomes cumbersome. Assigning roles to groups simplifies this immensely.
Consistency: Ensures all members of a specific group have the same access level.
Maintainability: When an employee joins, you add them to relevant groups; when they leave, you remove them from groups. The roles are automatically managed, reducing the risk of orphaned permissions or security vulnerabilities.
Auditability: It’s clearer to see who has what role based on their group membership rather than individual assignments.

4. What is the user table name?

Answer: The user table is named sys_user. This table stores all user records in the ServiceNow instance, including details like username, name, email, department, location, etc.

5. What is the group member table name?

Answer: The group member table, which stores the relationships between users and groups, is named sys_user_grmember. Each record in this table signifies that a particular user is a member of a specific group.

Scripting User and Group Creation

Automation is at the heart of ServiceNow. Knowing how to create foundational records like users and groups via script is a fundamental skill.

6. How to create a user account using script?

Answer: You’d use a GlideRecord to interact with the sys_user table. Here’s a common example:

var userGr = new GlideRecord('sys_user');
userGr.initialize(); // Prepares a new record for insertion
userGr.user_name = 'jdoe'; // It's 'user_name', not 'username' in sys_user
userGr.first_name = 'John'; // It's 'first_name', not 'firstname'
userGr.last_name = 'Doe'; // It's 'last_name', not 'lastName'
userGr.email = 'jdoe@example.com';
userGr.insert(); // Saves the new record to the database
gs.info("User jdoe created successfully!");

Interview Tip: Pay attention to field names! While username and firstname might be intuitive, ServiceNow often uses snake_case (e.g., user_name, first_name). Double-checking schema is a good habit. Also, mention initialize() as it prepares a new record for population and insertion.

7. How to create a group using script?

Answer: Similar to users, groups are created using GlideRecord on the sys_user_group table.

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Testing Group'; // The group's display name
// For reference fields like 'manager', you typically set the sys_id of the user
// Example: newGr.manager = '62826bf03710200044e0bfc8bcbe5df1';
newGr.email = 'testing@example.com';
newGr.description = 'This is a test group for demonstration.';
newGr.insert();
gs.info("Group 'Testing Group' created successfully!");

Note on sys_id: In actual production, you’d retrieve the manager’s sys_id dynamically or use a known sys_id from your instance. The example '62826bf03710200044e0bfc8bcbe5df1' is a placeholder.

Granting Permissions: Roles and Scripting

Roles are crucial for access control. Understanding how to assign them programmatically is vital for advanced automation.

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

Answer: Permissions (roles) are assigned by creating records in specific “has_role” tables.

For a User: When a role is added to a user, a record is created in the sys_user_has_role table.

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
// For 'user' and 'role' reference fields, always set the sys_id
// Replace with actual sys_ids for the user and role you want to assign
userRole.setValue('user', '62826bf03710200044e0bfc8bcbe5df1'); // sys_id of the user
userRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // sys_id of the role (e.g., itil_admin)
userRole.insert();
gs.info("Role assigned to user successfully!");

For a Group: When a role is added to a group, a record is created in the sys_group_has_role table. This aligns with the best practice discussed earlier.

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
// Replace with actual sys_ids for the group and role
grpRole.setValue('group', '477a05d153013010b846ddeeff7b1225'); // sys_id of the group
grpRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // sys_id of the role
grpRole.insert();
gs.info("Role assigned to group successfully!");

Important: Always use sys_id for setting reference fields in GlideRecord scripts. The setValue() method is a robust way to do this.

Advanced User Management Concepts

Beyond basic creation, ServiceNow offers features to handle complex user scenarios like temporary access or testing.

9. What exactly does user delegation mean in ServiceNow?

Answer: User delegation is a powerful feature that allows one user to temporarily act on behalf of another user within the organization. This is invaluable when the primary user is unavailable (e.g., on vacation, leave, or off-shift). The delegated user gains specific permissions to perform tasks and access resources that would normally only be available to the original user.

Real-world Example: Imagine a manager going on a two-week holiday. They can delegate their approval tasks to a colleague. This ensures that critical workflows, like approving expense reports or change requests, continue smoothly without interruption, preventing bottlenecks.

To configure this, an original user typically navigates to their profile, scrolls down to the “Delegates” related list, and specifies the delegate’s name, start/end dates, and which types of tasks (assignments, notifications, approvals) the delegate can handle.

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

Answer: Managing group membership programmatically is a common requirement for integrations or mass updates. You interact with the sys_user_grmember table.

Adding a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
// Replace with actual sys_ids of the user and group
grMem.user = '62826bf03710200044e0bfc8bcbe5df1'; // sys_id of the user to add
grMem.group = '477a05d153013010b846ddeeff7b1225'; // sys_id of the group
grMem.insert();
gs.info("User added to group successfully!");

Removing a Group Member:

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

if (grMem.next()) {
    grMem.deleteRecord(); // Deletes the found record
    gs.info("User removed from group successfully!");
} else {
    gs.info("User was not found in the specified group.");
}

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

Answer: A web services user (or integration user) is a specialized type of user account in ServiceNow designed exclusively for third-party applications or external systems to connect and interact with the instance via web services (REST, SOAP). The key characteristic is that this user cannot log in to the ServiceNow UI directly. Their sole purpose is to authenticate and perform actions (like creating incidents, querying data) through API calls. This enhances security by providing a dedicated, non-human access point with specific, often limited, roles.

17. What is impersonation?

Answer: Impersonation is a powerful debugging and testing feature in ServiceNow. It allows an administrator (or a user with the user_admin role) to temporarily “log in” as another user without knowing their password. While impersonating, the admin experiences the platform exactly as that user would, seeing their dashboards, menus, and access restrictions. This is incredibly useful for troubleshooting access issues, testing UI policies, or validating workflows from a specific user’s perspective. It’s crucial for ensuring that new features or changes work correctly for different user roles.

18. What is user preference?

Answer: User preferences in ServiceNow allow individual users to customize various aspects of their personal interface and experience. These preferences are stored in the sys_user_preference table and are unique to each user. When a user changes a preference (e.g., selecting a different theme, adjusting the number of rows per list, or configuring notification settings), these changes only impact that specific user; they do not affect other users or the global system settings. This empowers users to tailor their environment to their working style without requiring administrative intervention.

Scripting Power: Client vs. Server Side & User Information

Knowing the difference between client-side and server-side scripting, and how to access user information in both contexts, is fundamental.

Who Am I? Getting Current User Details

Accessing the current user’s details is a very common requirement in scripts.

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

Answer: On the client side (scripts running in the browser, like Client Scripts or UI Policies with ‘Run scripts’ enabled), you use the g_user object.

var currentUserID = g_user.userID; // Returns the sys_id of the current user
// Example output: '6816f79cc0a8016401c5a33be04be441'
alert('Client-side User ID: ' + currentUserID);

Context: g_user is a global object available in client-side scripts. It provides information about the currently logged-in user, their roles, and preferences.

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

Answer: On the server side (scripts running on the ServiceNow server, like Business Rules, Script Includes, Workflow Scripts), you use the gs (GlideSystem) object.

var currentUserID = gs.getUserID(); // Returns the sys_id of the current user
// Example output: '6816f79cc0a8016401c5a33be04be441'
gs.info('Server-side User ID: ' + currentUserID);

Context: gs is a global object available in server-side scripts. It provides utility functions, logging capabilities, and access to system-level information, including user details.

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

Answer: This is a common requirement for enforcing access or tailoring UI.

// Server-side
if (gs.getUser().isMemberOf('ITIL Group')) {
    gs.info('Current user is a member of ITIL Group.');
} else {
    gs.info('Current user is NOT a member of ITIL Group.');
}

// Client-side (Note: g_user.hasRole() is common for roles, but for groups,
// you might need a GlideAjax call to the server for a truly dynamic check,
// or check roles derived from group membership if those are sufficient.)
// For a direct client-side check if a user is a member of a *specific* group
// based on g_user, it's not as straightforward as gs.getUser().isMemberOf().
// A more robust client-side check often involves a GlideAjax call to a Script Include
// that uses gs.getUser().isMemberOf().

Best Practice: For server-side checks, gs.getUser().isMemberOf('group name') is highly efficient. For client-side, consider the implications of performance if you are making multiple GlideAjax calls. Often, checking if the user has a *role* that is granted by the group is sufficient: g_user.hasRole('itil').

Access Control Essentials

Security is paramount. Knowing how to control access is a core developer skill.

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

Answer: To create, modify, or delete Access Control Lists (ACLs), you need the security_admin role. This role is highly privileged and ensures that only authorized personnel can manage fundamental platform security. For elevated security, ServiceNow often requires a “security admin elevation” where a user with the security_admin role must click a specific button to temporarily enable the role for their session, making changes in a separate elevated session.

ITSM Core: Incident, Problem, and Change Management

These are the foundational processes in IT Service Management. Understanding their definitions and interrelationships is non-negotiable.

Understanding the Pillars of ITSM

19. What is an Incident?

Answer: An Incident is an unplanned interruption to an IT service or a reduction in the quality of an IT service. Essentially, something that *was* working has stopped working, or is working poorly. The goal of Incident Management is to restore normal service operation as quickly as possible and minimize the adverse impact on business operations. Users report incidents when they encounter issues like “my email isn’t working” or “I can’t access the shared drive.”

20. What is a Problem?

Answer: A Problem is the cause of one or more incidents. It’s often not immediately known at the time of an incident. Problem Management focuses on identifying the root cause of incidents, preventing recurrence, and minimizing their impact. If the same issue (e.g., “my printer isn’t working”) repeatedly occurs to the same employee, or if multiple employees simultaneously experience the same incident (e.g., a network outage), it often signals an underlying problem. In the latter case, a “parent incident” might be created for the network outage, with individual user incidents linked as “child incidents.” When the parent incident is resolved, child incidents can be automatically closed.

Interconnecting ITSM Processes

ITSM processes are rarely isolated; they often flow into one another.

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

Answer: Yes, absolutely. This is a common and crucial workflow in ITSM. If an incident recurs frequently, or if a single incident points to a deeper, underlying systemic issue, a Problem record is created directly from that incident. The incident then gets linked to the problem, signifying that the root cause investigation is underway and a permanent fix is being sought.

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

Answer: Yes. If a support engineer resolves an incident and realizes that the permanent solution requires a modification to an IT service, system, or infrastructure (e.g., a software upgrade, a configuration change, or a new hardware deployment), they will initiate a Change Request directly from the incident. This ensures that changes are formally planned, approved, and executed to prevent future incidents and maintain service stability.

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

Answer: These three processes form the core interconnected pillars of IT Service Management (ITSM):

Incident: Deals with immediate service disruption. A user reports an issue (an incident). The focus is on quick restoration.
Problem: Investigates the root cause of recurrent or major incidents. If an incident keeps happening or impacts many users, it might stem from an underlying problem. A problem record is often created from an incident.
Change: Manages modifications to the IT environment. Once a problem’s root cause is identified, a permanent fix (e.g., a software patch, a new configuration) might require a formal Change Request to be implemented safely. Changes can also be initiated directly from incidents if a modification is needed to resolve it, or as part of planned service improvements.

In essence: Incidents are symptoms, Problems seek the cure (root cause), and Changes implement the remedy (solution). They work together to restore service, prevent recurrence, and improve the IT landscape.

Scripting ITSM Record Creation

Automating the creation of ITSM records is a common requirement for integrations, self-service portals, or batch operations.

23. How to create an Incident record using script?

Answer: You’ll use GlideRecord on the incident table.

var gr = new GlideRecord('incident');
gr.initialize();
// Remember to use sys_ids for reference fields like caller_id, cmdb_ci, assignment_group
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // sys_id of a user
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // sys_id of a configuration item
gr.short_description = 'Test incident record created via script';
gr.description = 'This is a detailed description of the incident created by a server-side script.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of an assignment group
gr.insert();
gs.info("Incident " + gr.number + " created successfully!");

Key Point: For reference fields (like caller_id, cmdb_ci, assignment_group), always assign the sys_id of the referenced record, not its display name.

24. How to create a Problem record using script?

Answer: Similar to incidents, but targeting the problem table.

var gr = new GlideRecord('problem');
gr.initialize();
// For problem, 'opened_by' might be more common than caller_id depending on context
gr.opened_by = '86826bf03710200044e0bfc8bcbe5d94'; // sys_id of a user
gr.category = 'software';
gr.subcategory = 'operating_system';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // sys_id of a CI
gr.short_description = 'Test problem record from script: Repeated application crashes';
gr.description = 'Investigating frequent crashes of the XYZ application across multiple users.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of an assignment group
gr.insert();
gs.info("Problem " + gr.number + " created successfully!");

25. How to create a Change Request using script?

Answer: Targeting the change_request table.

var gr = new GlideRecord('change_request');
gr.initialize();
// Change requests have specific fields like 'requested_by' or 'start_date' and 'end_date'
gr.requested_by = '86826bf03710200044e0bfc8bcbe5d94'; // sys_id of a user
gr.category = 'software';
gr.subcategory = 'upgrade';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // sys_id of the CI being changed
gr.short_description = 'Server OS upgrade for XYZ application server';
gr.description = 'Planned upgrade of operating system on XYZ server to enhance security and performance.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // sys_id of an assignment group
gr.type = 'normal'; // e.g., 'normal', 'standard', 'emergency'
gr.insert();
gs.info("Change Request " + gr.number + " created successfully!");

Automating ITSM Workflows with Business Rules

Business Rules are critical for server-side automation and enforcing business logic.

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

Answer: This is a classic Business Rule scenario. You’d implement an “after” Business Rule on the Incident table.

Business Rule Configuration:

Name: Close Child Incidents
Table: Incident [incident]
When: After
Update: Checked (true)
Condition: current.state.changesTo(7) && current.parent.nil()
(Assuming ‘7’ is the value for ‘Closed’ state and current.parent.nil() ensures it’s a parent incident, not a child of another parent.)

Script:

if (current.state == 7 && current.parent.nil()) { // Ensure it's the parent incident getting closed
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id); // Find all incidents where this incident is the parent
    grChild.addQuery('state', '!=', 7); // Only close children that are not already closed
    grChild.query();

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

Interview Tip: Explain why it’s an “after” business rule (to ensure the parent incident itself is updated first) and why you add a condition for current.parent.nil(). Also, briefly mention current.state.changesTo(value) for robust state change detection.

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: This requires a “before” Business Rule to prevent the update.

Business Rule Configuration (for Incident):

Name: Prevent Incident Closure with Open Tasks
Table: Incident [incident]
When: Before
Update: Checked (true)
Condition: current.state.changesTo(7) (Assuming ‘7’ is ‘Closed’)

Script:

if (current.state == 7) { // Check if the incident is being closed
    var grTask = new GlideRecord('incident_task');
    grTask.addQuery('incident', current.sys_id);
    grTask.addQuery('active', true); // Check for active tasks (not just state != 3)
    grTask.addQuery('state', '!=', 3); // Assuming 3 is the state value for 'Closed' or 'Complete'
    grTask.query();

    if (grTask.hasNext()) { // If there are any open tasks
        gs.addErrorMessage('Cannot close the incident ' + current.number + ' because there are open tasks associated with it. Please close all tasks first.');
        current.setAbortAction(true); // Abort the current update operation
    }
}

Adaptation: For Problem and Change Request, you’d apply similar logic on their respective task tables (problem_task and change_task) and primary tables (problem and change_request).

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

Answer: Another “after” Business Rule, this time on the Problem table.

Business Rule Configuration:

Name: Close Incidents from Problem
Table: Problem [problem]
When: After
Update: Checked (true)
Condition: current.state.changesTo(7) (Assuming ‘7’ is the ‘Closed’ state for problems)

Script:

if (current.state == 7) { // If the problem is being closed
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Find incidents linked to this problem
    grIncident.addQuery('state', '!=', 7); // Only close incidents that are not already closed
    grIncident.query();

    while (grIncident.next()) {
        grIncident.state = 7; // Set the state to Closed
        grIncident.comments = "Automatically closed because the associated Problem " + current.number + " was closed.";
        grIncident.update(); // Update the incident
    }
}

ServiceNow Tables: The Backbone of the Platform

Understanding ServiceNow’s table structure is foundational for any developer. It influences how you query data, build relationships, and manage information.

Demystifying Table Types and Naming Conventions

30. Give me some names of out-of-the-box tables?

Answer: Out-of-the-box (OOTB) tables are those provided by ServiceNow directly, without custom development. They generally do not start with prefixes like u_ (for custom tables) or x_ (for tables in a scoped application).

Examples include: incident, problem, change_request, sc_req_item (Requested Item), sys_user (User), sys_user_group (Group), cmdb_ci (Configuration Item), task, sys_dictionary, sys_script, etc.

31. What are some of the base tables?

Answer: Base tables are tables that do not extend any other table but are often extended by many other tables. They act as parents in the table hierarchy.

Key examples are:

task: Extended by Incident, Problem, Change Request, Request Item, etc. It provides common fields like Number, State, Assignment Group, Short Description.
cmdb_ci: The base table for all Configuration Items (CIs). Extended by servers, network devices, software, etc.
sys_user: The base table for all user records. While not typically extended in the same way as task or cmdb_ci for functional records, it serves as a foundational “base” for user data.

32. Give me some examples of task tables?

Answer: Task tables are those that extend the base task table. They inherit all fields and behaviors from the task table and add their own specific fields.

Examples: incident, problem, change_request, sc_req_item (Requested Item), sc_task (Catalog Task), hr_case (HR Case), etc.

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

Answer:

Normal Tables: These tables store data permanently in the ServiceNow database. Records remain until explicitly deleted. Most tables you interact with (incident, sys_user, etc.) are normal tables.
Temporary Tables: These tables are designed to store data for a short, predefined period. They automatically purge records after a certain retention period (defaulting to 7 days). They typically extend the import_set_row table, making them suitable for transient data, like records processed during data imports, where the raw import data isn’t needed long-term. They are useful for performance and managing database size for non-critical, temporary data.

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

Answer: Yes, you can. Although temporary tables have a default retention period (often 7 days), you can modify this using archive rules. By creating an archive rule for the temporary table and configuring its criteria and retention period, you can effectively extend how long data is kept before being automatically purged. This gives you flexibility while still leveraging the benefits of temporary tables for certain use cases.

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

Answer:

Normal Tables: As discussed, these tables store data directly within the ServiceNow instance’s database. When you query a normal table, you are accessing data resident in ServiceNow.
Remote Tables: Introduced to allow ServiceNow to interact with external data sources as if they were native tables. A remote table definition in ServiceNow doesn’t store any data itself. Instead, it acts as a proxy, providing a schema definition and a mechanism (e.g., a connection to an external database, a REST API endpoint) to retrieve data directly from an external system in real-time. This means when you query a remote table, you are getting live data from the external system, not a snapshot stored in ServiceNow.

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

Answer: These terms describe relationships between records in different tables:

One-to-One Relationship: A single record in Table A is associated with exactly one record in Table B, and vice-versa. While less common for core data, an example might be a custom table storing sensitive user preferences where each preference record is uniquely tied to a sys_user record.
One-to-Many Relationship: A single 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: Users and Incidents. One user (sys_user) can have many incidents (incident) opened by them, but each incident is typically opened by only one user. This is often implemented using a reference field on the “many” side pointing to the “one” side (e.g., caller_id on the incident table references sys_user).
Many-to-Many Relationship: A single record in Table A can be associated with multiple records in Table B, and a single record in Table B can be associated with multiple records in Table A.

Example: Incidents and Affected CIs. One incident might affect multiple Configuration Items (e.g., a server and a database), and one CI might be affected by multiple incidents. This relationship is typically managed through an intermediate many-to-many table (e.g., task_ci for tasks and CIs, or m2m tables for custom relationships), where each record in the intermediate table links one record from Table A to one record from Table B.

44. All tables will be stored where?

Answer: All table definitions (their metadata, including names, columns, relationships, etc.) in a ServiceNow instance are stored in the sys_db_object table. This is essentially ServiceNow’s schema definition table.

Table Creation and Extension

33. Whenever we create a table, how many access controls will get created?

Answer: When you create a new table in ServiceNow and leave the “Create access controls” checkbox selected (which is the default behavior), four (4) Access Control Lists (ACLs) will be automatically created for that table. These ACLs grant basic ‘create’, ‘read’, ‘write’, and ‘delete’ permissions, usually to the admin role by default, or roles specified by the application scope. If you uncheck this box, no ACLs will be automatically generated, and you’ll have to create them manually to control access.

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

Answer: When creating a new table (or modifying an existing one to add auto-numbering), you typically configure this in the table’s “Controls” tab in its dictionary entry. You specify:

Prefix: A string that comes before the number (e.g., ‘INC’ for Incident, ‘PRB’ for Problem).
Number: The starting number for the sequence.
Number of digits: How many digits the number should have (e.g., 7 for INC0000001).
Ensure the “Auto-number” checkbox is selected.

This configuration ensures that each new record created in that table automatically gets a unique, sequentially generated number.

35. What happens when you extend a table?

Answer: When you extend a table (create a child table from a parent table):

Field Inheritance: The child table inherits all fields (columns) from its parent table. These inherited fields are not physically created again in the child table’s definition; they exist in the parent.
sys_id & Standard Fields: Core system fields like sys_id, sys_created_on, sys_updated_by, etc., are also inherited from the base table of the hierarchy (often the sys_metadata table indirectly). They are not “re-created” for each child.
‘Class’ Field: A special field called Class is automatically added to the parent table. This field stores the name of the actual table where the record resides (e.g., if you look at a record from the task table that is actually an incident, its Class field would show ‘incident’). This allows polymorphic behavior, where a single query on the parent table can return records from any of its children.
Single Class Field: Regardless of how many tables extend a parent, that parent table will only have one Class field. It won’t create a new Class field for each new child table that extends it.

Field Types and Their Nuances

36. Can you give me 10 field types?

Answer: ServiceNow offers a rich variety of field types to accommodate different data requirements. Here are ten common ones:

String: For short text entries (e.g., Short description, Name).
Reference: Links to a record in another table (e.g., Caller on Incident links to sys_user).
List: A specialized reference field that allows linking to multiple records in another table (e.g., Watch list).
Choice: Provides a dropdown list of predefined options (e.g., State, Category).
Email: Stores email addresses, often with built-in validation.
Date/Time: Stores both date and time values.
Date: Stores only date values.
Boolean: A true/false or yes/no field (e.g., Active).
Integer: Stores whole numbers.
Journal: A field designed to capture ongoing text updates, often retaining a historical log (e.g., Work notes, Comments).
Attachment: Allows users to upload files associated with the record.

Enhancing Data and Form Behavior: Dictionary & UI Goodies

Controlling how fields behave and appear on forms is crucial for user experience and data integrity. This involves leveraging dictionary entries, UI policies, and data policies.

Controlling Field Behavior: Dictionary Properties & Overrides

The data dictionary is where all field definitions reside, offering immense power to customize behavior.

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

Answer: This is a key question showing understanding of platform configuration hierarchy. You can control field behavior in several ways, with different scopes and execution contexts:

Dictionary Entry (Column Definition):
- Mandatory: Directly set the ‘Mandatory’ checkbox on the field’s dictionary entry. This is the strongest method, enforced globally at the database level.
- Read-only: Set the ‘Read-only’ checkbox. Also globally enforced.
Dictionary Overrides: Applied to a child table to override a parent table’s dictionary definition for a specific field. Allows for making a field mandatory/read-only/hidden only on the child table.
UI Policies:
- Client-side: Applied to forms. Can make fields mandatory, read-only, or hidden based on conditions. These execute in the browser.
- Scripting: If ‘Run scripts’ is enabled, you can use g_form.setMandatory(), g_form.setReadOnly(), g_form.setVisible().
Data Policies:
- Server-side & Client-side: Can make fields mandatory or read-only based on conditions. Enforced at the database level (like dictionary) but can also apply on forms (like UI Policies). Works across all data input methods (forms, web services, imports).
Client Scripts: Directly use g_form.setMandatory(), g_form.setReadOnly(), g_form.setVisible() for complex, dynamic client-side logic.
ACLs (Access Control Lists): Can make fields effectively “hidden” or “read-only” by restricting read or write access at the database level.

Hierarchy Consideration: Data Policy (if applied to client) > UI Policy > Client Script. Dictionary is lowest level, always enforced. ACLs are orthogonal, blocking access irrespective of other settings.

43. Can we make 2 fields as display in one table?

Answer: No, you should not and cannot explicitly set two fields as the “display value” in a single table. A table can only have one designated display field. The display value is what is shown in reference fields, breadcrumbs, and other places where a record’s “name” is needed. If you try to set a second field as display, ServiceNow will default to the first string field it finds, or fall back to the sys_id. Having multiple display fields would lead to confusion and inconsistent behavior across the platform.

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

Answer: You can set a default value for a field to automatically populate it when a new record form is opened. This streamlines data entry and ensures consistency. Methods include:

Dictionary Entry: The simplest way. In the field’s dictionary entry, simply enter the desired value in the “Default value” field. This can be a static value or a JavaScript expression.
Dictionary Overrides: To set a default value for a field specifically on a child table that differs from its parent.
Client Scripts (onLoad): For more complex, dynamic default values that depend on other client-side conditions, you can use g_form.setValue('field_name', 'default_value'); in an onLoad client script.
Business Rules (before insert): For server-side default values or values that depend on server-side logic, use current.field_name = 'default_value'; in a before insert Business Rule.

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

Answer: Reference Qualifiers are powerful tools used to restrict the data visible in reference and List type fields. They ensure users only see relevant options, improving data quality and user experience.

There are three main types:

Simple Reference Qualifier:
- Description: This is the most basic type. You specify a fixed query string directly in the dictionary entry to filter records.
- Example: To show only active users in a ‘Caller’ reference field: active=true
- Use Case: When the filtering criteria are static and don’t depend on other values on the form.
Dynamic Reference Qualifier:
- Description: This type uses a predefined “Dynamic Filter Option” script to generate a query. It’s more flexible than simple, as the dynamic filter option can contain logic that adapts based on the context (e.g., current user, roles).
- Example: Displaying only CIs assigned to the current user’s department. You’d create a Dynamic Filter Option that builds this query, then select that option in the field’s dictionary.
- Use Case: When the filtering needs to be dynamic but can be encapsulated in a reusable, named filter option. It helps avoid repetitive complex scripts across multiple reference fields.
Advanced Reference Qualifier (JavaScript):
- Description: This is the most flexible and powerful type. You provide a custom JavaScript expression that evaluates to a valid encoded query string. This allows for highly complex, dynamic filtering based on multiple form fields, user properties, or server-side lookups.
- Example: Filtering Incidents to show only those assigned to the current user’s assignment group AND with a priority less than 3:
```
javascript: 'assignment_group=' + gs.getUser().getRecord().getValue('assignment_group') + '^priority<3';
```
- Use Case: When filtering logic is too complex for simple queries, depends on multiple form fields, requires server-side lookups, or involves custom business logic.

Differences:

Simple vs. Dynamic: Simple is static, fixed criteria. Dynamic uses a pre-defined script (Dynamic Filter Option) that can generate dynamic queries but is chosen from a list.
Dynamic vs. Advanced: Dynamic leverages existing named filter options for reusability. Advanced involves writing custom, ad-hoc JavaScript directly in the dictionary entry, offering maximum flexibility but potentially less reusability unless the script is in a Script Include.
Simple vs. Advanced: Simple is basic, static filtering. Advanced provides full JavaScript power for highly dynamic and complex filtering criteria.

49. What are dependent values?

Answer: Dependent values in ServiceNow refer to a mechanism (primarily for Choice fields) where the available options in one field are filtered and displayed based on the selection made in another field. This creates a cascading effect, guiding users to select appropriate choices and reducing errors.

Example:

Parent Field: 'Category' (Choices: Hardware, Software, Network)
Dependent Field: 'Subcategory'

Configuration Steps:

Ensure 'Category' has its choices defined.
Go to the dictionary entry of 'Subcategory'.
Set the 'Dependent field' attribute to 'Category'.
For each 'Subcategory' choice (e.g., 'Laptop', 'Desktop'), specify its 'Dependent value' as one of the 'Category' choices (e.g., 'Hardware').

Now, if a user selects 'Hardware' in 'Category', only 'Laptop', 'Desktop', etc., will appear in 'Subcategory'. If they select 'Software', 'Operating System', 'Application', etc., will appear.

50. What is a calculated value?

Answer: A calculated value (configured via the "Calculated" checkbox in a field's dictionary entry) allows a field's value to be determined dynamically by a server-side JavaScript expression rather than being stored directly in the database. When the field is accessed (read), the script is executed, and the resulting value is displayed. This is useful for fields whose values are derivations of other fields and don't need to be stored, saving database space and ensuring real-time accuracy. However, it can impact performance if calculations are complex or involve many records.

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

Answer: Attributes are special parameters added to a field's dictionary definition that modify its behavior or appearance on forms, lists, or in other parts of the platform. They are configured in the "Attributes" field of a dictionary entry (or dictionary override), typically as a comma-separated list of name=value pairs.

Some commonly used attributes:

no_email: Prevents the field's value from being included in email notifications.
no_attachment: Disables the ability to attach files to records when applied to a table's collection attribute.
no_add_me: For reference fields, hides the "add me" button that allows users to create new records directly from the reference field.
tree_picker=true: Displays a reference field as a tree picker for hierarchical data.
max_length=X: Overrides the default string length.
ref_ac_columns=field1;field2: Displays additional columns in the auto-complete dropdown for a reference field.
edge_encryption_enabled=true: Designates a field for Edge Encryption.

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

Answer: Dictionary overrides are a powerful feature that allows you to change the dictionary definition of a field specifically for a child table, without affecting its behavior on the parent table or other sibling tables. This is crucial for managing inheritance while allowing for table-specific customizations.

For example, a priority field inherited from the task table might have a default value of '4' globally. Using a dictionary override on the incident table, you could change its default value to '5' specifically for incidents, or make it mandatory. The priority field on problem or change_request would remain unaffected.

Properties you can typically override include:

Default value: Set a different initial value.
Mandatory: Make the field mandatory or optional.
Read only: Make the field read-only or editable.
Active: Control if the field is active on the child table.
Reference qualifier: Apply a different filter to a reference field.
Choice list specification: Modify how choices are displayed or filtered (e.g., dropdown vs. lookup).
Display: (Though rare, sometimes you might use this with specific context or for specialized fields).
Attributes: Add or modify specific attributes.

Essentially, dictionary overrides let you customize almost any aspect of a field's dictionary definition on a child table.

Table-Level Attributes: The Collection Field

52. What is the collection field on a table?

Answer: The "Collection" type dictionary entry for a table isn't a field in the traditional sense. Instead, it represents the entire table itself within the dictionary. Every time you create a new table, ServiceNow automatically creates a dictionary entry of type "Collection" for it. Changes applied to this entry (such as certain attributes or the 'Read only' checkbox) are applied to the table as a whole, rather than to a specific field. It's a way to configure table-level properties.

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

Answer: To control attachments for an entire table (and thus its forms), you add or remove the no_attachment attribute to the table's Collection type dictionary entry.

Disable attachments: Add no_attachment=true to the "Attributes" field of the Collection dictionary entry for that table.
Enable attachments: Remove the no_attachment attribute from the Collection dictionary entry (or ensure it's not present).

This setting will affect all forms and records associated with that table, preventing or allowing file uploads.

Form Interactions: UI Policies vs. Data Policies

These two mechanisms are often confused, but they serve distinct purposes and operate at different layers of the platform.

58. What are UI policies?

Answer: UI Policies are client-side logic used to dynamically modify the behavior of fields on a form (and sometimes related lists) based on conditions. They execute in the user's browser.

Common uses include:

Making fields mandatory based on other field values.
Making fields read-only based on conditions.
Hiding or showing fields dynamically.
Showing/hiding related lists (with 'Run scripts' enabled).

They are primarily about enhancing the user experience on the form and enforcing client-side validation.

59. What is the 'Global' checkbox in UI Policies?

Answer: When the 'Global' checkbox is selected (checked) in a UI Policy, that policy will apply to all views of the form for the specified table. If you uncheck the 'Global' checkbox, a "View" field will appear, allowing you to select a specific form view (e.g., 'Default view', 'Self Service view'). In this scenario, the UI Policy will only apply when the form is rendered using that particular view, giving you granular control over form behavior for different audiences or use cases.

60. What is 'Reverse if false' in UI Policies?

Answer: The 'Reverse if false' checkbox is a very convenient feature in UI Policies. When checked, if the UI Policy's condition initially evaluates to true and then later evaluates to false (e.g., a user changes a field value), the actions defined in the UI Policy will be automatically reversed.

Example: If a field was made mandatory when a condition was true, it will become optional again when the condition becomes false. If a field was hidden, it will become visible again. This saves you from writing separate UI Policies or scripts to undo the initial actions.

61. What is the 'On Load' checkbox in UI Policies?

Answer: When the 'On Load' checkbox is selected in a UI Policy, the policy's conditions and actions are evaluated and applied immediately when the form loads in the browser. This ensures that the form's initial state (e.g., which fields are visible, mandatory, or read-only) is correctly set based on the initial record data or user context. If 'On Load' is *not* selected, the UI Policy will only trigger its actions when a field relevant to its conditions is changed by the user on the form, or when other conditions are met post-load. It won't affect the initial rendering of the form.

62. What is the 'Inherit' checkbox?

Answer: When the 'Inherit' checkbox is selected in a UI Policy, that UI Policy will also apply to all child tables that extend the table on which the UI Policy is defined. This allows you to define a UI Policy once on a parent table (like task) and have its effects automatically extend to child tables (like incident, problem, change_request), promoting consistency and reducing redundant configuration.

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

Answer: Yes, you absolutely can write client-side JavaScript within a UI Policy. To do this, you must check the 'Run scripts' checkbox within the UI Policy definition. Once checked, two script fields appear: "Execute if true" and "Execute if false." These fields allow you to write JavaScript that executes when the UI Policy's condition evaluates to true or false, respectively. This provides greater flexibility for complex client-side logic that goes beyond simple field visibility or mandatory states.

64. Can we convert a UI Policy as a Data Policy?

Answer: Yes, ServiceNow provides a utility to convert an existing UI Policy into a Data Policy. You can typically find a "Convert to Data Policy" or similar button/link when viewing a UI Policy record. This is a convenient way to elevate client-side form validation into server-side data integrity enforcement, ensuring the same rules apply regardless of how data enters the system.

65. Which cases where a UI Policy cannot be converted as a Data Policy?

Answer: A UI Policy cannot be reliably or fully converted into a Data Policy in certain scenarios because Data Policies operate at a deeper, database level and are primarily concerned with data integrity, whereas UI Policies focus on client-side form behavior. Key limitations for conversion are:

Controlling Data Visibility (Hiding/Showing Fields): Data Policies cannot hide or show fields. They only control mandatory and read-only states. Hiding fields is a UI-specific action.
Controlling Views: UI Policies can be tied to specific form views. Data Policies are global across all views and data entry points.
Controlling Related Lists: UI Policies with 'Run scripts' can show/hide related lists. Data Policies have no control over related lists.
Client-Side Scripting: If a UI Policy heavily relies on complex client-side JavaScript (using g_form methods for dynamic calculations, alerts, etc.), that script logic cannot be directly translated into a Data Policy, which is declarative or uses server-side logic if 'Run server-side as well' is checked.
'Reverse if false' functionality: While Data Policies have an equivalent to reverse if false for mandatory/read-only, complex UI Policy scripts for 'Execute if false' won't convert directly.

In essence, if the UI Policy performs actions beyond making fields mandatory or read-only, especially those related to UI presentation or complex client-side interactions, it's not a candidate for direct conversion.

66. What are Data Policies?

Answer: Data Policies are a crucial mechanism for enforcing data consistency and integrity across all input channels in ServiceNow. Unlike UI Policies, which are primarily client-side (though they can influence server-side if converted), Data Policies operate at both the client-side (form) and server-side (database).

They are used to:

Make fields mandatory.
Make fields read-only.
(Less common) Make fields visible/hidden (though primarily for mandatory/read-only).

The key differentiator is that Data Policies ensure these rules are applied regardless of how data is entered—whether through a form, a script, an import set, or a web service. This prevents invalid data from entering the system, ensuring high data quality, which is critical for reporting and business processes.

GlideRecord and Record Creation Mechanisms

GlideRecord is the core API for database interaction, and knowing various ways to create records highlights your flexibility.

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

Answer: There are multiple avenues to create records in ServiceNow, catering to different use cases and user types:

Form Submission: The most common way, through the standard ServiceNow user interface forms.
Record Producer: A specific type of catalog item that allows users to create records in non-catalog tables (e.g., creating an Incident from the Service Portal). It simplifies the form and maps variables to target table fields.
Email Inbound Actions: ServiceNow can process incoming emails and create records (e.g., incidents, requests) based on the email content, subject, and sender.
GlideRecord Scripting: Programmatically create records using server-side JavaScript (new GlideRecord('table').initialize().insert()) in Business Rules, Script Includes, background scripts, etc.
Import Sets / Excel Sheets: Bulk import records from external data sources (like Excel, CSV, XML) into an import set table, then transform them into target production tables.
Integrations / Web Services (REST/SOAP): External systems can create records in ServiceNow by sending data via web service APIs (REST or SOAP).
Service Catalog Requests (sc_req_item): When a user orders a service catalog item, it typically creates a Request (sc_request) and a Requested Item (sc_req_item), and potentially associated tasks.

46. What is the 'current' object?

Answer: The current object is a server-side JavaScript object that is available primarily within Business Rules and Script Includes called from Business Rules. It represents the record currently being inserted, updated, or deleted in the database.

You use the current object to:

Get values: current.field_name (e.g., current.state to get the new state value).
Set values: current.field_name = 'new_value' (e.g., current.comments = 'Added by BR'). These changes will be saved when the Business Rule finishes execution, or you can call current.update() explicitly in an after Business Rule.

It's a powerful way to interact with the record that triggered the Business Rule or is being acted upon.

47. How to set the field values on the current form?

Answer: When working with the current object on the server-side (e.g., in a Business Rule):

For standard fields: Directly assign the value: current.field_name = 'value';
For reference fields (using sys_id): You can also directly assign the sys_id: current.reference_field = 'sys_id_of_referenced_record';
Using setValue(): This is a more robust and explicit way, especially useful for reference fields where you provide the sys_id: current.setValue('reference_field', 'sys_id_of_referenced_record');
Using setDisplayValue(): This method allows you to set the value of a reference field by its display value (e.g., 'John Doe') rather than its sys_id. ServiceNow will then look up the corresponding sys_id. While convenient, it can be less performant and potentially ambiguous if multiple records have the same display value. Use with caution: current.setDisplayValue('reference_field', 'Display Name');

Note: On the client side (e.g., Client Scripts), you would use the g_form object: g_form.setValue('field_name', 'value'); or g_form.setDisplayName('field_name', 'Display Name');.

Conclusion: Your Path to ServiceNow Scripting Interview Success

Whew! That was a deep dive, wasn't it? Navigating ServiceNow scripting interviews can feel like a gauntlet, but by thoroughly understanding these concepts, you're not just memorizing answers; you're building a robust foundation in platform development. The key takeaways from this extensive guide are:

Understand the "Why": Don't just know *what* a UI Policy does, understand *why* you'd use it over a Data Policy, and *when* each is appropriate.
Master GlideRecord: It's your primary tool for server-side data manipulation. Be comfortable with initialize(), insert(), update(), query(), addQuery(), and deleteRecord().
Client vs. Server Side: Clearly articulate where scripts run, what global objects are available (g_form, g_user, gs), and their implications.
Best Practices are Paramount: Emphasize role management via groups, understanding table inheritance, and the appropriate use of different configuration options.
Think in Scenarios: Interviewers love problem-solving. Practice applying these concepts to real-world ITSM workflows and user management challenges.

Remember, your enthusiasm and ability to articulate complex ideas simply are just as important as your technical knowledge. Good luck with your interview! You've got this.