The Expert Answer:

“Currently, I’m working with the Washington DC release. It’s always exciting to be on the latest version, as it brings a host of new features and performance enhancements.

My journey with ServiceNow versions includes Rome, San Diego, Tokyo, Utah, and Vancouver. This progression has given me a solid understanding of how the platform evolves and how features are introduced or refined over time. Each version has its nuances, and understanding these differences is crucial for troubleshooting and leveraging the most up-to-date capabilities.”

The Expert Answer:

“Absolutely, you can. In ServiceNow, permissions are primarily managed through roles. You can assign roles directly to individual users or to groups. Scripting with GlideRecord is also a method for programmatically assigning roles.

The Expert Answer:

“The table that stores all user information is sys_user. This is where you’ll find details like username, first name, last name, email, and more.

For group membership, the table is sys_user_grmember. This table acts as a junction table, linking users to the groups they belong to. Each record in sys_user_grmember represents a specific user’s membership in a specific group.”

The Expert Answer:

“Creating user accounts programmatically is a common task, often for automation or bulk imports. We achieve this using the GlideRecord API. Here’s a typical script:

var userGr = new GlideRecord('sys_user');
userGr.initialize(); // Prepares a new record
userGr.setValue('username', 'jdoe'); // Set the username
userGr.setValue('first_name', 'John'); // Set the first name
userGr.setValue('last_name', 'Doe'); // Set the last name
userGr.setValue('email', 'jdoe@example.com'); // Set the email
userGr.insert(); // Inserts the new user record into the sys_user table
            

It’s important to ensure that any required fields are populated, and you’d typically want to handle potential errors or validation if this were part of a larger process. For instance, checking if a username already exists before attempting to insert.”

The Expert Answer:

“Similar to user creation, we use GlideRecord for creating groups programmatically. The table for groups is sys_user_group.

var newGr = new GlideRecord('sys_user_group');
newGr.initialize(); // Prepare a new group record
newGr.setValue('name', 'New Project Team'); // Set the group name
// Assigning a manager is common; you'd typically use the sys_id of an existing user
var managerSysId = '62826bf03710200044e0bfc8bcbe5df1'; // Replace with an actual sys_id
newGr.setValue('manager', managerSysId);
newGr.setValue('email', 'project.team@example.com'); // Set group email
newGr.setValue('description', 'Team responsible for the new project initiative'); // Set a description
newGr.insert(); // Insert the new group record
            

When creating groups, it’s essential to have the correct sys_id for any reference fields, like the manager. Again, robust error handling and validation are key in a production script.”

The Expert Answer:

“Assigning roles is done by inserting records into specific tables that link users/groups to roles.

For Users:

When you assign a role to a user, a record is created in the sys_user_has_role table. Here’s how you’d do it via script:

var userRole = new GlideRecord('sys_user_has_role');
userRole.initialize();
// Set the sys_id of the user you want to assign the role to
userRole.setValue('user', '62826bf03710200044e0bfc8bcbe5df1');
// Set the sys_id of the role you want to assign
userRole.setValue('role', '2831a114c611228501d4ea6c309d626d');
userRole.insert();
            

For Groups:

Similarly, when you assign a role to a group, a record is created in the sys_group_has_role table.

var grpRole = new GlideRecord('sys_group_has_role');
grpRole.initialize();
// Set the sys_id of the group you want to assign the role to
grpRole.setValue('group', '477a05d153013010b846ddeeff7b1225');
// Set the sys_id of the role you want to assign
grpRole.setValue('role', '2831a114c611228501d4ea6c309d626d');
grpRole.insert();
            

Again, the sys_ids are crucial here. You’d typically fetch these dynamically or have them stored in a configuration record. And remember the best practice: assigning roles to groups is generally preferred for manageability.”

The Expert Answer:

“User delegation in ServiceNow is a powerful feature that allows one user to perform tasks on behalf of another user. This is incredibly useful for scenarios like vacation coverage, extended leave, or when specific roles require temporary authorization. The delegated user gains access to the original user’s permissions and can act on their behalf.

For example, if an employee is going on vacation, they can delegate their approval tasks or other specific actions to a colleague. This ensures critical workflows continue uninterrupted.

Configuration: To set up user delegation, the original user would navigate to their user record, scroll down to the ‘Delegates’ related list, and click ‘New’. Here, they can specify:

• Delegate: The user who will be performing tasks on their behalf.
• Start Date & End Date: The period for which the delegation is active.
• Permissions: They can also granularly select what actions the delegate can perform, such as managing assignments, responding to notifications, or handling approvals.

The Expert Answer:

“Managing group memberships is a frequent administrative task, and scripting with GlideRecord is the way to go. The table we interact with here is sys_user_grmember.

Adding a Group Member:

var grMem = new GlideRecord('sys_user_grmember');
grMem.initialize();
// Set the sys_id of the user to add
grMem.setValue('user', '62826bf03710200044e0bfc8bcbe5df1');
// Set the sys_id of the group to add the user to
grMem.setValue('group', '477a05d153013010b846ddeeff7b1225');
grMem.insert();
console.log('User added to group successfully.');
            

Removing a Group Member:

To remove a member, you first need to query for the specific membership record and then delete it.

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

if (grMem.next()) { // If a matching record is found
    grMem.deleteRecord(); // Delete the membership record
    console.log('User removed from group successfully.');
} else {
    console.log('User not found in the specified group.');
}
            

In a real-world scenario, you’d want to include checks to ensure the user and group exist, and potentially handle cases where a user is already a member or not a member before attempting an action. Using `gs.log()` is often preferred over `console.log()` in server-side scripts for better log management.”

The Expert Answer:

“ServiceNow has evolved its user interface over the years to enhance user experience and modern aesthetics. The primary interfaces you’ll encounter are:

• UI16: This is the standard, modern interface that most users interact with daily. It’s designed for ease of navigation and a clean look.
• Next Experience UI: This is ServiceNow’s latest UI paradigm, aiming for an even more intuitive and streamlined user experience. It features a refreshed look and feel, enhanced navigation, and improved performance. Many organizations are migrating to or already using this.

While older versions like UI15 exist, they are largely deprecated and not typically encountered in modern deployments. The ‘Next Experience UI’ represents the future direction for ServiceNow’s user interaction. Understanding how to navigate and utilize these different interfaces is important for supporting users across various environments.”

The Expert Answer:

“A ‘web services user’ in ServiceNow is a special type of user account created specifically for integrations and programmatic access. This user account is not intended for direct login into the ServiceNow graphical user interface (GUI) by a human.

Instead, when a third-party application or another system needs to interact with ServiceNow (e.g., to create records, update data, or retrieve information via APIs like REST or SOAP), it uses the credentials of a web services user. This grants the external system the necessary permissions to perform these actions without needing a full ServiceNow user license or the ability to log into the platform.

Key characteristics include:

• No GUI Login: These users cannot log in through the standard ServiceNow portal.
• API Access: Their primary purpose is to authenticate API requests.
• Scoped Permissions: They are typically assigned specific roles that grant access only to the necessary tables and operations for the integration.