1. Which ServiceNow version are you currently working with, and from which versions have you gained experience?

This question is a classic icebreaker, but it’s more than just trivia. It gauges your exposure to the platform’s evolution and your ability to adapt to new features and changes.

Human-like Answer:

“Currently, I’m actively working with the Washington DC release. Before that, my experience spans across several recent and stable versions, including Rome, San Diego, Tokyo, Utah, and Vancouver. This journey has given me a good perspective on the incremental improvements and new functionalities introduced across these releases, allowing me to appreciate the platform’s continuous development.”

Interview Relevance: Employers want to know if you’re up-to-date with the latest features and if you have a broad enough understanding of the platform’s history to avoid common pitfalls or leverage older, still-relevant patterns.

2. How do you manage user permissions and roles within a scoped application? What’s the best practice?

Permissions are the bedrock of security and access control. In scoped applications, this becomes even more critical as you want to isolate your app’s data and functionality.

Human-like Answer:

“Within a scoped application, managing permissions primarily revolves around defining and assigning roles. You can create custom roles specific to your application’s needs. For instance, if you have a ‘Project Management’ scoped app, you might have roles like ‘Project Manager,’ ‘Team Member,’ and ‘Read-Only Viewer.’ These roles then dictate what actions users or groups can perform (create, read, write, delete) on tables and specific records within that scope.

The best practice is to leverage groups for assigning roles. Instead of directly assigning roles to individual users, you assign roles to groups. Then, you add users to these groups. Why is this better? It drastically simplifies user management. When an employee joins or leaves a team, you simply add or remove them from the relevant group, and their permissions update automatically. This follows the principle of least privilege and is much more scalable and less error-prone than manual user-to-role assignments.”

Technical Insight:

• User table: sys_user
• Group table: sys_user_group
• User roles table: sys_user_has_role
• Group roles table: sys_group_has_role

Scripting Example (Adding a role to a group):

// Assuming you have the sys_id of the group and the role
var groupSysId = 'your_group_sys_id'; // e.g., '477a05d153013010b846ddeeff7b1225'
var roleSysId = 'your_role_sys_id';   // e.g., '2831a114c611228501d4ea6c309d626d'

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
grpRole.setValue('group', groupSysId);
grpRole.setValue('role', roleSysId);
grpRole.insert();
gs.info('Role ' + roleSysId + ' assigned to group ' + groupSysId);
        

3. Can you explain user delegation in ServiceNow?

User delegation is a powerful feature for ensuring business continuity when users are unavailable.

Human-like Answer:

“User delegation in ServiceNow is essentially about empowering one user to act on behalf of another. It’s commonly used when an employee is out of the office – on vacation, sick leave, or attending a conference. The original user can delegate specific tasks or responsibilities to a colleague.

For example, if a manager is on leave and needs to approve requests, they can delegate their approval tasks to their direct report. The delegated user then sees those tasks in their own queue and can act on them as if they were the original user, but only for the duration and with the permissions specified by the delegator.

To set this up, the original user would typically go to their profile settings, find the ‘Delegates’ section, and then specify who they want to delegate to, the start and end dates of the delegation, and what actions they are delegating (e.g., approvals, notifications, assignments). This ensures critical workflows don’t halt when someone is temporarily unavailable.”

4. How do you create and manage users and groups programmatically using scripts?

Being able to automate user and group management is essential for larger deployments and integrations.

Human-like Answer:

“When we need to create or update user and group records via scripting, the workhorse is definitely GlideRecord. It allows us to interact with ServiceNow tables just like you would with a database.

Creating a User: You’d initialize a new GlideRecord for the sys_user table, set the required fields like username, first name, last name, and email, and then call the insert() method.

var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username = 'jdoe';
userGr.firstName = 'John';
userGr.lastName = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.user_password = gs.encrypt('Password123'); // For initial setup, consider more secure methods for production
userGr.active = true;
var newUserSysId = userGr.insert(); // Store the sys_id if needed for further operations
gs.info('User created with sys_id: ' + newUserSysId);
        

Creating a Group: Similarly, for groups, you’d use GlideRecord on the sys_user_group table. You’d set the group name, description, and potentially a manager’s sys_id (found in sys_user).

var groupGr = new GlideRecord('sys_user_group');
groupGr.initialize();
groupGr.name = 'Application Support Team';
groupGr.description = 'Handles support for the custom app.';
groupGr.manager = 'sys_id_of_manager'; // e.g., '62826bf03710200044e0bfc8bcbe5df1'
var newGroupSysId = groupGr.insert();
gs.info('Group created with sys_id: ' + newGroupSysId);
        

Adding a User to a Group: This involves the sys_user_grmember table. You’ll typically query for an existing record or create a new one.

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
grMem.user = 'sys_id_of_user'; // e.g., 'user_sys_id_of_jdoe'
grMem.group = 'sys_id_of_group'; // e.g., 'sys_id_of_Application Support Team'
grMem.insert();
gs.info('User added to group.');
        

Removing a User from a Group: You’ll query the sys_user_grmember table based on the user and group sys_ids and then delete the record.

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', 'sys_id_of_user');
grMem.addQuery('group', 'sys_id_of_group');
grMem.query();
if (grMem.next()) {
    grMem.deleteRecord();
    gs.info('User removed from group.');
}
        

5. What is the difference between a Scoped App and a Global Application?

This is fundamental to understanding modern ServiceNow development.

Human-like Answer:

“The key difference lies in their scope of influence and how they manage their artifacts (tables, scripts, UI elements, etc.).

Global Applications: Think of these as the original way ServiceNow applications were built. Everything developed in the global scope is available everywhere on the platform. This includes custom tables, scripts, UI policies, business rules, etc. While flexible, this can lead to naming collisions, difficulties in upgrades, and a lack of clear ownership. All customizations made before scoped apps became the standard reside in the global scope.

Scoped Applications: These are the modern, best-practice approach. A scoped application defines a specific, isolated namespace for its components. Its tables, scripts, and configurations are inherently tied to that application’s scope. This means:

• Namespace Isolation: A table named ‘Task’ in your ‘My App’ scope is completely different from a ‘Task’ table in another app or the global scope. This prevents naming conflicts.
• Security: ACLs (Access Control Lists) can be more granularly applied within a scope.
• Maintainability & Upgradability: When you upgrade the ServiceNow platform, scoped applications are less likely to break because their components are isolated. They can also be more easily packaged, distributed, and installed.
• Self-Contained: They are designed to be independent and reusable.

In essence, global is like a single, shared workspace where everyone can place their tools, potentially leading to chaos. Scoped applications are like individual workshops, each with its own dedicated space and tools, promoting order and efficiency.”

6. How do you define and implement custom roles within a scoped application?

Roles are the building blocks for controlling access within your scoped app.

Human-like Answer:

“Within my scoped application, I’d navigate to ‘Application Roles‘ under ‘System Security‘ or the equivalent module within my app’s creator. Here, I can define new roles, giving them a descriptive name (e.g., ‘MyAwesomeApp_Manager‘, ‘MyAwesomeApp_Viewer‘).

Crucially, I’d then associate these roles with specific Access Control Lists (ACLs). For example, if I want ‘MyAwesomeApp_Manager‘ to be able to create and update records in my custom ‘u_project‘ table, I’d create two ACLs:

• An ACL for ‘create‘ operation on ‘u_project‘ and assign the ‘MyAwesomeApp_Manager‘ role to it.
• An ACL for ‘write‘ operation on ‘u_project‘ and assign the ‘MyAwesomeApp_Manager‘ role to it.

I can also define roles that grant read access to specific tables or even specific fields. It’s all about mapping user actions (create, read, write, delete) to specific tables and then granting the appropriate roles to those ACLs. This ensures only authorized users can interact with the application’s data and functionality.”

7. What is the purpose of a `sys_id` and how is it used in Scoped Applications?

The `sys_id` is the unique identifier in ServiceNow, and understanding its role is vital.

Human-like Answer:

“The sys_id is ServiceNow’s unique identifier for every record in every table. Think of it as a universally unique identifier (UUID) or a primary key. It’s a 32-character alphanumeric string that guarantees each record is distinct, even across different tables or applications.

In Scoped Applications, the sys_id is absolutely fundamental. Here’s why:

• Referencing Records: Whenever you create a reference or list field pointing to another table (e.g., a ‘Caller’ field on an Incident referencing the sys_user table), you are storing the sys_id of the referenced record.
• Scripting: In server-side or client-side scripts, when you need to fetch, update, or delete a specific record, you’ll use its sys_id. For example, `new GlideRecord(‘incident’).get(‘sys_id’, ‘your_incident_sys_id’);`
• URLs: Record URLs in ServiceNow are built using the table name and the record’s sys_id.
• Integrations: When integrating with external systems, sys_ids are often used to uniquely identify records between ServiceNow and other platforms.
• Application Scope: While sys_ids are globally unique for records, within a scoped app, the sys_id of application artifacts (like tables, scripts, UI policies) are also unique to that application’s scope, further reinforcing the isolation principle.

You’ll see sys_ids everywhere – in URLs, in script logs, in database queries, and as values in reference fields. It’s the backbone of record identification and manipulation in ServiceNow.”

8. Explain the concept of “Class” in relation to table inheritance in ServiceNow.

This question delves into the foundational data model of ServiceNow.

Human-like Answer:

“In ServiceNow, when you extend a table, you’re essentially creating a child table that inherits fields and properties from a parent table. The ‘Class‘ field plays a crucial role in this inheritance hierarchy.

When a table extends another (e.g., ‘Incident‘ extends ‘Task‘), ServiceNow automatically adds a ‘Class‘ field to the *parent* table (in this case, ‘Task‘). This ‘Class‘ field stores the sys_id of the *child* table that the current record belongs to.

So, if you have a record in the ‘Incident‘ table, the ‘Class‘ field on the ‘Task‘ table record will store the sys_id of the ‘Incident‘ table. If you have a record in the ‘Problem‘ table (which also extends ‘Task‘), its corresponding ‘Task‘ record’s ‘Class‘ field will store the sys_id of the ‘Problem‘ table.

This is how ServiceNow efficiently manages records that share common fields but have unique attributes. It allows for a single record to be recognized as a specific type (like Incident) even though it’s stored within a more generic parent table structure. It’s a clever way to achieve polymorphism in a database context.”

Technical Note: A table can only extend one other table directly (single inheritance). However, a table can be extended by multiple child tables. The ‘Class’ field on the parent tracks which specific child table a record truly belongs to.

9. How do you implement dependent fields and dynamic reference qualifiers in your scoped applications?

These features enhance user experience by providing context-aware filtering.

Human-like Answer:

“Both dependent fields and dynamic reference qualifiers are powerful tools for creating intuitive user interfaces, especially within scoped applications.

Dependent Fields: These create cascaded dropdowns. Imagine you have a ‘Category‘ field and then a ‘Subcategory‘ field. When a user selects ‘Hardware‘ in ‘Category‘, the ‘Subcategory‘ dropdown should only show hardware-related options.

To implement this, you go to the dictionary entry of the dependent field (Subcategory) and set the ‘Dependent field‘ attribute to the parent field (Category). Then, in the choices for the Subcategory field, you link each choice to a specific value of the parent field. So, ‘Laptop’ would be linked to ‘Hardware’, ‘Printer’ to ‘Hardware’, ‘Operating System’ to ‘Software’, and so on. It’s all configured in the choice list definitions.

Dynamic Reference Qualifiers: These are used to filter records in a reference field based on the current context of the form. For example, on an Incident form, you might want the ‘Affected CI‘ field to only show Configuration Items (CIs) that are relevant to the selected ‘Business Service‘.

You achieve this by navigating to ‘Dynamic Filter Options‘ (under System Definition) to create reusable filter definitions. Then, in the reference field’s dictionary entry, you select ‘Dynamic‘ as the reference qualifier type and choose your created dynamic filter option. The system then dynamically builds the query for the reference field based on the selected values on the form, ensuring users only see relevant data.”

Simple vs. Dynamic vs. Advanced Reference Qualifiers:

• Simple: A static query directly in the dictionary entry (e.g., `active=true`). Good for fixed filters.
• Dynamic: Uses predefined dynamic filter options, making it reusable and context-aware.
• Advanced: Involves writing JavaScript code directly in the dictionary entry to create complex, custom filtering logic. This offers the most flexibility for intricate requirements.

10. How do you handle client-side vs. server-side scripting in a scoped application? When would you choose one over the other?

Understanding execution context is critical for efficient and secure development.

Human-like Answer:

“This is a fundamental consideration for any ServiceNow developer, especially in scoped applications. The core difference is where the code runs:

• Client-Side Scripting: This code runs directly in the user’s web browser. Examples include UI Policies (with ‘Run scripts’ enabled), Client Scripts (onLoad, onChange, onSubmit), and some UI Actions. It’s great for immediate user feedback, manipulating the form as the user interacts with it, and validating data *before* it’s sent to the server. However, client-side logic is visible in the browser’s source code and can be bypassed, so sensitive operations should never be performed solely client-side.
• Server-Side Scripting: This code runs on the ServiceNow instance itself. This includes Business Rules, Script Includes, UI Actions (when executed on the server), Workflow scripts, and REST/SOAP message processing. Server-side scripting is where you perform database operations (GlideRecord), integrate with other systems, enforce complex security logic, and perform heavy calculations. It’s more secure because the logic isn’t exposed to the end-user’s browser.

When to choose which:

• Choose Client-Side for:
• Making fields mandatory/read-only/visible dynamically based on other field values.
• Showing or hiding form sections or related lists.
• Providing real-time validation and user feedback (e.g., “Please enter a valid email address”).
• Performing simple lookups or setting default values that don’t require complex logic.
• Choose Server-Side for:
• Creating, updating, or deleting records in the database (e.g., creating child incidents from a problem).
• Enforcing business rules and complex validation that *must* be secure.
• Integrations with external systems.
• Performing complex calculations or data transformations.
• Any operation that involves sensitive data or requires absolute certainty of execution.

In a scoped application, it’s common to use both. For instance, a client script might trigger a server-side script include (via `GlideAjax`) to fetch data or perform an action securely, then the client script uses the returned data to update the form.

Troubleshooting: If a script isn’t working as expected, first determine its execution context. Check the browser’s developer console for client-side errors, and check the System Logs (syslog) for server-side errors. Ensure the script is defined within the correct scope and has the necessary permissions.”