New group of operators

CoreView allows you to add operators by utilizing either “Distribution groups” or “Security groups”. This is achieved through the “New group operators” option. Please, follow the steps below to create a new group of operators. 

Step 1

Select “New group operators” at the top right of the page.

Step 2

Now, a new panel will appear. Here, start writing the name of the group (one among the distribution or security group) you wish to assign roles to (assigning them in bulk to all users in that group) and choose it from the drop-down menu. In the example below, the “Security group” “SSPRSecutiryGroupUsers” has been selected:

Step 3

Now, assign the desired roles. 

Step 4

 Click “Save” to finalize your operation. The new group of operators is now created. 

How RBAC settings are applied to nested groups

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:

1. Act at the individual user level
2. 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.