1. Which is the current version you are working on in ServiceNow? And from which version did you start?

This question is a common icebreaker and helps the interviewer understand your exposure to different ServiceNow releases. It’s not about having the absolute latest version but about demonstrating a history of learning and adapting.

Human-like Answer: “I’m currently working on the Washington DC release, which is the latest one available. My journey with ServiceNow started back with the Rome release, and since then, I’ve had the opportunity to work with San Diego, Tokyo, Utah, and Vancouver as well. Each release brings its own set of enhancements and sometimes new ways of doing things, so it’s always been about staying updated and leveraging the new features effectively.”

Interview Relevance: Shows you’re current with the platform and have a foundational understanding of its evolution.

Tip: Be honest about the versions you’ve worked with. If you haven’t worked with the absolute latest, highlight your experience with recent, stable releases and express enthusiasm for learning newer ones.

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

Permissions in ServiceNow are primarily managed through roles. This question probes your understanding of access control and best practices for managing it.

Human-like Answer: “Absolutely, we can and do add permissions to both users and groups in ServiceNow. The way we manage permissions is by assigning roles. You can assign roles directly to individual users, or, and this is the key part, you can assign roles to groups. The best practice by far is to manage permissions through groups. Why? Because it’s much more efficient and maintainable. When an employee joins, you add them to the relevant groups, and they automatically inherit the necessary roles. Conversely, when an employee leaves, you simply remove them from their groups, and all their associated roles are revoked instantly. This prevents orphaned roles and simplifies user lifecycle management significantly.”

Interview Relevance: Tests your grasp of security fundamentals and enterprise administration best practices.

Troubleshooting Scenario: What if a user has too many permissions?

• Check direct role assignments: First, review if roles were assigned directly to the user. This is generally discouraged.
• Review group memberships: Examine all the groups the user belongs to and the roles assigned to those groups.
• Analyze role hierarchy: Understand how roles inherit permissions. Sometimes a seemingly innocuous role can grant broad access.
• Use Access Control Lists (ACLs): If specific access is still an issue, investigate ACLs to see if there are any specific restrictions or grants that might be causing conflicts.

3. What is the user table name? And what is the group member table name?

This is a fundamental question testing your knowledge of ServiceNow’s core tables. Knowing these table names is crucial for scripting and administration.

Human-like Answer: “The primary table for user information in ServiceNow is sys_user. And for managing the members within groups, the table we look at is sys_user_grmember. This table acts as a bridge, linking users to the groups they belong to.”

Interview Relevance: Basic but essential knowledge for anyone working with user management and data manipulation in ServiceNow.

4. How to create a user account using script?

This question assesses your ability to automate user creation, a common requirement in integrating ServiceNow with HR systems or for bulk user provisioning.

Human-like Answer: “We can create a user account programmatically using GlideRecord. Here’s a simple example:

var userGr = new GlideRecord('sys_user');
userGr.initialize();
userGr.username = 'jdoe'; // Set the username
userGr.first_name = 'John'; // Set the first name
userGr.last_name = 'Doe';  // Set the last name
userGr.email = 'jdoe@example.com'; // Set the email address
userGr.active = true; // Ensure the user is active
userGr.insert(); // Save the new user record
        

You’d typically set other fields like ‘password’, ‘department’, ‘manager’, etc., as per your requirements.”

Interview Relevance: Demonstrates scripting capability and understanding of record manipulation.

Troubleshooting: What if the user isn’t created?

• Check script logs: Look for any JavaScript errors in the system logs (System Logs > System Log > All).
• Permissions: Ensure the script running context (e.g., a Business Rule, a Scheduled Job) has the necessary roles to write to the sys_user table.
• Field validation: Verify that all required fields (like username, email) are populated and meet ServiceNow’s validation rules. For instance, usernames usually need to be unique.
• Duplicate username/email: Check if a user with the same username or email already exists.

5. How to create a group using script?

Similar to user creation, automating group creation is vital for organizational management.

Human-like Answer: “Creating a group with a script uses the same GlideRecord approach. Here’s how you’d do it:

var newGr = new GlideRecord('sys_user_group');
newGr.initialize();
newGr.name = 'Testing Team'; // Name of the new group
newGr.description = 'This group is for testing purposes.'; // Description
// Optionally, assign a manager (using their sys_id)
// var managerSysId = '62826bf03710200044e0bfc8bcbe5df1'; // Replace with an actual sys_id
// newGr.manager = managerSysId;
newGr.email = 'testingteam@example.com'; // Group email
newGr.insert(); // Save the new group record
        

Remember to replace placeholder sys_ids with actual ones from your instance.

”

Interview Relevance: Further tests your scripting skills for core ServiceNow objects.

6. How to add permissions (roles) to a user or group account using script?

This question delves into the actual mechanism of assigning roles, which is fundamental to ServiceNow security.

Human-like Answer: “When you add a role to a user, ServiceNow creates a record in the sys_user_has_role table. To do this with a script:

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

For adding a role to a group, the table involved is sys_group_has_role. The script is very similar:

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
grpRole.group = 'SYS_ID_OF_THE_GROUP'; // e.g., '477a05d153013010b846ddeeff7b1225'
grpRole.role = 'SYS_ID_OF_THE_ROLE'; // Same role sys_id as above
grpRole.insert();
        

It’s crucial to use the actual sys_ids for both the user/group and the role.

”

Interview Relevance: Shows deep understanding of the underlying data model for role assignments.

Troubleshooting: Role not appearing for the user/group?

• Correct Sys IDs: Double-check that you’re using the correct sys_id for both the user/group and the role. A typo here is common.
• Table Names: Ensure you’re using sys_user_has_role for users and sys_group_has_role for groups.
• Existing Record: The script assumes a new assignment. If the role is already assigned, attempting to insert again might cause issues or simply do nothing. You might need to query first.
• Role Exists: Confirm the role itself exists in the system.

7. What exactly does user delegation mean in ServiceNow?

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

Human-like Answer: “User delegation in ServiceNow allows one user to act on behalf of another user. This is typically used when the original user is out of office, perhaps on vacation or sick leave, and needs critical tasks like approvals or requests to be handled in their absence. The delegated user gains specific permissions to perform actions—like approving tasks or receiving notifications—that would normally be restricted to the original user. It’s a way to keep workflows moving smoothly without interruption. You can configure this by going to the original user’s record, scrolling down to the ‘Delegates’ related list, and specifying who the delegate is, the date range, and what actions they can perform on your behalf (assignments, notifications, approvals).”

Interview Relevance: Tests your understanding of practical ServiceNow features that enhance business operations.

Real-world Example: Imagine a Senior Manager who approves all change requests. If they go on a two-week vacation, they can delegate their approval authority to their Deputy Manager. During that period, the Deputy Manager can approve or reject change requests as if they were the Senior Manager. Once the Senior Manager returns, the delegation can be deactivated or expire automatically.

8. How to add and remove group members from a group using script?

This is a practical scripting question for managing group memberships dynamically.

Human-like Answer: “We manage group membership through the sys_user_grmember table. Here’s how you’d add a user to a group:

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
grMem.user = 'SYS_ID_OF_THE_USER'; // The user to add
grMem.group = 'SYS_ID_OF_THE_GROUP'; // The group to add to
grMem.insert();
        

To remove a member, you first need to find the specific record in the sys_user_grmember table and then delete it:

var grMem = new GlideRecord('sys_user_grmember');
grMem.addQuery('user', 'SYS_ID_OF_THE_USER'); // The user to remove
grMem.addQuery('group', 'SYS_ID_OF_THE_GROUP'); // The group to remove from
grMem.query(); // Execute the query

if (grMem.next()) { // If a matching record is found
    grMem.deleteRecord(); // Delete that specific membership record
}
        

It’s good practice to always query first to ensure the membership exists before attempting deletion, although in this specific scenario, if it doesn’t exist, the if (grMem.next()) block simply won’t execute.

”

Interview Relevance: Tests practical scripting for user management within groups.

9. What are the different user interfaces in ServiceNow?

This question gauges your familiarity with the evolution of ServiceNow’s front-end design.

Human-like Answer: “ServiceNow has had a few distinct user interface generations. Historically, there was UI15, which was followed by UI16. More recently, ServiceNow introduced the Next Experience UI (also sometimes referred to as Polaris or the ‘new UI’), which offers a more modern, streamlined, and intuitive user experience with features like universal search and customizable workspaces. Most organizations are in the process of or have already migrated to the Next Experience UI.”

Interview Relevance: Shows awareness of the platform’s development and user experience focus.

Tip: Mentioning your experience with transitioning between UIs or your preference for the Next Experience UI can be a plus.

10. What is meant by a web services user in ServiceNow?

This question tests your understanding of how ServiceNow integrates with external systems.

Human-like Answer: “A web services user in ServiceNow is a special type of user account that is primarily used for integrations. It’s designed to allow third-party applications or other systems to connect to ServiceNow and exchange data via web services (like REST or SOAP) without needing to log in through the standard user interface. Crucially, these web services users cannot log in to the ServiceNow GUI as a regular user would. They are granted specific permissions, typically via roles, to perform actions or access data that the integrating application needs. This is essential for secure and automated data exchange.”

Interview Relevance: Important for understanding integration patterns and security for system-to-system communication.

Troubleshooting: An integration is failing, and you suspect the web services user.

• Credentials: Verify the username and password/authentication token used by the external system are correct for the web services user.
• Roles: Ensure the web services user account has the necessary roles assigned to perform the required operations (e.g., rest_api_explorer, soap_query, or custom roles with specific table access).
• ACLs: Check Access Control Lists (ACLs) to ensure the web services user is permitted to perform the specific actions (read, write, create, delete) on the target tables.
• User Status: Confirm that the web services user account is active and not locked out.
• System Properties: Some integrations might rely on specific system properties being configured.