Mastering ServiceNow GlideRecord: Your Top 10 Interview Questions Decoded

Navigating the world of ServiceNow development can feel like learning a new language. And if ServiceNow is a language, then GlideRecord is its grammar – the fundamental structure that allows you to communicate with the platform’s database. Whether you’re a seasoned developer or just starting your journey, a strong grasp of GlideRecord is non-negotiable. It’s the cornerstone of server-side scripting, enabling you to create, retrieve, update, and delete records dynamically.

When you walk into a ServiceNow interview, expect GlideRecord to be a central topic. Interviewers aren’t just looking for syntax memorization; they want to see if you understand the ‘why’ behind the ‘how,’ the best practices, and how to apply this powerful API to solve real-world problems. They want to know you can not only write code but write efficient and maintainable code.

So, let’s dive deep into the top 10 ServiceNow GlideRecord interview questions. We’ll break down the answers, explore the nuances, provide practical examples, and arm you with the confidence to ace your next interview.

1. What is GlideRecord, and why is it fundamental to ServiceNow scripting?

This might seem like a basic question, but it’s often the first one an interviewer will ask to gauge your foundational understanding. Don’t just rattle off a definition; explain its significance.

The Core Concept:

At its heart, GlideRecord is a JavaScript object that allows you to interact with the ServiceNow database from server-side scripts. Think of it as your direct portal to tables and records. It encapsulates SQL-like operations in an object-oriented, ServiceNow-specific API. Every piece of data you see in ServiceNow—an incident, a user, a configuration item—is stored as a record in a table, and GlideRecord is the primary mechanism to programmatically access and manipulate these records.

Why it’s Fundamental:

Database Interaction: It’s the standard way to query, insert, update, and delete records without writing raw SQL.
Server-Side Scripting: Essential for Business Rules, Script Includes, Workflow Activities, Scheduled Jobs, UI Actions (server-side), and more.
Automation: Enables complex automations, integrations, and data synchronizations that go beyond declarative configurations.
Platform Consistency: Provides a consistent, secure, and performant way to interact with the database across various ServiceNow applications.

Interview Relevance:

This question assesses your grasp of core ServiceNow architecture. A good answer demonstrates that you understand how data flows and how to programmatically control it, which is the bedrock of any developer role.

2. How do you programmatically manage Users and Groups in ServiceNow?

User and group management is a common administrative task that often requires scripting for automation or bulk operations. Interviewers want to see if you know the relevant tables and the basic GlideRecord operations for creating these records.

User Table Name & Creation:

The user table is named sys_user. Creating a new user record using GlideRecord is straightforward:

var userGr = new GlideRecord('sys_user');
userGr.initialize(); // Prepares a new, empty record
userGr.user_name = 'jdoe'; // Unique login ID
userGr.first_name = 'John';
userGr.last_name = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.active = true; // Set active to true for a new user
userGr.insert(); // Commits the new record to the database
gs.info('User jdoe created successfully!');

Group Table Name & Creation:

The group table is named sys_user_group. Similar to users, creating a group is simple:

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'IT Support Team'; // Display name of the group
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Sys_id of the manager user
newGr.email = 'itsupport@example.com';
newGr.description = 'Team responsible for IT incidents.';
newGr.insert();
gs.info('Group "IT Support Team" created successfully!');

Interview Relevance:

This showcases your practical scripting skills for common administrative tasks. Knowing the exact table names (sys_user, sys_user_group) and the `initialize()` / `insert()` pattern is key. It also subtly hints at understanding the structure of core tables.

3. How do you script Role Assignment and Group Membership, and what are the best practices for permissions?

This question delves into the relationships between users, groups, and roles, which is critical for access control in ServiceNow. It also touches upon a crucial best practice.

The Best Practice: Assign Roles to Groups, not Users!

This is a fundamental principle in ServiceNow and IT administration in general. When assigning permissions (roles), it’s best practice to add roles to groups. Then, add users to those groups. Why?

Simplified Management: If an employee’s role changes or they leave, you simply add/remove them from a group, and their permissions adjust automatically. No need to manage roles individually for each user.
Consistency: Ensures all members of a specific team have the exact same set of permissions.
Auditing: Easier to audit who has what permissions by looking at group memberships.

Scripting Role Assignment:

Roles are assigned via association tables.

To a User: A record in sys_user_has_role is created.
To a Group: A record in sys_group_has_role is created.

Adding a Role to a User (Use with caution, prefer groups!):

// Assuming 'userSysId' is the sys_id of the user and 'roleSysId' is the sys_id of the role
var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
userRole.setValue('user', '62826bf03710200044e0bfc8bcbe5df1'); // Sys_id of the user
userRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Sys_id of the role (e.g., 'itil')
userRole.insert();
gs.info('Role assigned to user.');

Adding a Role to a Group (Recommended Approach):

// Assuming 'groupSysId' is the sys_id of the group and 'roleSysId' is the sys_id of the role
var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
grpRole.setValue('group', '477a05d153013010b846ddeeff7b1225'); // Sys_id of the group
grpRole.setValue('role', '2831a114c611228501d4ea6c309d626d'); // Sys_id of the role (e.g., 'itil')
grpRole.insert();
gs.info('Role assigned to group.');

Scripting Group Membership:

Users are added to groups by creating records in the sys_user_grmember table.

Adding a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
grMem.user = '62826bf03710200044e0bfc8bcbe5df1'; // Sys_id of the user
grMem.group = '477a05d153013010b846ddeeff7b1225'; // Sys_id of the group
grMem.insert();
gs.info('User added to group.');

Removing a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', '62826bf03710200044e0bfc8bcbe5df1'); // Query for the specific user
grMem.addQuery('group', '477a05d153013010b846ddeeff7b1225'); // Query for the specific group
grMem.query(); // Execute the query

if (grMem.next()) { // If a record is found
    grMem.deleteRecord(); // Delete that record
    gs.info('User removed from group.');
} else {
    gs.info('User not found in group.');
}

Interview Relevance:

This question tests your understanding of relational data and best practices in ServiceNow security and administration. Knowing the intermediary tables (sys_user_has_role, sys_group_has_role, sys_user_grmember) and how to manipulate them is a sign of a well-rounded developer. Emphasize the “assign roles to groups” best practice!

4. How do you create core ITIL records (Incident, Problem, Change) using GlideRecord?

Creating core ITIL records is a frequent requirement, especially when integrating with other systems or automating processes. This question checks if you know the table names and the general pattern for record creation.

Common Pattern:

The pattern for creating Incident, Problem, and Change records is quite similar: `new GlideRecord()`, `initialize()`, set fields, `insert()`. The main difference lies in the table name and specific fields relevant to each record type.

Creating an Incident Record:

var gr = new GlideRecord('incident');
gr.initialize();
gr.caller_id = '86826bf03710200044e0bfc8bcbe5d94'; // Sys_id of the caller
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 script for testing purposes.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018'; // Sys_id of the Assignment Group
gr.insert();
gs.info('Incident ' + gr.number + ' created successfully!');

Creating a Problem Record:

var gr = new GlideRecord('problem');
gr.initialize();
gr.opened_by = '86826bf03710200044e0bfc8bcbe5d94'; // Sys_id of the user opening the problem
gr.category = 'software';
gr.subcategory = 'application_error';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Test problem created via script';
gr.description = 'Investigating recurring application errors in critical system.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();
gs.info('Problem ' + gr.number + ' created successfully!');

Creating a Change Request:

var gr = new GlideRecord('change_request');
gr.initialize();
gr.type = 'normal'; // Standard, Normal, Emergency
gr.category = 'hardware';
gr.subcategory = 'network';
gr.cmdb_ci = 'affd3c8437201000deeabfc8bcbe5dc3';
gr.short_description = 'Test change request created via script';
gr.description = 'Upgrade network switch in server room ABC.';
gr.assignment_group = 'a715cd759f2002002920bde8132e7018';
gr.insert();
gs.info('Change Request ' + gr.number + ' created successfully!');

Troubleshooting Tip:

If your script fails to create a record or fields are not populated, check:

ACLs: Does the user running the script have permission to create records on that table and write to those fields?
Mandatory Fields: Are all mandatory fields (as defined in the dictionary) being populated?
Field Names: Are your field names spelled correctly? (e.g., caller_id not callerId)
sys_id for Reference Fields: For reference fields like caller_id, cmdb_ci, and assignment_group, you must provide the sys_id of the referenced record, not its display name.

Interview Relevance:

This demonstrates your ability to interact with the bread-and-butter of ServiceNow operations. It confirms you know the core table names and how to use GlideRecord for fundamental data entry, which is critical for integrations and automations.

5. How would you implement logic for parent-child record closure (e.g., closing child incidents when a parent closes)?

This is a classic scenario that tests your understanding of Business Rules, GlideRecord queries, and updating multiple records. It’s about propagating changes through related records.

The Scenario: Closing Child Incidents

Requirement: When a parent incident is closed, all its associated child incidents should also automatically close.

Solution: Implement an “After” Business Rule on the incident table.

When: After
Update: Checked (true)
Condition: current.state.changesTo(7) && current.parent == '' (Assuming 7 is the ‘Closed’ state value and we’re acting only on actual parent incidents, not child incidents being closed).

if (current.state == 7 && current.parent.nil()) { // current.parent.nil() checks if parent field is empty
    // GlideRecord to find child incidents
    var grChild = new GlideRecord('incident');
    grChild.addQuery('parent', current.sys_id); // Query for children of the current incident
    grChild.query(); // Execute the query

    while (grChild.next()) { // Iterate through each found child incident
        grChild.state = 7; // Set the state to Closed (assuming 7 is 'Closed')
        grChild.update(); // Update the child incident
        gs.info('Child incident ' + grChild.number + ' closed due to parent ' + current.number + ' closure.');
    }
}

The Scenario: Closing Incidents when Associated Problem Closes

Requirement: When a problem record is closed, all associated incident records should also close.

Solution: Implement an “After” Business Rule on the problem table.

When: After
Update: Checked (true)
Condition: current.state.changesTo(7) (Assuming 7 is the ‘Closed’ state value for problems).

if (current.state == 7) { // Assuming 7 is the state value for 'Closed'
    // GlideRecord to find incidents associated with the 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
    grIncident.query();

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

Interview Relevance:

This is an excellent question to evaluate your understanding of Business Rules, the current object, and performing bulk updates using GlideRecord. It shows you can write efficient scripts that handle record relationships and state transitions, which is a common requirement in ITSM workflows.

6. How do you prevent an action (e.g., closing an Incident) if related records are in an open state?

Ensuring data integrity and proper workflow progression is crucial. This question tests your ability to implement validation logic using GlideRecord and to stop an action when conditions aren’t met.

The Scenario: Preventing Incident Closure

Requirement: An incident cannot be closed if any of its associated incident tasks are still open. This logic should also apply to Problem and Change Request records if they have open tasks.

Solution: Implement a “Before” Business Rule on the incident table (and similar ones for problem and change_request).

When: Before
Update: Checked (true)
Condition: current.state.changesTo(7) (or whatever the ‘Closed’ state value is).

if (current.state.changesTo(7)) { // If the incident is being changed to a closed state
    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 tasks are found
        gs.addErrorMessage('Cannot close Incident ' + current.number + ' because there are open tasks. Please close all tasks first.');
        current.setAbortAction(true); // Prevents the incident from being saved/closed
    }
}

Key elements:

current.state.changesTo(value): Checks if a field’s value is changing *to* a specific value.
grTask.hasNext(): Checks if the query returned at least one record. This is more efficient than `grTask.next()` if you only need to know if *any* record exists.
gs.addErrorMessage(): Displays a message to the user on the form.
current.setAbortAction(true): This is the critical line. It stops the current database transaction (the update/insert/delete operation) and prevents the record from being saved.

Interview Relevance:

This question demonstrates your understanding of “Before” Business Rules, defensive scripting, and ensuring data integrity. It shows you can implement robust validation logic, which is vital for building reliable applications on ServiceNow.

7. Explain the differences between the `current` object and a new GlideRecord instance, and how to set field values.

This is a fundamental distinction that trips up many new developers. The current object is a special GlideRecord-like object available within certain server-side scripts.

The `current` Object:

Contextual: The current object is implicitly available in Business Rules, Script Includes (when called from a Business Rule, Workflow, etc.), and other execution contexts. It represents the record that triggered the script or is currently being processed.
No Instantiation: You don’t create it with new GlideRecord(). It’s given to you by the platform.
Immediate Context: Primarily used for reading and manipulating the record currently in scope.
Example: In a Business Rule on the Incident table, current.state refers to the state of the incident being processed.

A New GlideRecord Instance:

Explicit: You explicitly create it using var gr = new GlideRecord('table_name');.
Independent: It’s an independent object used to interact with any record on any table, typically *other* than the one currently triggering the script (though it can query the same table).
Example: If you need to find all child incidents related to the current incident, you’d create a new GlideRecord for the incident table and query for child records.

Setting Field Values: `current.field_name = value` vs. `current.setValue('field_name', value)` vs. `current.setDisplayValue('field_name', value)`

current.field_name = value; (Direct Assignment):
- Purpose: The most common and direct way to set field values.
- Reference Fields: For reference fields (e.g., caller_id), you *must* provide the sys_id of the referenced record.
- Example: current.caller_id = 'sys_id_of_user';
current.setValue('field_name', value);
- Purpose: A more formal method. Useful when the field name itself is dynamic or for consistency.
- Reference Fields: Similar to direct assignment, requires the sys_id for reference fields.
- Example: current.setValue('caller_id', 'sys_id_of_user');
current.setDisplayValue('field_name', value);
- Purpose: Specifically for reference fields, it allows you to set the value using the *display value* (e.g., user’s name) instead of the sys_id. ServiceNow will then automatically resolve the corresponding sys_id.
- Caveat: If multiple records have the same display value, it might pick the wrong one. Less performant than `setValue` with `sys_id`.
- Example: current.setDisplayValue('caller_id', 'John Doe');

Interview Relevance:

Understanding the current object versus a new GlideRecord instance is fundamental to writing correct and efficient server-side scripts. The distinctions between setting field values show your attention to detail and awareness of performance implications, especially with reference fields. It indicates maturity in your ServiceNow development knowledge.

8. What are Reference Qualifiers, what types exist, and how do they differ?

Reference Qualifiers are powerful tools to control which records are displayed in reference and list type fields. This question is extremely common and tests your UI/UX customization skills.

What are Reference Qualifiers?

Reference Qualifiers restrict the data available for selection in reference fields (e.g., ‘Caller’ on an Incident form) and List Collector variables. They ensure users only see relevant options, improving data accuracy and user experience.

Types of Reference Qualifiers:

There are three main types, increasing in complexity and flexibility:

a) Simple Reference Qualifier:

Description: The most basic type. You define a fixed query string, similar to what you’d put in a filter condition (e.g., `active=true`).
Use Case: When the filtering criteria are static and don’t change based on other fields on the form.
How to Use: Navigate to the dictionary entry of the reference field. In the “Reference Qualifier” field, select “Simple” and add your conditions.
Example: Display only active users in the “Caller” field.
active=true
Difference from others: It’s static and uses an AND condition implicitly for multiple fields.

b) Dynamic Reference Qualifier:

Description: Uses a pre-defined “Dynamic Filter Option” script that generates a query dynamically. These options are reusable across multiple reference fields.
Use Case: When the filtering needs to adapt based on system context (e.g., current user’s department, or values from unrelated fields on the form) but you want to encapsulate the logic for reuse.
How to Use:
1. Go to System Definition > Dynamic Filter Options and create a new one, defining the conditions.
2. In the reference field dictionary entry, select “Dynamic” for the “Reference Qualifier” type and choose your created Dynamic Filter Option.
Example: Display only incidents assigned to the same assignment group as the current user. (You’d define a dynamic filter option that looks up gs.getUser().getRecord().getValue('default_group') and uses it in a query).
Difference from Simple: Dynamic filters are reusable and encapsulate more complex, context-aware logic than a simple static query.
Difference from Advanced: Dynamic filters are defined separately and selected, while Advanced qualifiers are written directly in the dictionary entry and are unique to that field. They are often more user-friendly to manage for non-developers once set up.

c) Advanced Reference Qualifier (JavaScript Reference Qualifier):

Description: This is the most flexible type, allowing you to write custom JavaScript code to construct the query string. The script must return a valid encoded query string.
Use Case: For highly complex filtering logic that depends on multiple fields on the current form, requires advanced database lookups, or conditional logic that simple/dynamic qualifiers can’t handle.
How to Use: In the reference field dictionary entry, select “Advanced” for the “Reference Qualifier” type and enter your JavaScript code, always prefixed with javascript:.
Example: Filter Configuration Items (CIs) to show only those related to the current Incident’s caller’s department AND that are ‘operational’.
```
javascript: 'assigned_to=' + current.assigned_to + '^state=1^ORstate=2'; // A simple example, typically more complex.
javascript: 'location=' + current.location + '^ORassignment_group=' + current.assignment_group + '^EQ'; // More complex example
```
A common mistake is forgetting the javascript: prefix or not returning a valid encoded query string.
Difference from Simple & Dynamic: Offers maximum control and flexibility as you write direct JavaScript, allowing for conditional logic, fetching values from related records, and constructing highly specific queries on the fly. It’s unique to the field where it’s defined and not reusable as a separate entity like a Dynamic Filter Option.

Interview Relevance:

This is a critical question. Interviewers want to see that you understand how to control data visibility and enhance user experience. Being able to explain all three types, their use cases, and their differences demonstrates a deep understanding of UI customization and performance considerations. Knowing when to use each type is a mark of an experienced developer.

9. What are other crucial GlideRecord methods you frequently use, and what are their purposes?

While `initialize()` and `insert()` are common, GlideRecord has a rich API. Interviewers will expect you to know more than just basic creation methods.

Essential GlideRecord Methods:

gr.query();: Executes the query conditions (`addQuery`, `addEncodedQuery`) defined on the GlideRecord object. Without this, no data is retrieved.
gr.next();: Advances the cursor to the next record in the result set. Returns `true` if there’s another record, `false` if not. Used in `while` loops to iterate through results.
gr.get(sys_id);: Retrieves a single record by its sys_id. Returns `true` if found, `false` otherwise. More efficient for single-record lookups than `addQuery` + `query` + `next`.
```
var grUser = new GlideRecord('sys_user');
if (grUser.get('sys_id_of_user')) {
    gs.info('Found user: ' + grUser.name);
}
```
gr.addQuery(fieldName, operator, value);: Adds a simple query condition. The operator can be ‘=’, ‘!=’, ‘LIKE’, ‘STARTSWITH’, etc.
```
gr.addQuery('active', true);
gr.addQuery('state', 'IN', '1,2,3'); // Query for multiple values
```
gr.addEncodedQuery(encodedQueryString);: Adds a complex query using an encoded query string (the string you get from applying a filter in a list view). Very powerful for dynamic or complex queries.
```
gr.addEncodedQuery('active=true^category=hardware^ORpriority=1');
```
gr.orderBy(fieldName); / gr.orderByDesc(fieldName);: Sorts the query results in ascending or descending order.
gr.setLimit(number);: Limits the number of records returned by the query. Essential for performance when you only need a few results.
gr.deleteRecord();: Deletes the current record that the GlideRecord object is pointing to (after a `query()` and `next()` operation).
```
// Example from Q3:
grMem.addQuery('user', userSysId);
grMem.query();
if (grMem.next()) {
    grMem.deleteRecord();
}
```
gr.setWorkflow(false);: Prevents Business Rules and Workflow from running when the record is updated or inserted via this GlideRecord instance. Use with caution but helpful for preventing infinite loops or unwanted side effects during bulk operations.
gr.autoSysFields(false);: Prevents the `sys_created_on`, `sys_created_by`, `sys_updated_on`, `sys_updated_by` fields from being automatically updated. Also useful for integrations.

Interview Relevance:

This shows a comprehensive understanding of the GlideRecord API, not just the basics. Knowing these methods indicates you can write more efficient, targeted, and powerful scripts. Discussing `setWorkflow(false)` or `autoSysFields(false)` demonstrates an awareness of performance and advanced scripting considerations.

10. How do you troubleshoot and debug GlideRecord scripts in ServiceNow?

Writing code is only half the battle; debugging is where real problem-solving shines. Interviewers want to know you can diagnose and fix issues effectively.

Common Debugging Techniques:

gs.info() / gs.debug() / gs.warn() / gs.error(): The simplest and most powerful tool. Use these to log variable values, check script execution flow, and confirm query results. They appear in the System Logs (System Logs > System Log > All).
```
gs.info('Value of variable x: ' + x);
if (gr.hasNext()) {
    gs.info('Query found records.');
} else {
    gs.info('Query found no records.');
}
```
System Logs: Always check the system logs. They provide execution details, error messages, and anything you print with gs.info().
Script Debugger: For more complex scenarios, the ServiceNow Script Debugger (available for server-side scripts) allows you to set breakpoints, step through code, and inspect variables in real-time.
ACLs (Access Control Lists): If your GlideRecord script isn’t creating, updating, or deleting records, or if certain fields aren’t populating, ACLs are often the culprit. The user account under which the script runs (often the “System” user for Business Rules, or the calling user for UI Actions) needs the necessary permissions.
Field Names: Double-check field names for typos. A misspelled field name will simply be ignored or cause an error.
sys_id for Reference Fields: Ensure you are using the correct sys_id for reference fields and not a display name (unless using `setDisplayValue`).
Encoded Queries: Test complex `addEncodedQuery` strings in a list view’s filter builder first to ensure they return the expected results. Then copy and paste.

try-catch Blocks: Wrap potentially error-prone code in `try-catch` blocks to gracefully handle exceptions and log custom error messages.

try {
    // Your GlideRecord operations here
    var gr = new GlideRecord('non_existent_table'); // This would cause an error
    gr.insert();
} catch (ex) {
    gs.error('An error occurred in my script: ' + ex.message);
}

Context/Timing: Be aware if your script is in a “Before” or “After” Business Rule, or a different context. This affects whether current is already saved to the database.

Interview Relevance:

This demonstrates your practical skills and maturity as a developer. Debugging is a daily task, and showing you have a systematic approach, from simple logging to using advanced tools, instills confidence in your problem-solving abilities. Mentioning ACLs shows a holistic understanding of how different platform components interact.

Wrapping Up

GlideRecord is undeniably the workhorse of server-side scripting in ServiceNow. Mastering these top interview questions isn’t just about regurgitating answers; it’s about showcasing a deep understanding of ServiceNow’s core architecture, best practices, and your ability to apply scripting to solve real-world challenges.

Remember to always explain the “why” behind your answers, provide clear examples, and articulate your thought process. Practice writing these scripts, even simple ones, in your personal developer instance. The more comfortable you are with the API and its nuances, the more confident you’ll be in any interview scenario.

Good luck, and happy coding!

1. What is GlideRecord, and why is it fundamental to ServiceNow scripting?

The Core Concept:

Why it’s Fundamental:

Interview Relevance:

2. How do you programmatically manage Users and Groups in ServiceNow?

User Table Name & Creation:

Group Table Name & Creation:

Interview Relevance:

3. How do you script Role Assignment and Group Membership, and what are the best practices for permissions?

The Best Practice: Assign Roles to Groups, not Users!

Scripting Role Assignment:

Adding a Role to a User (Use with caution, prefer groups!):

Adding a Role to a Group (Recommended Approach):

Scripting Group Membership:

Adding a Group Member:

Removing a Group Member:

Interview Relevance:

4. How do you create core ITIL records (Incident, Problem, Change) using GlideRecord?

Common Pattern:

Creating an Incident Record:

Creating a Problem Record:

Creating a Change Request:

Troubleshooting Tip:

Interview Relevance:

5. How would you implement logic for parent-child record closure (e.g., closing child incidents when a parent closes)?

The Scenario: Closing Child Incidents

The Scenario: Closing Incidents when Associated Problem Closes

Interview Relevance:

6. How do you prevent an action (e.g., closing an Incident) if related records are in an open state?

The Scenario: Preventing Incident Closure

Key elements:

Interview Relevance:

7. Explain the differences between the current object and a new GlideRecord instance, and how to set field values.

The current Object:

A New GlideRecord Instance:

Setting Field Values: current.field_name = value vs. current.setValue('field_name', value) vs. current.setDisplayValue('field_name', value)

Interview Relevance:

8. What are Reference Qualifiers, what types exist, and how do they differ?

What are Reference Qualifiers?

Types of Reference Qualifiers:

a) Simple Reference Qualifier:

b) Dynamic Reference Qualifier:

c) Advanced Reference Qualifier (JavaScript Reference Qualifier):

Interview Relevance:

9. What are other crucial GlideRecord methods you frequently use, and what are their purposes?

Essential GlideRecord Methods:

Interview Relevance:

10. How do you troubleshoot and debug GlideRecord scripts in ServiceNow?

Common Debugging Techniques:

Interview Relevance:

Wrapping Up

7. Explain the differences between the `current` object and a new GlideRecord instance, and how to set field values.

The `current` Object:

Setting Field Values: `current.field_name = value` vs. `current.setValue('field_name', value)` vs. `current.setDisplayValue('field_name', value)`