User Roles are a mess, best practice guideline?

[Marcel H_]

First a little bit of background. My company originally had ServiceNow Business Edition (later to become Express) and the basic rule was if someone had the itil role, it consumed a license. Easy enough. We converted to Enterprise a bit over a year ago, and needless to say the roles are much more complicated. We are being told that we are now roughly 30 licenses over our current subscription due to so many people having "Fulfiller" roles in the system. The issue is though that we were still working off the premise that if the role wasn't "working" tickets in the system, it wasn't a fulfiller role.

We have created quite a few modules in the system for functions that don't exist OOB, and pretty much all of the roles being used to grant people access to these modules are being considered Fulfiller roles now. In addition I've been controlling access to various modules, lists, service catalog categories/items, etc. and many of those are also being considered Fulfillers as well. We also need to give some people/groups the ability to create their own reports, but even if they aren't normally fulfillers, apparently granting them the report_group role make them such.

Another issue that I'm seeing is that sometimes a user will have the same role duplicated on their user profile as many as 10x. Removing the duplicates is breaking their access, and there doesn't seem to be a way to actually determine which of the duplicated roles being applied are the one actually granting the access.

Overall what I am looking for is if there are best practices, clearly outlined for the following situations:

1. What is the best way to have nested groups (Parent/Child relationship) where roles are inherited, but sub groups might have different roles applied as well?
   1. Is it better to break inheritance in these cases? Does each of these roles applied to the child group get counted as a Fulfiller license if the data they are accessing are always in the same table/module?
   2. Does being a member of a group automatically make you a fulfiller?
   3. Does having access to READ records that are not your own (created by you) automatically make you a Fulfiller? We have several business cases in which groups of people need to SEE data, but will not interact with it, update it, etc.
2. If you have a manager that is overseeing several groups, that are spread across several modules/tables and they need access to see ALL the tickets related to his groups, do you need to create a special role, along with specific ACLs to allow that manager read only access instead of consuming several Fulfiller licenses?
   1. Again, in this case, if this manager is a member of several groups to control access, do we need to break inheritance of these groups and manage permissions manually? This could potentially become very manual labor intensive keeping track of the roles that a single person has or does not have.
3. How can modules, lists, records, etc. be hidden from view except for specific groups of people without that being seen as a fulfiller role? The items that they are viewing are only really going to be read, or in some cases it could be a Service Catalog items I don't want everyone to have access to, but the roles are being counted as fulfiller licenses when that isn't necessarily the case.
   1. I saw just today that there is User Criteria that can be used to define access to certain things like Service Catalog items, which is something I'll look into, but if I'm not mistaken this doesn't extend into lists of records, modules, tables, etc.
4. For our Technology department, we also have a role, "xxxxx_technology" that is being used to control views to show and hide various modules, but pretty much everyone also seems to have the "itil" role assigned as well (probably a holdover from ServiceNow Express honestly). The "xxxxx_technology" role contains the itil role, so does that mean anyone assigned the "xxxxx_technology" role is actually consuming 2 fulfiller licenses because they have both roles?
5. While I have gotten some feedback from our account rep, I would like some additional clarification on what will show up as a Fulfiller role on a compliance report:
   1. My impression is that if a role can create/write/delete on a table they are a Fulfiller. Is this always the case? Will roles that have read access to records in a table actually be excluded as not being a fulfiller?
   2. If a user is the member of a group that is placed in the "Assignment Group" field of a ticket form, does that automatically make them/their roles a Fulfiller? Information I received says "Yes - with some exceptions". What are those exceptions?
   3. Is being assigned any role at all going to consume a Fulfiller license? Again the information I received is "Yes, any role except a Requester role.", but that seems to potentially conflict with the idea that only create/write/delete roles count as fulfillers.

Overall I know that our Fulfiller license usage isn't very high, and my department Director doesn't want to potentially pay another $30k/yr for licenses that are not truly fulfiller licenses, but are more than happy to true up where necessary. Right now though it's hard to make heads or tails of our role situation. Any help, or guidance is greatly appreciated.

[Chuck Tomasi]

Hi Marcel,

Thanks for the information. Well done. This sounds like a conversation you really need to have with your ServiceNow account team as it involves licenses and best practices.

There are several best practices documented on the wiki here if that is of any interest. None about nest groups and applying to subgroups with different roles (to the best of my knowledge), but worth noting.

Reference:

ServiceNow Wiki: Technical Best Practices

[Marcel H_]

Thanks Chuck, I appreciate the link and the response. Just trying to make sure we're in compliance for our licenses, while being able to ensure that our users have access, even if read-only, to the data that they need to be successful. Expansion of user licensing is something that will likely happen as certain department's use of the platform mature, but certainly controlled addition of licenses is better than being surprised on a compliance report .

I'll keep looking through related articles to see if there are good way to accomplish what I need to do. I have a suspicion though that I'll be spending a lot of time in ACLs adjusting how the roles see/access things.

Do you happen to know, or have seen where roles are duplicated on a user's profile in a way where it shows that they are granted the role multiple times from a single group, as well as outside of a group (I assume direct assignment of a role)? Below is a screenshot where the boxes represent groups the user is a member of that are granting the role (same colored boxes are the same group), but as can be seen sometimes they are granted the same role multiple times even after removing all roles, removing them from all groups, saving the associated records and then re-adding them to the group.

Sometime removing the duplicates works just fine, other times it totally breaks their access to something. I can't seem to tell which "version" of the role is the one that is actually applying the role correctly.

[Chuck Tomasi · Accepted solution]

Hi Marcel,

It doesn't matter that a role is listed multiple times. If it was inherited, there's no harm. All of the information is normalized so don't worry about removing any duplicates, there's no need and like you said, it can possibly mess things up even more. For example, if a user has itil either directly, from a group, or inherited from another role, they have itil - period.

[Marcel H_]

That's great to know, thanks Chuck! I guess it's my OCD side that wants everything to only be listed once, and the count of roles to be very much a 1:1, but right now as long as that's normal and it works, I'll take it.

I'll just work out via ACLs what roles have access to what and try to streamline the inheritance in various nested groups (or maybe just not use parent/child relationships for them). It's a bit of an undertaking, but I'll tackle it a bit more over time.