How To Assign Roles To A User In ServiceNow

Users, Groups and Roles in ServiceNow

All ServiceNow Admins need to have a solid understanding of how these 3 inter-related pieces of the platform work together. If you’re still a beginner, check out how to create a user in ServiceNow.

If you don’t have a proper grasp of how users, groups and roles fit together, you’re going to be wasting a lot of time manually updating them when you don’t have to.

While we always try to automate as much as possible in our day to day operations, there will always be manual setup required, especially when new teams start using the platform.

Master a couple simple concepts and save time to perform other work. It’s super important to understand how users in the system have different levels of access, how that access is granted and how it’s easily managed.

When you work at an organization with thousands of users with varying roles, things can get incredibly complicated quickly as far as provisioning users and their many different levels of access. If access is not properly adhere to, you risk exposing data to those who shouldn’t be seeing it – which can cause people to lose respect for ServiceNow.

To see what access a role grants a user, check out the ACL’s. Roles are connected to ACL’s and ACL’s determine what a user can and cannot see.

Thankfully, it doesn’t have to be so difficult for ServiceNow Admins to properly manage group and role allocation.

Let’s review how users, groups and their roles all work together.

Assign Roles To A User Directly? Not The Best Idea

The most important concept that new admins have to understand is the following:

There are users, who are members of groups, who inherit the roles of the groups that they are a member of.

While assigning a role directly to a user will “work”, it’s not scalable and isn’t a best practice. You can create a role for a single user in certain circumstances, but why would you assign it to them directly?

It won’t allow for a future admin, or yourself, to come back to that user in a few months and recall exactly what you were trying to accomplish.

If you’re a ServiceNow Admin, try to get a better understanding of how these 3 pieces of the platform work together, and you’ll end up saving yourself a lot of time in the long run.

If you want to give a role to a user directly, there’s probably a better idea that will scale in the future.

It’s almost never a good idea to apply a role to a user directly. While there are always corner cases in ServiceNow, it’s likely safe to say that it’s just not a good idea.

Instead, create a group and add the user to that group. Then assign role(s) to that group. This will allow for proper group management down the road. And you’ll never to remember what roles you allocated to a certain user.

Assign Roles To A Group Instead – This Scales

Role Required: admin

Whether you manage your groups locally in ServiceNow or via LDAP (or another centralized 3rd party) – you can attach a role directly to a group.

It is preferred to not manage groups directly in ServiceNow.

But if we are managing group membership in ServiceNow, we need to make sure that we have orchestration and automation in place to write back to Active Directory so both systems are kept in sync.

When you want to properly allocate a role to a group, navigate directly to the group record in ServiceNow. Then out of box, there should be a Related List at the bottom of the form that is titled “Roles”.

Say for example you have a Change Management Approvers group. This would usually be the “approval_user” role. To see what the “approval_user” role granted a user access to, go and check out the related ACL’s connected to that role.

This CAB Group consists of a select group of IT Managers that at times, is changing members because it’s an Active Directory group.

If you have the group in ServiceNow and you assign it a approval role, and the group is managed in Active Directory – then your job is done from a scalability perspective.

For example, to allocate the “approval_user” role to the “CAB Approval” group.

There should be an edit button here, as shown below.

Go ahead and start typing this into the Slush Bucket and find the correct role. Move the role from the left to the right side and Save the form.

At this point, you have taken a role and granted it to all of the group members.

This would specifically mean that at this time, all of the members are inheriting the approval role.

And if a user leaves that group, then they are no longer inheriting the role.

Roles are only granted to the users who are in the group that has the role.

So while this group exists in ServiceNow, you have properly set it up from an access perspective.