Previous post in the series: Update Sets

---

Groups and Roles

Groups and roles are how we manage access to things in ServiceNow. You should always add users to a group rather than granting a user an individual role. This makes user administration simple. From the same lens, you should always add roles to a group rather than granting roles to a user. This makes role administration simple.

Groups

Groups are basically a collection of users that share the same purpose. A few examples could include HR Specialists, or Payroll, or Sales. Each group has its specific function, and is ideally limited in access to only perform what it needs to. One group handles HR tickets, one group deals with payroll, and one group deals with selling.

In ServiceNow, groups are often assigned to tasks/cases. For instance, a HR Case `[sn_hr_core_case] record for a Leave Request may very well be assigned to the HR Specialist group to work on. The specialist is in charge of reviewing the case and making a decision.

Another example of a group that comes OOTB in ServiceNow is Catalog Request Approvers > $1000. If someone makes a request from the Service Catalog that has a total cost exceeding $1000, this group gets assigned to the request. By assigning these specific requests to a specific group, organizations can ensure they maintain checks and balances.

Groups within groups

Groups can have Parent groups and therefore they can also have children groups. For example, imagine you are a company that services the entire United States. You have a Sales division and have a Sales group. But maybe you sell both software and hardware, and so you have a need to further categorize salespeople into Hardware Sales and Software Sales groups. This is an excellent use case for the parent-child relationship; you can nest the Hardware Sales and Software Sales groups underneath the Sales group.

To put this example into something more real, let's take a look at the screenshot below:

We have our Sales group, which has a group manager (Honest Abe). At the bottom of the screenshot we can see a related list titled Groups and we can see the condition for those records is that the Parent = Sales. This is how we can see what groups are children of the Sales group.

If we check out one of the child groups, we can see the Parent group listed in the respective field:

In the screenshots above, we can also see related list tabs for Roles and Group Members. As we mentioned at the top of this post, groups are what we should be assigning roles to. If we assign a role to a group, anyone that is a group member inherits that role.

Importantly, the child groups also inherit the roles from the parent groups.

So if the Sales group has a role, the Hardware Sales and Software Sales groups will also get that role. In the screenshot below, we're looking at the Roles related list on the Software Sales group record, and we can tell that role is inherited based on the true value in the Inherits field. (Note: this is a random role I added for the sake of this example; also this was added after taking the earlier screenshots, which explains why you're not seeing Roles (1) in the earlier screenshot of Roles related lists.)

But group members are not inherited. So if you're part of the Sales group, you aren't also in the Software Sales group. And if you're the Manager of a group, you're not necessarily "in" the group either. The Manager field simply means you have access to modify the group record and some of its related records (e.g. group members).

Some relevant Group tables

• Groups [sys_user_group] is the highest-level table for groups
• Group Members [sys_user_grmember] is a many-to-many table that links a user to a group
• Group Roles [sys_group_has_role] is a many-to-many table that links roles to a group

Roles

A role is what gives you access to a table. Specifically, roles can give you C,R,U,D (Create, read, update, delete) access. The CRUD access is determined by configuration of Access Controls, which we won't be covering in depth in this post. For the purpose of this post, you just need to know that roles are what allow you to edit records, insert records, and/or delete records.

So we'll pick on the role we saw in the Sales group example above: dashboard_admin. This role, according to its definition on the role record, is intended for dashboard administrators, and grants access to manage all dashboard and dashboard groups. In other words, this role can crate, read, update, and delete dashboards and dashboard groups. (Remember, at the end of the day, dashboard records technically exist on a table. So this role can manage records on that table.)

You'll notice a few related lists on the role record:

• Contains Roles
• Applications with Role
• Modules with Role
• Custom Tables

We'll touch on these each in more detail below.

Roles within roles

Just like groups, roles can contain other roles. In the screenshot above, you can see that the dashboard_admin role contains the analytics_filter_admin role. This means that if you have dashboard_admin you also get analytics_filter_admin. Simple as that. This makes it easy to "group" roles together, so that

Applications

Applications are the containers for different functional areas of the platform. It's a bit tricky to explain, so I'll try to use an analogy: in a mall, there are multiple stores, which each have specific purposes. In this mall, you need a key to access each store. If you have the key, you can walk into the store and goof around. If you don't, sorry, but you're not gonna get let in.

If you think of the mall like a ServiceNow instance, and the store like an Application, you can deduce that you need a key (role) to get in. Certain applications in ServiceNow are limited to certain roles. We can prevent users from even seeing a store (application) when they look at the mall's directory (Filter Navigator) by restricting the visibility to certain roles. This will make more sense in the next section about Modules.

Modules

Modules are the links in the Filter Navigator. See this image for reference:

The links to Business Applications and Dashboards are both modules within the Application Menu Self-Service. We can restrict access to certain modules by role. In other words, if you don't have the role, you can't see the link. Same thing with the Application Menu -- we can restrict access to the Self-Service application menu by a role.

You can grant access to an entire application menu or just specific modules. If a user has access to see Dashboards, they don't necessarily have access to see Business Applications. Same thing with Self-Service -- if they have access to see Self-Service, that doesn't necessarily mean they can see all of the modules within it. Each module can be controlled individually.

If this is confusing, just focus on the fact that you can lock down modules with roles.

Custom tables

Not really sure what this is, and I haven't seen it populated for anything I've worked on. Looks like it has something to do with "subscribed users with role." Ignore it!

Roles with flows

Not to get too in-depth... but some flows in Flow Designer run as System User, while others run as Logged-in user. Basically, system user is a service account (not listed on the User [sys_user] table) that is not impacted by access controls. If your flow calls for a record to get created on a table that a logged-in user does not have access to create on, the flow will error out.

Some relevant Role tables

• Roles [sys_user_role] is the highest-level table for roles
• Contained Roles [sys_user_role_contains] tells you if a a role will be inherited by another role
• User Roles [sys_user_has_role] is a many-to-many table that links a user to a role

---

Next post in series: TBD! In the meantime, check out one of my more advanced posts.