A1. “My current focus is on the Washington DC release, which is the latest version available. Prior to this, I’ve had hands-on experience with several key versions, including Rome, San Diego, Tokyo, Utah, and Vancouver. This progression has given me a strong understanding of how features evolve and the impact of upgrades on the platform.”

Why this answer works: It’s direct, provides the latest version, and lists a chronological sequence of previous versions, showcasing continuous learning and practical application across different platform lifecycles.

A2. “Yes, absolutely. In ServiceNow, permissions are primarily managed through roles. We can assign roles directly to individual users, or more effectively, to groups. The best practice is to assign roles to groups rather than directly to users. Here’s why: When an employee leaves an organization, or their responsibilities change, you simply remove them from the relevant group(s). This automatically revokes all the roles previously assigned through that group, significantly simplifying user lifecycle management and reducing the risk of orphaned permissions. Manually managing roles for each user can become cumbersome and error-prone, especially in larger organizations.”

Interview Tip: Be ready to explain the concept of roles and how they map to permissions. Mentioning the efficiency and security benefits of group-based role assignment is key.

A3. The primary table for user information in ServiceNow is sys_user.

A4. The table that manages the relationship between users and groups (i.e., who is a member of which group) is sys_user_grmember.

A5. We use the GlideRecord API to interact with tables. To create a user, you would instantiate a GlideRecord object for the sys_user table, initialize it, set the necessary fields, and then call the insert() method. For example:

var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username = 'jdoe';
userGr.first_name = 'John'; // Note: Field name is usually snake_case
userGr.last_name = 'Doe';
userGr.email = 'jdoe@example.com';
userGr.insert();
    

Troubleshooting: Ensure you’re using the correct field names (often lowercase with underscores, like first_name instead of firstname). Check for any mandatory fields you might have missed.

A6. Similar to user creation, we use GlideRecord for the sys_user_group table. You’ll typically need to set a name, and optionally a manager (using their sys_id) and description.

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Testing_Team';
newGr.manager = '62826bf03710200044e0bfc8bcbe5df1'; // Replace with actual sys_id of a user
newGr.email = 'testingteam@example.com';
newGr.description = 'Group for testing purposes';
newGr.insert();
    

Practicality: In a real scenario, you’d likely retrieve the manager’s sys_id dynamically or from a configuration record.

A7. Adding permissions involves creating records in specific many-to-many relationship tables:

• For Users: The relationship between users and roles is managed in the sys_user_has_role table. You’ll need the sys_id of the user and the sys_id of the role.

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
userRole.setValue('user', 'user_sys_id_here'); // e.g., '62826bf03710200044e0bfc8bcbe5df1'
userRole.setValue('role', 'role_sys_id_here'); // e.g., '2831a114c611228501d4ea6c309d626d'
userRole.insert();
        

• For Groups: The relationship between groups and roles is managed in the sys_group_has_role table.

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
grpRole.setValue('group', 'group_sys_id_here'); // e.g., '477a05d153013010b846ddeeff7b1225'
grpRole.setValue('role', 'role_sys_id_here'); // e.g., '2831a114c611228501d4ea6c309d626d'
grpRole.insert();
        

Key Takeaway: Always remember to use the correct relationship table (sys_user_has_role for users, sys_group_has_role for groups) and the respective sys_ids.

A8. User delegation in ServiceNow allows one user to act on behalf of another user. This is typically used when the original user is unavailable – for instance, during vacation, leave, or extended absence. The delegated user gains the ability to perform tasks, view records, and even receive notifications and approvals that would normally be directed to the original user. It’s crucial for maintaining workflow continuity.

How it works: An employee can configure delegation by accessing their user record, scrolling down to the ‘Delegates’ related list, and specifying who they want to delegate to (the delegate), the start and end dates for the delegation, and what permissions the delegate should have (e.g., for approvals, notifications, or assignments).

Real-world Example: Imagine a manager going on leave. They can delegate their approval tasks for purchase requests to their team lead. This ensures that requests are still being processed without delay.

A9. We use the sys_user_grmember table for this.

• Adding a Group Member: You create a new record in sys_user_grmember, linking the user’s sys_id to the group’s sys_id.

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
grMem.user = 'user_sys_id_here'; // e.g., '62826bf03710200044e0bfc8bcbe5df1'
grMem.group = 'group_sys_id_here'; // e.g., '477a05d153013010b846ddeeff7b1225'
grMem.insert();
        

• Removing a Group Member: You need to query for the specific membership record using the user and group sys_ids and then delete it.

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', 'user_sys_id_here'); // e.g., '62826bf03710200044e0bfc8bcbe5df1'
grMem.addQuery('group', 'group_sys_id_here'); // e.g., '477a05d153013010b846ddeeff7b1225'
grMem.query();
if (grMem.next()) {
    grMem.deleteRecord();
}
        

Efficiency Tip: When removing, ensure you have a grMem.next() check before deleting to avoid errors if the member doesn’t exist in the group.

A10. ServiceNow has evolved through several user interfaces. Historically, we’ve seen UI15 and UI16. Currently, the modern and recommended interface is the Next Experience UI, which offers a more streamlined and user-friendly experience.

Interview Tip: Briefly mentioning the advantages of the Next Experience UI, such as improved navigation and performance, can further impress the interviewer.

A11. A “Web Services User” in ServiceNow is an account specifically designed to allow external applications or systems to connect and interact with ServiceNow programmatically via web services (like REST or SOAP). The key characteristic is that this type of user cannot log in to the ServiceNow graphical user interface (GUI). They are purely for system-to-system integration, making them ideal for automated data exchange without requiring human intervention or interaction with the platform’s UI.

Security Consideration: These users typically have very specific roles assigned, granting them only the necessary permissions for their integration tasks, adhering to the principle of least privilege.

A12. On the client-side (within client scripts, UI policies, etc.), you can access the logged-in user’s sys_id using the global variable g_user.userID.

// Example in a Client Script
var currentUserId = g_user.userID;
console.log("Current User Sys ID (Client-side): " + currentUserId);
    

A13. On the server-side (within Business Rules, Script Includes, etc.), you use the gs object (GlideSystem) to get the current user’s sys_id with gs.getUserID().

// Example in a Business Rule
var currentUserId = gs.getUserID();
gs.info("Current User Sys ID (Server-side): " + currentUserId);
    

Important Distinction: Always remember to use g_user on the client and gs on the server. Mixing these will lead to errors.

A15. Impersonation in ServiceNow allows an administrator or user with the appropriate role (like admin or user_admin) to temporarily log in as another user. This is an invaluable tool for testing user experiences, troubleshooting issues specific to a user’s context, and verifying the impact of configurations or scripts from a particular user’s perspective, all without needing their actual credentials.

Best Practice: Always ensure you are impersonating for a specific, justifiable reason and promptly stop impersonating once your task is complete. Logged impersonation activities can be tracked.

A16. User preferences in ServiceNow refer to settings that individual users can configure to personalize their experience within the platform. These can range from list view configurations (columns displayed, sort order), form layout customizations, to notification settings. Critically, these preferences are user-specific; changing a preference for one user only affects that user and does not impact the global platform configuration.

A17. An incident in ServiceNow represents an unplanned interruption to an IT service or a reduction in the quality of an IT service. When an employee experiences something suddenly stopping working, like their email client crashing or a critical application becoming unresponsive, they would typically raise an incident to get support and restore the service as quickly as possible.

A18. A problem is the underlying root cause of one or more incidents. If the same incident (e.g., frequent application crashes) occurs repeatedly for the same employee, or if similar incidents affect multiple employees, it signals a potential problem. The goal of problem management is to identify the root cause and either resolve it permanently or find a workaround to prevent future incidents. If a problem is identified, a parent incident might be created, with all related recurring incidents linked as child incidents. Closing the parent problem would then often cascade the closure to its associated incidents.

A19. Yes, absolutely. If a support engineer identifies that an incident is recurring or potentially part of a larger, underlying issue, they can create a problem record directly from that incident. This is a standard workflow to transition from immediate service restoration (incident management) to root cause analysis (problem management).

A20. Yes. When an incident is being resolved, if the support team determines that the resolution requires a change to the IT infrastructure or an application (e.g., deploying a patch, reconfiguring a server), they will initiate a change request from that incident. This ensures that the change is properly documented, assessed for risk, planned, and approved.

A21. They form a critical trio in IT Service Management (ITSM):

• Incident Management: Focuses on restoring normal service operation as quickly as possible and minimizing the adverse impact on business operations.
• Problem Management: Focuses on identifying the root cause of incidents, preventing their recurrence, and minimizing the impact of unavoidable incidents.
• Change Management: Focuses on controlling the lifecycle of all changes, enabling beneficial changes to be made with minimum disruption to IT services.

The typical flow is: An incident occurs. If it’s recurring or complex, a problem is identified for root cause analysis. The solution to the problem might then require a planned change to be implemented.