We have four user roles: Admin, Manager, Supervisor, and Agent.
Discussion posts and replies are publicly visible
TL:DR - Don't only have role titles controlling security, also have the function within the application.
Although there are many ways to approach security and there is a pragmatic element (ie. If you only need all users and admins then don't make more than you need) I tend to gravitate toward naming my groups after functions in the applications rather than role titles. For example, if you have and approval process you may have Submitters, Approvers and Reviewers (and of course Administrators are fairly standard) and I find this makes the security discussion a whole lot easier and better facilitates more complex security structures.
The way you are approaching it is in a nested sense where higher roles automatically get everything the lower roles can have. But you might not want this. Going back to the example, it's easier to say that Agents need access to Submit approvals, Supervisors and Managers need access to Approve and Review submissions and another role (maybe a Personal Assistant or certain reporting functions) need access to Review approvals.
You still have the appropriate groups named after the roles titles but that's more associated with the users and not the applications. Within the apps you then have your functions and you add the appropriate groups of people. Again, there is a need for pragmatism where you will tend to bundle functions together into appropriate groupings but there will often be clear app functions that stand out.
One (very simplified) example:
Let's say you have a loan process within a bank and regional managers have the final approval for loans over $500k so you create a group called LOANS_RegionalManagers and give them access. This group is used in a lot of objects. Then it's later brought in that state managers can also complete this function in the application. What do you do? You could just make state mangers go into the regional managers group but that introduces a lot of risk and potential for incidents in future with people having access to things they shouldn't. You could make a LOANS_StateManagers group and put it everywhere the regional managers group is but this is a lot of work and could very easily be missed somewhere causing errors.
If you had a LOANS_HighValueApprovers group though, you could have within that the USERS_RegionalManagers and just add the USERS_StateManagers group and you're done.
So have a think about your app and what the appropriate groupings of functions could be and name them on what the function does rather than who does it. Then it's easy to just add the groups representing the who to what they need to be able to do.
If in future you come across the situation you need to split it out in a more granular way then you make the new functional groups and again add who needs to be able to do them. It also makes it A LOT clearer what can be done by groups or users in an app. Going back to the example if your group is just LOANS_RegionalManagers it's very hard to answer "What does the regional manager do in this application?" without digging into the documentation (especially if the user is a state manager!). Whereas if you see a user is in the LOANS_HighValueApprovers group and the group has a useful description then you're much better placed to know what's happening.
this helps alot, thank you