Best practice for setting up ACLs and groups architecture

[jency83]

Hi guys, 

I am wondering what is your experience building a good ACL and groups architecture in a ServiceNow instance.

I have seen a few but they always comes with some comproimses. I am checking if anyone found an ideal solution. What I have seen so far

1. Simply having groups with roles assigned, then simply add users to groups

- Looks the easiest way but with many groups, it may get too complex and confusing for end user

1a. Link groups in parent/child relationship and assign roles properly

- Might be a bit better, but there can be exceptions adding again quite a lot of complexity

2. "Organizational" and "Permission" groups

- Assign various groups, one grants people membershing in assignment group, another one grants them a role

- This looks scalable, but you may need to request multiple group membership which is not much user friendly

Eventually I found an article by @SaschaWildgrube about personas. 4k+ views but not a single comment below. Is anyone using similar approach? I kinda like it. 

What is your experience?

[Dr Atul G- LNG]

Agreed. I'm currently supporting a large U.S. client, and they also have many groups. We still follow the same method, which works well. You can use the same approach, but make sure proper governance is in place.

Here are some best practices to follow:

1. Naming Conventions: Ensure each type of group follows a clear and consistent naming convention. This helps with identification and management.

2. Group Type Field: Use the group type field to categorize groups. This makes it easier to filter and manage access requests specific to certain types.

3. Request Visibility: Set visibility so only the required groups show up in access requests.

4. Group Ownership: Every group should have a designated manager. This supports accountability and streamlines approval workflows.

5. Governance Structure: All of the above should be enforced through a governance framework to ensure scalability and control.

This approach ensures that access management remains organized and efficient as the number of groups grows.

[Adam43]

We follow similar- putting roles in groups then users in those groups.  We use 'type' to further organize- we created "assignment" as a type, for groups that need to show up on 'assignment group' fields across the platform.  Also have "permission" for application based personas (we've grown from just ITSM- adding lots of GRC, SPM, and a few others).  Some groups are managed by automation (fulfillment group adds their user on a related record in application- a BR adds them to relevant groups).  Specifically- 'assignment' groups we built a catalog item for that type to be managed in portal with approvals, because it corresponds directly to real world awareness- group manager knows he's got people coming in to work tickets in certain assignment groups.  Permission groups- we're still struggling with- we don't want a custom catalog item for every permission group.  The personas aren't always well thought-out- often we get product owners who just "want that role" they found online.  Rather than documenting a process and understanding what a role really does OOTB- we get pushed into creating a group with a role, just to be able to apply that role.  IMHO- user persona design would get you bunching together multiple roles based on the user behaviour and product design.  Our Assignment group type is a clear persona- ticket fulfillers on agency teams.  But application permission groups are not that simple (thinking SPM/Project/Demand etc.- heavily customized; and GRC groups for IRM/BCM etc).

We've been pushing "persona" development for a long time- but it's a hard road with every process owner.  Last year- when license renewal rolled around- lots of them suddenly got a wake up notice because their licenses were over-applied and now their trying to have better control- but it's far easier to keep that stuff in mind when they roll out the product, and design personas accordingly to actual user behaviours and license/subscription factors.

I'd love to hear how you manage membership in groups- do you use catalog items, a direct ticket to your platform team, something else?

[TejasSN_LogicX]

The simplest way is to assign roles directly to groups and add users, but this quickly becomes messy as the system grows. Separating groups into “organizational” (who you are/where you work) and “permission” (what you can do) is more scalable but less user-friendly since users may need multiple groups.

The cleanest model is personas: each persona represents a job function (e.g., Service Desk Agent, HR Partner) and automatically maps to the right roles and groups. Users just request a persona, and the complexity stays hidden.

For ACLs, always base them on roles, not groups, and only use scripts when absolutely needed. Personas and roles make the setup easier to manage, scale, and explain.