So, you’re gearing up for a ServiceNow developer or administrator interview? Excellent! You’ve likely spent hours perfecting your platform navigation, understanding ITSM processes, and perhaps even delving into Service Portal widget development. But let’s be honest, there’s one topic that almost guarantees a deep dive in every technical interview: GlideRecord.

GlideRecord is the beating heart of server-side scripting in ServiceNow. It’s your primary tool for interacting with the database – querying, inserting, updating, and deleting records. If you truly understand GlideRecord, you understand the fundamental way data moves and transforms within the platform. That’s why interviewers love to test your knowledge here.

This article isn’t just a list of questions and answers; it’s a deep dive into the “why” behind the “what,” packed with practical explanations, best practices, and the kind of insights that truly impress. Let’s get started and turn those interview jitters into confidence!

The Fundamentals: User, Group, and Role Management with GlideRecord

Managing users, groups, and roles is a cornerstone of ServiceNow administration. Interviewers frequently use these scenarios to gauge your understanding of fundamental data models and scripting practices. Get ready to show off your expertise!

Can We Add Permissions to Users and Groups? Which is the Best Practice? (Q3)

Answer: Absolutely, you can add roles (permissions) to both users and groups, both manually through the UI and programmatically using GlideRecord. However, the unequivocal best practice is to assign roles to groups, not directly to individual users.

Why this is crucial for an interview: This question isn’t just about knowing what’s possible; it’s about demonstrating your understanding of maintainability, scalability, and security best practices. Imagine an organization with thousands of users. If you assign roles directly to users, every time an employee’s role changes, or they leave the organization, you have to manually update their individual roles. This is a massive administrative overhead and prone to error.

By assigning roles to groups, you gain immense flexibility:

1. Simplified Management: When an employee joins, you simply add them to the relevant groups, and they instantly inherit all necessary roles.
2. Automated Removal: When an employee leaves, removing them from a group automatically revokes all associated roles, significantly reducing security risks and manual cleanup.
3. Consistency: Ensures that everyone in a specific functional area (e.g., “ITIL Users,” “Service Desk Agents”) has the exact same permissions.
4. Auditability: It’s easier to see which groups have which roles, and then which users are members of those groups, providing a clearer audit trail.

So, while direct assignment to users is technically possible, always advocate for and implement group-based role assignments. This shows a mature understanding of platform administration.

What is the User Table Name? (Q4)

Answer: The user table is named sys_user. This is a fundamental table you’ll interact with constantly.

What is the Group Member Table Name? (Q5)

Answer: The group member table is named sys_user_group. Wait, no! This is a common trick question in interviews. The sys_user_group table stores the definitions of your groups themselves. The table that links users to groups (i.e., defines group membership) is sys_user_grmember. Be careful here; understanding the subtle differences between table names demonstrates attention to detail.

How to Create a User Account Using Script? (Q6)

Interview Insight: This tests your basic GlideRecord insert operation and understanding of essential user fields.

var userGr = new GlideRecord('sys_user');
userGr.initialize(); // Prepares a new, empty record for insertion
userGr.user_name = 'jdoe'; // It's 'user_name', not 'username' - common typo!
userGr.first_name = 'John';
userGr.last_name = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.insert(); // Commits the new record to the database
gs.info("User " + userGr.user_name + " created with Sys ID: " + userGr.sys_id);
        

Explanation:

• new GlideRecord('sys_user'): Instantiates a GlideRecord object for the sys_user table.
• initialize(): This is crucial for creating new records. It populates default values and prepares the record for new data.
• userGr.fieldName = 'value': We assign values to the user record’s fields. Note the common field names like user_name, first_name, last_name, and email.
• insert(): This method saves the new record to the database. Without it, your changes exist only in memory.

Troubleshooting Tip: Always check required fields for the sys_user table in your instance (e.g., user_name, first_name, last_name are often mandatory). If you omit a required field, the insert() might fail silently or throw an error depending on the context.

How to Create a Group Using Script? (Q7)

Interview Insight: Similar to user creation, but for groups. Shows you understand different core tables.

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'New Testing Group'; // The name of the group is key
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Sys_id of a user
newGr.email = 'testing@tcs.com';
newGr.description = 'This is a test group created via script.';
newGr.insert();
gs.info("Group " + newGr.name + " created with Sys ID: " + newGr.sys_id);
        

Explanation: This follows the same pattern as creating a user. The important field here is name, which identifies the group. Fields like manager are reference fields, requiring the sys_id of the referenced record (in this case, a user).

How to Add Permissions (Roles) to a User/Group Account Using Script? (Q8)

Interview Insight: This is a critical question that assesses your understanding of role assignment tables and GlideRecord’s setValue() method, particularly for reference fields.

Adding a Role to a User:

When you assign a role directly to a user, a record is created in the sys_user_has_role table. While possible, remember our best practice discussion earlier!

// IMPORTANT: Replace with actual sys_ids for user and role
var userId = '62826bf03710200044e0bfc8bcbe5df1'; // Sys_id of the user
var roleId = '2831a114c611228501d4ea6c309d626d'; // Sys_id of the role (e.g., 'itil' role's sys_id)

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
userRole.setValue('user', userId); // 'user' is the field referencing sys_user
userRole.setValue('role', roleId); // 'role' is the field referencing sys_user_role
userRole.insert();
gs.info("Role assigned to user.");
        

Adding a Role to a Group (Best Practice!):

When you assign a role to a group, a record is created in the sys_group_has_role table. This is the recommended approach.

// IMPORTANT: Replace with actual sys_ids for group and role
var groupId = '477a05d153013010b846ddeeff7b1225'; // Sys_id of the group
var roleId = '2831a114c611228501d4ea6c309d626d'; // Sys_id of the role (e.g., 'itil' role's sys_id)

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
grpRole.setValue('group', groupId); // 'group' is the field referencing sys_user_group
grpRole.setValue('role', roleId);   // 'role' is the field referencing sys_user_role
grpRole.insert();
gs.info("Role assigned to group.");
        

Explanation for setValue(): When dealing with reference fields (like ‘user’ referencing sys_user, or ‘role’ referencing sys_user_role), it’s generally safer and more explicit to use setValue('fieldName', sys_id). While direct assignment (gr.fieldName = sys_id) often works, setValue() is considered best practice, especially when you need to be absolutely sure you’re setting the underlying reference and not just a display value.

How to Add and Remove a Group Member from a Group Using Script? (Q10)

Interview Insight: This demonstrates your ability to interact with junction tables (many-to-many relationships) and perform both insertion and deletion operations.

Adding a Group Member:

This involves creating a record in the sys_user_grmember table, linking a user to a group.

// IMPORTANT: Replace with actual sys_ids
var userId = '62826bf03710200044e0bfc8bcbe5df1'; // Sys_id of the user
var groupId = '477a05d153013010b846ddeeff7b1225'; // Sys_id of the group

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
grMem.user = userId;  // Reference to the user
grMem.group = groupId; // Reference to the group
grMem.insert();
gs.info("User added to group.");
        

Removing a Group Member:

To remove a member, you need to find the specific membership record in sys_user_grmember and then delete it.

// IMPORTANT: Replace with actual sys_ids
var userId = '62826bf03710200044e0bfc8bcbe5df1'; // Sys_id of the user
var groupId = '477a05d153013010b846ddeeff7b1225'; // Sys_id of the group

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', userId);  // Query for the specific user
grMem.addQuery('group', groupId); // Query for the specific group
grMem.query(); // Execute the query

if (grMem.next()) { // If a matching record is found
    grMem.deleteRecord(); // Delete that specific membership record
    gs.info("User removed from group.");
} else {
    gs.warn("User was not a member of the specified group.");
}
        

Explanation: The addQuery() method is essential for filtering records. You can chain multiple addQuery() calls to narrow down your search. query() executes the search, and next() iterates through any found records. deleteRecord() removes the current record being processed by next().

Contextual Scripting & System Utilities

Beyond manipulating records, ServiceNow scripting often requires understanding the current user’s context or environment. These questions test your knowledge of global server-side utilities.

How to Get the Current Logged-in User’s System ID in the Server Side? (Q14)

Answer: gs.getUserID();

Interview Insight: Simple but critical. gs (GlideSystem) is a ubiquitous server-side object. Knowing this immediately tells an interviewer you understand server-side scripting basics.

How to Check if the Current Logged-in User is a Member of a Particular Group? (Q15)

Answer: gs.getUser().isMemberOf('group name');

Explanation: This returns a boolean (true or false). It’s a handy way to control access or behavior based on group membership directly within server-side scripts like Business Rules or Script Includes. Remember to use the name of the group, not its sys_id.

Which Role is Required to Work on Access Control (ACL)? (Q16)

Answer: security_admin.

Interview Insight: This shows you understand elevated privileges and security within the platform. The security_admin role is transient; users must elevate to it to create, modify, or delete ACLs, enhancing security.

Common ITSM Record Creation Scenarios

Interviewers often want to see if you can apply your GlideRecord knowledge to real-world ITSM processes. Creating core records like Incidents, Problems, and Changes is a prime example.

How to Create an Incident Record Using Script? (Q23)

Interview Insight: Demonstrates practical application of GlideRecord for a core IT service management (ITSM) process.

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // Sys_id of the user who called
gr.category = 'inquiry';
gr.subcategory = 'antivirus';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3'; // Sys_id of the Configuration Item
gr.short_description = 'Test incident created via script';
gr.description = 'This incident was automatically generated by a server-side script.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys_id of the Assignment Group
// Other fields like 'impact', 'urgency', 'priority' can also be set.
gr.insert();
gs.info("Incident " + gr.number + " created with Sys ID: " + gr.sys_id);
        

Explanation: The pattern remains consistent: initialize(), set fields, and then insert(). Notice how reference fields like caller_id, cmdb_ci, and assignment_group require the sys_id of the referenced record. Setting these fields correctly is crucial for data integrity and reporting.

How to Create a Problem Record Using Script? (Q24)

Interview Insight: Reinforces the general GlideRecord pattern across different task types.

var gr = new GlideRecord('problem');
gr.initialize();
// Problem records typically don't have a 'caller_id' like incidents,
// but they can be linked to Incidents and Users.
// For simplicity, we'll reuse some fields, but be mindful of your instance's Problem form design.
gr.u_reported_by = '86826bf03710200044e0bfc8bcbe5d94'; // Custom field example for reporting user
gr.category = 'software';
gr.subcategory = 'operating system';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'New Problem identified via script';
gr.description = 'System slowness observed across multiple services. Investigating root cause.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
// Problem specific fields like 'fix_notes', 'workaround', etc., can also be set.
gr.insert();
gs.info("Problem " + gr.number + " created with Sys ID: " + gr.sys_id);
        

How to Create a Change Request Using Script? (Q25)

Interview Insight: Completes the trifecta of core ITSM record creation, showing versatility.

var gr = new GlideRecord('change_request');
gr.initialize();
// Change Requests are more complex, often requiring 'type', 'risk', 'priority', 'start_date', 'end_date', etc.
gr.type = 'normal'; // e.g., 'normal', 'standard', 'emergency'
gr.category = 'hardware';
gr.subcategory = 'server';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Scheduled Server Patching - DC1';
gr.description = 'Applying security patches to all Windows servers in Datacenter 1.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.requested_by = '86826bf03710200044e0bfc8bcbe5d94'; // User requesting the change
// Add other relevant change request fields as per your instance's configuration.
gr.insert();
gs.info("Change Request " + gr.number + " created with Sys ID: " + gr.sys_id);
        

Advanced Scripting Logic: Business Rules & Workflow

This is where GlideRecord truly shines – in automating processes and enforcing business logic. These questions test your ability to write conditional logic and manipulate related records, typically within Business Rules.

Write a Logic for Whenever a Parent Incident is Closed, All Child Incidents Should Also Get Closed. (Q26)

Interview Insight: This scenario tests your understanding of Business Rules, parent-child relationships, GlideRecord queries, and updates. It’s a classic example of automation.

Solution Strategy: This requires an After Business Rule on the incident table. “After” is crucial because we want the parent incident to be successfully closed first before we start closing its children.

// Business Rule Details:
// Table: incident
// When: After
// Update: True
// Condition: current.state.changesTo(7) && current.parent.nil()

// Script:
if (current.state == 7 && current.parent.nil()) { // Ensure the parent incident is indeed closing (state 7 for Closed)
    // GlideRecord to find child incidents
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id); // Query for children linked to this parent's sys_id
    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 (assuming 7 is 'Closed')
        grChild.comments = "Automatically closed as parent incident " + current.number + " was closed.";
        grChild.update(); // Update the child incident
        gs.info("Child Incident " + grChild.number + " closed due to parent " + current.number + " closure.");
    }
}
        

Explanation:

• current.state.changesTo(7): This condition is robust; it fires only when the state *changes to* 7, not just when it *is* 7.
• current.parent.nil(): Ensures this rule only applies to actual parent incidents (those without a parent themselves).
• grChild.addQuery('parent', current.sys_id): Finds all incidents where their ‘parent’ field references the sys_id of the current (parent) incident.
• grChild.next(): Iterates through each found child incident.
• grChild.update(): Saves the changes to each child incident.

Troubleshooting Tip: Ensure your state values (e.g., ‘7’ for Closed) match your instance’s configuration. It’s always a good idea to add comments or work notes to the child incidents to explain the automated closure.

There is an Incident and that Incident Has Two Associated Tasks. When You Try to Close that Incident, if Any Incident Task is Open, the Incident Should Not Be Closed. Similarly for Problem and Change Request. (Q27)

Interview Insight: This tests your ability to use a Before Business Rule to prevent an action based on related record states. It’s about data validation and process enforcement.

Solution Strategy: This requires a Before Business Rule on the incident table. “Before” is critical here because we want to stop the save operation *before* the incident officially closes if there are open tasks.

// Business Rule Details:
// Table: incident
// When: Before
// Update: True
// Condition: current.state.changesTo(7) // Fires only when attempting to close the incident

// Script:
if (current.state == 7) { // Check if the incident is being set to Closed
    var grTask = new GlideRecord('incident_task');
    grTask.addQuery('incident', current.sys_id); // Query for tasks associated with THIS incident
    grTask.addQuery('state', '!=', 3); // Assuming '3' is the state value for 'Closed' for incident tasks
    grTask.query();

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

Explanation:

• current.state.changesTo(7): Ensures the rule only runs when the user attempts to close the incident.
• grTask.addQuery('state', '!=', 3): This is key. It looks for tasks whose state is *not* ‘Closed’.
• grTask.hasNext(): Checks if the query returned any records. If it returns true, it means there are open tasks.
• gs.addErrorMessage(): Displays a message to the user on the form.
• current.setAbortAction(true): This is the magic line. It stops the current database operation (the update of the incident) from proceeding, effectively preventing the incident from being closed.

For Problem and Change Request: The logic would be nearly identical, but you’d adjust the table name (problem_task for Problem, change_task for Change Request) and the field linking them (problem for Problem Tasks, change_request for Change Tasks).

Whenever a Problem is Closed, the Associated Incidents Will Also Get Closed. (Q28)

Interview Insight: Similar to the parent-child closure, but demonstrates understanding of cross-application relationships (Problem to Incident). This is another common automation requirement.

Solution Strategy: This requires an After Business Rule on the problem table.

// Business Rule Details:
// Table: problem
// When: After
// Update: True
// Condition: current.state.changesTo(7) // Assuming '7' is the 'Closed' state for Problems

// Script:
if (current.state == 7) { // Check if the problem is being set to Closed
    // GlideRecord to find incidents associated with this problem
    var grIncident = new GlideRecord('incident');
    grIncident.addQuery('problem_id', current.sys_id); // Query for incidents linked to this problem
    grIncident.addQuery('state', '!=', 7); // Only close incidents that are NOT already closed (state 7 for Incident)
    grIncident.query();

    while (grIncident.next()) {
        grIncident.state = 7; // Set the incident state to Closed
        grIncident.comments = "Automatically closed as associated problem " + current.number + " was closed.";
        grIncident.update(); // Update the incident
        gs.info("Incident " + grIncident.number + " closed due to problem " + current.number + " closure.");
    }
}
        

Explanation: This follows the same pattern as the parent-child incident closure. The key difference is the field used to link records: problem_id on the incident table points to the sys_id of the problem record.

ServiceNow Table Architecture & Dictionary Concepts

A true ServiceNow expert understands not just how to script, but also the underlying data model. These questions delve into the architecture of tables and the configuration options available through the Dictionary.

Give Me Some Names of Out-of-the-Box Tables. (Q30)

Answer: Out-of-the-box (OOB) tables are those provided by ServiceNow that don’t start with prefixes like u_ (for custom tables) or x_ (for scoped application tables). Examples include: incident, problem, change_request, sys_user, sys_group, cmdb_ci, sc_req_item, sc_task, sys_choice, sys_journal_field.

Interview Insight: This tests basic platform terminology. It shows you can differentiate between native and custom elements.

What Are Some of the Base Tables? (Q31)

Answer: Base tables are tables that typically do not extend any other table, but are extended by many other tables. They form the foundation of major application areas. Key examples are task and cmdb_ci.

Explanation:

• task: The ultimate parent for all task-based records (Incident, Problem, Change, Service Catalog Task, etc.). It holds common fields like ‘number’, ‘short_description’, ‘assignment_group’, ‘state’.
• cmdb_ci: The parent table for all Configuration Items in the CMDB (servers, applications, databases, networks). It holds common fields for all CIs.

Understanding base tables is crucial for writing efficient and scalable code, as you can often query or script against the parent table to affect all its children.

Give Me Some Examples of Task Tables. (Q32)

Answer: Task tables are those that extend the task table. Common examples are incident, problem, and change_request, but also sc_task (Service Catalog Task), hr_task (HR Task), pm_project_task (Project Task), etc.

Whenever We Create a Table, How Many Access Controls Will Get Created? (Q33)

Answer: By default, when you create a new table through the ‘Tables’ module and leave the “Create access controls” checkbox checked, ServiceNow generates four ACLs (Access Control Lists) for that table:

• read
• create
• write
• delete

These ACLs typically grant access to users with the admin role by default, allowing administrators to manage records in the new table immediately. If you uncheck the box, no ACLs are created, and you’ll have to create them manually, otherwise, no one (not even admin) will have access to the table’s records by default!

How to Create a Number Field, Like an Incident Number? (Q34)

Answer: This is configured within the table definition itself, specifically on the ‘Controls’ tab. When creating a new table or modifying an existing one:

1. Navigate to the table record (System Definition > Tables).
2. Go to the ‘Controls’ tab.
3. Check the “Auto-number” checkbox.
4. Provide a ‘Prefix’ (e.g., “INC” for incidents, “PRB” for problems).
5. Specify the ‘Number of digits’ (e.g., 7 for INC0000001).

This automatically generates unique, sequential numbers for records inserted into that table.

What Happens When You Extend a Table? (Q35)

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

• Field Inheritance: The child table inherits all fields from the parent table. These inherited fields are not physically recreated in the child table’s database schema; they are effectively “linked.” This means less database overhead and consistent field definitions across related tables.
• No Duplicate System Fields: Standard system fields (like sys_id, sys_created_on, sys_updated_by, etc.) are only present on the parent table. The child table uses these fields from the parent.
• sys_class_name Field: A field called sys_class_name is automatically created on the parent table. This field stores the name of the actual table where the record was created. For example, if you create an Incident, the ‘task’ record will have its sys_class_name set to ‘incident’. This allows the system to correctly identify the specific type of record even when querying the parent table.
• Single sys_class_name: Even if a table extends many other tables (a deep hierarchy), it will only have one sys_class_name field on its topmost parent, which accurately reflects the current table type.

Interview Relevance: This demonstrates your understanding of table hierarchy and how ServiceNow optimizes data storage and retrieval. It’s a foundational concept.

Can You Give Me 10 Field Types? (Q36)

Answer: Absolutely! ServiceNow offers a rich variety of field types:

1. String: For short text (up to 4000 characters typically).
2. String (Multi-line): For longer text inputs.
3. Reference: Links to a record on another table (e.g., ‘caller_id’ to sys_user).
4. List: Allows selection of multiple records from another table (e.g., ‘watch_list’).
5. Choice: A dropdown list of predefined options.
6. Date: Stores a date without a time component.
7. Date/Time: Stores both date and time.
8. Boolean: A true/false (checkbox) field.
9. Integer: Whole numbers.
10. Decimal: Numbers with decimal places.
11. Email: Formats input as an email address.
12. Journal: Appends new text entries without overwriting previous ones (e.g., ‘Activity Comments’).
13. Journal Input: The field where users type new journal entries.
14. Attachment: Stores files.
15. HTML: For rich text formatting.
16. URL: Stores web addresses.
17. Duration: Stores time spans (e.g., 00:00:00).

What is the Difference Between Temporary and Normal Tables? (Q37)

Answer:

• Normal Tables: These store data permanently. Records remain in the database indefinitely until explicitly deleted (via script, UI, or data retention policies). Most operational data (Incidents, Users, CIs) resides in normal tables. They do not extend import_set_row.
• Temporary Tables: Also known as “Staging Tables” or “Import Set Row” tables. These tables are designed for transient data, often used during data imports. By default, data in temporary tables is retained for 7 days and then automatically purged. They always extend the import_set_row table, which provides the inherent temporary behavior.

Why it matters: Understanding this helps in choosing the correct table type for data imports or temporary data storage, preventing unnecessary database bloat.

Can We Increase the Retention Period in a Temp Table? (Q38)

Answer: Yes, you can increase the retention period for temporary tables. You would typically do this by creating or modifying Table Cleanup (previously called “Archive Rules”) records for that specific table. You can extend the retention beyond the default 7 days to suit specific compliance or debugging needs, though it’s generally recommended to keep temporary data temporary.

What is the Difference Between Remote Table and Normal Tables? (Q39)

Answer:

• Normal Tables (Local Tables): These tables store data directly within the ServiceNow instance’s database. When you query a normal table, you are accessing data that resides physically within your instance.
• Remote Tables: Introduced with IntegrationHub spokes, Remote Tables allow you to access and display live data from external systems (e.g., Jira, SAP, Salesforce) directly within ServiceNow without replicating that data into the local instance database. When you interact with a Remote Table, ServiceNow makes API calls to the external system in real-time to fetch or update the data. The data is never persistently stored in your ServiceNow database.

Interview Relevance: This shows awareness of modern integration capabilities and how ServiceNow handles external data sources without full replication.

What is One-to-One and One-to-Many Table in ServiceNow? (Q40)

Answer: These describe relationships between records across different tables:

• One-to-One Relationship: A single record in one table is associated with exactly one record in another table, and vice-versa. While less common for core data, an example might be a “Computer” CI (cmdb_ci_computer) and a “License Certificate” (a custom table), where each computer has only one certificate and each certificate belongs to only one computer.
• One-to-Many Relationship: A single record in the “one” table can be associated with multiple records in the “many” table, but each record in the “many” table is associated with only one record in the “one” table.
  • Example: Users and Incidents: One user (sys_user) can be the caller_id for many incidents (incident), but each incident typically has only one caller_id.
  • Example: Company and Users: One company (core_company) can have many users, but each user belongs to only one company.
• Many-to-Many Relationship: Multiple records in one table can be associated with multiple records in another table. These are typically implemented using a “junction” or “relationship” table.
  • Example: Incidents and Groups: An incident can be assigned to multiple groups (via a ‘watch_list’ or ‘escalation_path’ for example, though ‘assignment_group’ is one-to-one), and a group can be associated with many incidents. A classic example is a “Affected CIs” related list on an Incident, which is a many-to-many relationship managed by the task_ci table.
  • Example: Users and Groups: One user can be a member of many groups, and one group can have many users. This is handled by the sys_user_grmember junction table.

Interview Relevance: Understanding these relationships is fundamental to database design and critical for writing effective GlideRecord queries that join data across tables.

In How Many Ways Can We Create a Record in ServiceNow? (Q41)

Answer: You have a multitude of options for record creation in ServiceNow:

1. Form (UI): Manually filling out and submitting a form in the platform.
2. Record Producer: A specific type of catalog item that submits data to a table (e.g., “Report an Incident” on the Service Portal).
3. Email: Inbound Email Actions can parse incoming emails and create records (e.g., Incident from email).
4. GlideRecord (Script): Programmatically creating records using server-side JavaScript.
5. Import Set/Transform Maps (Excel/CSV): Importing data from external files, which then maps to target tables.
6. REST/SOAP APIs: External systems can create records via web services.
7. Flow Designer / Workflow: Automated flows or workflows can create records as part of a larger process.
8. ServiceNow Mobile App: Creating records directly from mobile devices.

In How Many Ways Can We Make a Field Mandatory, Read-Only, or Visible? (Q42)

Answer: This is a powerful question that tests your understanding of different client-side and server-side mechanisms for UI control.

1. Dictionary Entry (Server-Side):
   • Mandatory: Set “Mandatory” checkbox to true.
   • Read-Only: Set “Read Only” checkbox to true.
   • Visible: Not directly controlled by dictionary “visible” checkbox, but “Active” false would hide it.
2. Dictionary Overrides (Server-Side): Override the dictionary properties for a specific child table.
3. UI Policies (Client-Side):
   • Make fields mandatory, read-only, or hidden/visible based on conditions.
   • Work on the form, after page load, and can be conditional.
4. Data Policies (Client & Server-Side):
   • Enforce data integrity across all data entry points (UI, imports, web services).
   • Can make fields mandatory or read-only. They are more robust than UI Policies for data integrity because they apply server-side.
5. Client Scripts (Client-Side):
   • Using g_form.setMandatory('field_name', true/false).
   • Using g_form.setReadOnly('field_name', true/false).
   • Using g_form.setVisible('field_name', true/false).
   • Offer the most dynamic and complex control.
6. ACLs (Access Control Lists – Server-Side): Control whether a user can read/write a field. While not directly making it “mandatory” or “read-only” on the form, a write ACL preventing write access effectively makes it read-only for that user.

Interview Tip: When answering this, emphasize the order of precedence (ACLs > Data Policies > UI Policies > Client Scripts) and the difference between client-side (UI Policies, Client Scripts) and server-side (Dictionary, Data Policies, ACLs) enforcement.

Can We Make 2 Fields as Display in One Table? (Q43)

Answer: No, you should never make two fields as “Display” on a single table. Only one field should be marked as “Display” in a table’s dictionary entry.

Explanation: The “Display” field is used by ServiceNow for several critical functions:

• Reference Fields: When a field references this table, the display value of the referenced record will be taken from the field marked “Display.”
• Breadcrumbs: The display value is often used in breadcrumbs for navigation.
• Reports: Sometimes used as the default display value in lists and reports.

Having two display fields would lead to confusion about which one the system should use, resulting in unpredictable behavior, inconsistent data presentation, and potential errors. It’s a fundamental data model principle.

All Tables Will Be Stored Where? (Q44)

Answer: The metadata for all tables defined in your ServiceNow instance is stored in the sys_db_object table. This table contains information about each table, such as its name, label, whether it’s extensible, its parent, and other properties.

How to Set a Default Value on a Field? (Q45)

Answer: You can set a default value for a field directly within its Dictionary Entry. When you open the form for a new record, this default value will automatically populate the field. This is useful for pre-filling common values, ensuring consistency, or guiding users.

Server-Side Scripting Deep Dive: The current Object

The current object is arguably the most important object in server-side scripting, especially within Business Rules and Script Includes. Interviewers love to probe your understanding here.

What is the current Object? (Q46)

Answer: The current object is a special server-side JavaScript object that represents the current record being processed by a Business Rule, Script Include, or other server-side script context. It’s a GlideRecord object itself, providing direct access to the fields and methods of that record.

Explanation:

• In a Business Rule, current refers to the record that is being inserted, updated, or deleted.
• You use current to read the values of fields on the record (e.g., current.state), and to set new values (e.g., current.comments = '...') before the record is saved to the database.
• It’s only available in server-side scripts that operate on a specific record context.

Interview Relevance: This is a core concept. If you can’t explain current, you’ll struggle with most server-side scripting questions.

How to Set the Field Values on the Current Form (using current)? (Q47)

Answer: You can set field values on the current object in a few ways:

• Direct Assignment: The most common way for most field types.

  
  current.field_name = 'new_value';
  current.short_description = 'Updated description';
                  

• setValue(): Recommended for reference fields, or when you want to be explicit. It’s especially useful for ensuring you set the underlying sys_id for reference fields, not just a display value.

  
  // For a reference field, 'caller_id'
  current.setValue('caller_id', 'sys_id_of_user'); // Always pass the sys_id for reference fields
                  

• setDisplayValue(): This method allows you to set a reference field by its display value (e.g., a user’s name) 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 share the same display value. Use with caution.

  
  // For a reference field, 'caller_id'
  current.setDisplayValue('caller_id', 'John Doe'); // ServiceNow will find John Doe's sys_id
                  

Key Difference (setValue vs. setDisplayValue for Reference Fields):

• setValue(): Takes the sys_id of the referenced record. This is highly reliable and efficient.
• setDisplayValue(): Takes the display value (e.g., name, number) of the referenced record. ServiceNow then performs a lookup to find the corresponding sys_id. This can be useful if you only have the display value, but it’s less direct.

For most server-side scripting where you can reliably get the sys_id, setValue() or direct assignment with sys_id is preferred for reference fields.

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. (Q48)

Answer: Reference Qualifiers are powerful tools used to restrict the data shown in a reference field (or a List field). They define a filter that determines which records from the referenced table are available for selection. This significantly improves user experience and data accuracy.

There are three main types:

1. Simple Reference Qualifier

• Description: This is the most straightforward type. You define a fixed query string that acts as a filter. It doesn’t change based on other fields on the form.
• Example: You have a “Manager” reference field (referencing sys_user), and you only want to show users who have the “itil” role and are active.

  
  // In the Reference Qualifier field:
  active=true^roles=itil
                  

• How to Use: In the dictionary entry of the reference field, select “Simple” for the Reference Qualifier field, and enter your encoded query string.
• Strengths: Easy to configure, good for static filtering.
• Weaknesses: Not dynamic; cannot adapt to user input or other field values.

2. Dynamic Reference Qualifier

• Description: This type leverages a pre-defined “Dynamic Filter Option.” These options encapsulate more complex, reusable logic that might involve conditions based on the current user, group, or other contextual data. They provide a balance between simplicity and dynamism.
• Example: Displaying only incidents assigned to the current user’s assignment group. You might have a Dynamic Filter Option called “Assigned to my Group.”
• How to Use:
  1. First, create a Dynamic Filter Option (System Definition > Dynamic Filter Options). Define its conditions and make it “Available for reference qualifiers.”
  2. Then, in the reference field’s dictionary entry, select “Dynamic” for the Reference Qualifier and choose your created Dynamic Filter Option.
• Strengths: Reusable, abstracts complex logic, can incorporate server-side script logic within the Dynamic Filter Option.
• Weaknesses: Less flexible for highly specific, one-off dynamic requirements compared to Advanced; requires pre-configuration.

3. Advanced Reference Qualifier (JavaScript Reference Qualifier)

• Description: This is the most powerful and flexible type. You write custom JavaScript code that returns an encoded query string. This allows for highly dynamic filtering based on virtually any condition, including values from other fields on the current form, properties of the current user, or even data fetched from other tables.
• Example: Filtering the “Assigned To” field to show only users who are members of the “Assignment Group” selected on the form AND who are active.

  
  // In the Reference Qualifier field:
  javascript: 'active=true^roles=itil^EQ^GOTOroles.user_name^GROUPFROMcurrent.assignment_group';
  
  // A more robust example using a Script Include (best practice for complex logic):
  javascript: new MyReferenceQualifierUtils().filterUsersByGroup(current.assignment_group);
                  

  A simpler, direct example:

  
  javascript: "assignment_group=" + current.assignment_group + "^active=true";
                  

• How to Use: In the reference field’s dictionary entry, select “Advanced” for the Reference Qualifier and enter your JavaScript code. The script must return an encoded query string.
• Strengths: Maximum flexibility and dynamism, can incorporate complex logic and external data.
• Weaknesses: Requires JavaScript knowledge, potential for performance issues if not written efficiently, harder to debug if complex. Best practice is to use a Script Include that returns the query string.

Differences Explained:

• Simple vs. Dynamic: Simple is static, a hardcoded query. Dynamic uses a pre-configured, reusable filter that can itself be based on context, but the configuration of *that filter* is separate.
• Dynamic vs. Advanced: Dynamic is about choosing a pre-packaged filter. Advanced is about writing a brand new, custom script-based filter every time. Dynamic is more “configuration over code” for complex but common patterns. Advanced is “code” for unique, intricate needs.
• Simple vs. Advanced: Simple is fixed. Advanced is fully programmable, allowing the filter to change based on conditions, other field values, and user context.

Interview Relevance: This is a high-value question. A thorough explanation demonstrates deep platform knowledge, best practices (using Script Includes for Advanced), and problem-solving skills.

What is a Dependent Value? (Q49)

Answer: Dependent values in ServiceNow are used to create cascaded dropdown menus (choice lists) or other filtered selections where the available options in one field (the dependent field) change based on the selection made in another field (the parent field).

Steps to Configure Dependent Values:

1. Identify Parent and Dependent Fields: For example, “Category” as the parent and “Subcategory” as the dependent.
2. Configure the Parent Field: Ensure the parent field is a Choice list and has its options defined.
3. Configure the Dependent Field’s Dictionary Entry:
   • Go to the dependent field’s dictionary entry.
   • Set the “Dependent field” attribute to the parent field.
4. Define Choices for the Dependent Field:
   • For each choice in the dependent field, you’ll specify its “Dependent value.” This links it to a specific choice in the parent field.
   • Example: If “Category” is ‘Hardware’, you’d define “Subcategory” choices like ‘Laptop’, ‘Desktop’, ‘Printer’ and set their “Dependent value” to ‘Hardware’.

Example: If Category = “Hardware”, Subcategory options might be “Laptop”, “Desktop”. If Category = “Software”, Subcategory options might be “Operating System”, “Application”. This streamlines form entry and reduces errors.

What is a Calculated Value? (Q50)

Answer: A calculated value field is a field whose value is automatically determined by a server-side script, typically based on the values of other fields on the current record. You define this script within the field’s dictionary entry.

Configuration:

1. In the field’s dictionary entry, check the “Calculated” checkbox.
2. A “Calculation” script field will appear.
3. Write a server-side script that assigns a value to the current.field_name, or simply returns the calculated value.

Example: An “Age (days)” field on an Incident that calculates the difference between “Created” and “Resolved” dates. The script would use current.created_on and current.resolved_at to compute the difference. The calculation runs whenever the record is loaded or updated.

What Are Attributes? Name Some of the Attributes That You Used. (Q51)

Answer: Attributes are powerful, comma-separated key-value pairs that you can add to a field’s dictionary entry (or a table’s collection record) to modify its behavior, appearance, or functionality beyond standard dictionary settings. They provide fine-grained control over how fields operate and interact with the UI.

Examples of Attributes:

• no_email=true: Prevents the field’s content from being included in email notifications.
• no_attachment=true: Disables the ability to attach files to this specific field (not the entire record).
• no_m2m=true: Prevents a field from being added to a many-to-many relationship.
• tree_picker=true: Displays a reference field as a hierarchical tree picker (common for CI fields).
• ref_contributions=my_custom_macro: Adds a custom UI macro to the right of a reference field.
• read_only=true: Makes a field read-only (similar to the checkbox, but can be set conditionally via scripts).
• max_length=100: Overrides the default string length (though often set directly on the field type).
• glide_list=true: Turns a string field into a comma-separated list of references (if used with a reference field type).

Interview Relevance: Knowing common attributes demonstrates a deeper understanding of platform customization and how to achieve specific UI behaviors without extensive scripting.

What is the Collection Field on a Table? (Q52)

Answer: The “Collection” field is a special dictionary entry that represents the table itself, rather than an individual field within the table. Every table has a dictionary entry of type “Collection.”

Purpose: It allows you to apply attributes or properties that affect the entire table or all its forms/lists. Changes made to the Collection dictionary entry apply globally to that table (and its children, depending on the attribute), rather than to a specific field.

How to Enable/Disable Attachment on the Form Using Attributes? (Q53)

Answer: To control attachments for an entire form/table, you would use the no_attachment attribute on the Collection dictionary entry for that table.

// On the Collection dictionary entry for your table (e.g., 'incident'):
// Add 'no_attachment=true' in the Attributes field to disable attachments for the entire incident form.
// Remove it or set to 'false' to enable attachments.
        

This affects the entire record, preventing any attachments from being added or viewed on forms for that table. Note that a specific field’s no_attachment attribute would only affect files attached to that particular field, which is less common.

What Are Dictionary Overrides? What Are All the Properties We Can Override in Dictionary Overrides? (Q54)

Answer: Dictionary overrides allow you to modify the behavior or properties of an inherited field (a field from a parent table) specifically for a child table, without affecting the parent table or other child tables. This is incredibly useful for tailoring field behavior within specific contexts.

Example: The ‘Priority’ field is inherited from the task table. By default, its value might be ‘4 – Low’. However, for an ‘Incident’ (which extends ‘task’), you might want the default priority to be ‘5 – Planning’ or ‘3 – Moderate’. A dictionary override on the ‘Incident’ table for the ‘Priority’ field can achieve this.

Properties You Can Override: You can override a significant number of properties, including:

• Default Value: Change the initial value displayed.
• Mandatory: Make the field mandatory (or not) for the child table.
• Read Only: Make the field read-only (or not) for the child table.
• Active: Activate or deactivate the field for the child table.
• Choice List Specification: Limit choice options for the child table.
• Reference Qualifiers: Apply a different filter to a reference field.
• Attributes: Add or change specific attributes (e.g., no_email, tree_picker).
• Column Label: Change the display label of the field.
• Max Length: Adjust the maximum character length for string fields.

Interview Relevance: This is a powerful feature for platform customization. Explaining dictionary overrides demonstrates your ability to manage inheritance and tailor functionality without extensive scripting or modifying core definitions.

What Are Data Lookup Rules? (Q57)

Answer: Data Lookup Rules (or “Data Lookups”) provide a low-code/no-code way to automatically set field values on a form based on conditions met by other field values. They work by looking up a match in a defined “lookup table” and then copying values from that lookup record to the current record.

Example: In an Incident form, if you select a ‘Category’ and ‘Subcategory’, a Data Lookup Rule could automatically populate the ‘Impact’, ‘Urgency’, and ‘Assignment Group’ based on predefined combinations in the lookup table. This streamlines data entry and enforces consistency.

How they work:

1. You define a “Matcher” field (or fields) on the lookup table and the target table.
2. You define “Setter” fields on the lookup table and the target table.
3. When the “Matcher” fields on the target form match a record in the lookup table, the values from the “Setter” fields of the lookup record are copied to the target form.

They are efficient for managing many-to-many relationships or complex conditional field population without writing scripts.

Client-Side Control: UI Policies and Data Policies

While GlideRecord is server-side, interviewers often segue into related concepts of UI control. UI Policies and Data Policies are frequently confused, so clearly articulating their differences and features is key.

What Are UI Policies? (Q58)

Answer: UI Policies are client-side logic that allow you to dynamically change the behavior of fields on a form based on certain conditions. They execute after the form loads and whenever a field referenced in the conditions changes.

Key functionalities:

• Making fields mandatory.
• Making fields read-only.
• Making fields visible/hidden.
• Controlling the visibility of related lists.

They operate solely on the user interface (the browser) and do not enforce data integrity at the database level.

What is the Global Checkbox in UI Policies? (Q59)

Answer: The “Global” checkbox in a UI Policy determines its scope regarding views.

• Checked (Global = true): The UI Policy will apply to all views of the form (e.g., Default view, Self-Service view, Mobile view).
• Unchecked (Global = false): The UI Policy will only apply to the specific view you select in the “View” field that appears. This allows you to tailor UI behavior for different user experiences or specific purposes.

What is “Reverse if False” in UI Policies? (Q60)

Answer: The “Reverse if false” checkbox is a powerful feature in UI Policies.

• Checked: If the UI Policy’s conditions are met (true), the specified actions (make mandatory, read-only, visible) are applied. If the conditions later become false, those actions are automatically reversed. For example, if a field was made mandatory when true, it becomes optional again when false.
• Unchecked: If the conditions are met, the actions are applied. However, if the conditions later become false, the actions remain in effect. You would need a separate UI Policy (or client script) to reverse them.

It’s generally recommended to check “Reverse if false” for most dynamic UI changes to ensure consistent and intuitive user experiences.

What is the “On Load” Checkbox in UI Policy? (Q61)

Answer: The “On Load” checkbox determines when the UI Policy’s conditions and actions are first evaluated.

• Checked: The UI Policy is evaluated and its actions are applied immediately when the form initially loads in the browser. This is essential for setting initial states (e.g., hiding a field until a condition is met).
• Unchecked: The UI Policy’s conditions are *not* evaluated when the form first loads. Actions will only be triggered later if a field involved in the UI Policy’s conditions changes. This is less common but can be useful if you only want changes after user interaction.

What is the Inherit Checkbox in UI Policy? (Q62)

Answer: The “Inherit” checkbox applies when a UI Policy is defined on a parent table.

• Checked: The UI Policy (and its conditions/actions) will also be applied to all child tables that extend the parent table. This is efficient for enforcing consistent UI behavior across a family of tables (e.g., all task types).
• Unchecked: The UI Policy will only apply to the specific table on which it is defined. Child tables will not inherit its behavior.

Can You Write a Script in a UI Policy? (Q63)

Answer: Yes, you can write client-side scripts within a UI Policy. To do this, you must check the “Run scripts” checkbox in the UI Policy form. Once checked, two script fields appear: “Execute if true” and “Execute if false.”

Explanation:

• “Execute if true”: The script in this field runs if the UI Policy conditions evaluate to true.
• “Execute if false”: The script in this field runs if the UI Policy conditions evaluate to false (and “Reverse if false” is checked).

These scripts are client-side (JavaScript) and can interact with the g_form object to perform more complex UI manipulations than the standard UI Policy actions allow (e.g., setting a field’s value, showing messages, controlling form sections). However, for very complex logic, a Client Script might be more appropriate.

Can We Convert a UI Policy as a Data Policy? (Q64)

Answer: Yes, ServiceNow provides a convenient way to convert an existing UI Policy into a Data Policy. On the UI Policy form, there’s a UI action (a button or link) that says “Convert this to Data Policy.” Clicking this will create a new Data Policy with the same conditions and field actions (mandatory, read-only).

Which Are All the Cases Where a UI Policy Cannot Be Converted as a Data Policy? (Q65)

Answer: While many UI Policies can be converted, there are specific scenarios where a direct conversion to a Data Policy is not possible or meaningful, because Data Policies are focused purely on data integrity, not UI presentation:

• Controlling Data Visibility (Hidden Fields): Data Policies cannot make fields hidden or visible. They only enforce mandatory or read-only states. UI Policies are for hiding/showing fields.
• Controlling Views: Data Policies do not have a concept of “views.” They apply globally across all data entry points. UI Policies can be view-specific (using the Global checkbox).
• Controlling Related Lists: Data Policies cannot hide or show related lists. This is a UI-specific action handled by UI Policies.
• Running Scripts: Data Policies do not have script fields (“Execute if true/false”). If your UI Policy contains client-side scripts, those scripts will not be transferred to the Data Policy. Data Policies do not execute scripts.
• “Reverse if false”: Data Policies have a “Reverse if false” equivalent (which is typically implied), but the concept of reversing a UI-specific action like hiding a field doesn’t translate.

In essence, if a UI Policy is doing anything purely related to the visual presentation of the form, rather than data integrity (mandatory/read-only), it cannot be fully converted into a Data Policy.

What Are Data Policies? (Q66)

Answer: Data Policies are server-side rules that enforce data consistency and integrity across all data input methods in ServiceNow. Unlike UI Policies, which only affect the form UI, Data Policies apply regardless of how data enters the system (form, import sets, web services, scripts, etc.).

Key functionalities:

• Making fields mandatory.
• Making fields read-only.

They operate at both the client-side (to provide immediate feedback on forms) and, more importantly, at the server-side, ensuring that data stored in the database adheres to defined rules. If a Data Policy condition is violated, the record cannot be saved.

Interview Relevance: This is a crucial distinction. Data Policies are about data integrity; UI Policies are about user experience. Understanding this difference is fundamental to building robust applications in ServiceNow.

Conclusion: Your Path to ServiceNow Interview Success

Phew! If you’ve made it this far, congratulations! You’ve navigated through some of the most challenging and frequently asked questions about GlideRecord and related ServiceNow platform concepts. Mastering these topics isn’t just about regurgitating answers; it’s about understanding the underlying principles, knowing when to apply which tool, and demonstrating a thoughtful approach to development and administration.

GlideRecord truly is the backbone of server-side scripting in ServiceNow. Your ability to wield it effectively, coupled with a solid grasp of data models, UI controls, and best practices, will make you an invaluable asset to any ServiceNow team. Practice these concepts, try out the scripts in your personal developer instance, and most importantly, be ready to explain the “why” behind your technical choices.

Good luck with your interviews. You’ve got this!