The Role-Based Access Control (RBAC) settings were designed to accommodate specific scenarios involving nested groups of operators.
Let's view an example. Consider two groups:
- Group A, which includes User1 and User2
- Group B, nested within Group A, containing User3 and User4
When roles such as “Tenant Admin” are added to Group A, the initial setup is as follows:
- Group A, now defined as “Tenant Admin”, is created in our authentication system.
- Group B, also defined as “Tenant Admin”, is created in our authentication system.

These two groups, once created, only control direct users. This approach helps balance complexity. For instance, if you want to remove the “Tenant Admin” role from User1 and User2, you have two options:
- Act at the individual user level
- Remove the "Tenant Admin" role from Group A, which is more efficient when dealing with hundreds of users.
Although this seems like a simple structure, managing cases with 5-6 nested groups, potentially in a recursive manner (which is permissible on the Microsoft side), can be challenging. Hence, the design choice to keep it simple is a safeguard against these complex situations.
The initial setup starts from the top level (Group A), but any subsequent modifications are handled at the nested group level.
For instance, if you decide to modify the role for Group A users at a later stage, assigning them a “Management” role, this change will only impact User1 and User2. User3 and User4, who are part of the nested Group B, will remain unaffected by this change.

Conclusion
One of the main use cases of having CoreView groups operators is to utilize them within the CoreView workflow. This functionality allows you to automate the onboarding process of CoreView operators.
Once you add these groups, all the members within them will automatically become operators. This means they will have the ability to perform the tasks that are assigned to operators within your system.
Furthermore, these new operators will inherit the roles that have been granted to their respective groups. In other words, if a group has been given specific permissions or roles within your system, all operators from that group will automatically receive those same permissions or roles. This makes the process of assigning roles and permissions more efficient, as you don't have to do it individually for each operator.