User groups is a concept whereby users can be grouped together and permissions and contract access assigned. This removes the need to manage permissions / access at a user level, significantly reducing the maintenance overhead around user administration.
In CLMA there are a few additional user groups that control access to certain features. The following user groups fall into this category:
- CLMA Admin - gives administrator privileges as well as access to administrator functionality
- CLMA Model Admin - gives access to the Model Manager feature
- CLMA Search Admin - gives access to the Search Model feature
- Activity Managers - gives access to the workflow engine (APS)
- Activity Managers Initiators - gives permission to use workflow functionality
- Compliance Managers - gives access to the Compliance Manager feature
- Entity Users - gives access to the Entity Manager feature
- Entity Managers - gives permission to add/maintain entity data in Entity Manager
- Entity Managers Delete - gives permission to delete entities in Entity Manager
- Search Users - gives access to the Contracts (i.e. Search) feature
- MassAction Users - gives access to the Mass Actions feature
The design of the user groups will be dependent on the Roles and Access segregation requirements. In addition, further sub groups can be created if required (e.g. a smaller subset of users should receive alerts for expiring contracts, etc).
The best practice design is to use the following 4-tier structure:
> License groups
> > Roles groups (if different from license roles) - used to specify what the users can ‘do’
> > > Access Segregation groups (e.g. region / department, etc.) - used to specify what the users can ‘access’
> > > > Further groupings if required
The following diagram presents a basic example of this design:
- Nested groups will inherit permissions/access from the parent group. The one exception is the ‘Activity Managers’ and 'Activity Managers Initiators’ group. For users to get access to the feature, they need to be directly added to one or both of these groups.
- It is easy to see which groups are a member of a specific group, and follow this flow “downstream”. What is not easy is the reverse. You cannot navigate to a group and follow this “upstream”. Having a clearly defined structure to your group design will help a lot with diagnosing why a user has/hasn’t got permissions/access to something, as it makes it easier to determine which groups to review and look “downstream” to identify whether the user is nested somewhere in that group.
Things to avoid
- Although it is possible to nest the same group under multiple parent groups, try to avoid this. From a maintenance perspective it becomes very confusing very quickly to determine how the permissions/access flows. (If you can’t draw it like the diagram above, it is too complex.)
- Avoid circular logic i.e. making group A a member of group B and group B a member of A