2 of 2 people found this helpful
Whilst you can privilege on both Groups and Roles it is easy to create a confusing structure of effective priviledging if you are not careful given effective privileges are cumulative acrossall Groups and Roles the user is a member of.
My advise is to ONLY privileges to Roles unless your design is such that you can only do on Groups for some features, but even then still do sparingly in Groups!
I like to think of groups and roles as:
- Groups - define your position in the company organisation structure
- Roles - define what you are allowed to do (privileges) in your job.
Furthermore as privileges are layered I like to create a “base” role for each user types that gives the basic privileges to log into the UI and raise lifecycles or view core data and then create additional roles to layer on additional rights.
So for end users I’d have a base role of “Self Service User” and base privilege this. For most end users that will be all they need and I usually set all new users imported from AD to automatically get this. Some end users might be managers as well so these users would have addition “End User Manager” role we can give just thae additional privileges to; ie authorisation actions etc.
For Analysts I’d have a base role of “Analyst” and then layer on additional roles for users that need extra privileges ie Change Manager, IT Manager, Knowledge Content Approver, Problem Manager etc.
One final thing to stress, privileges are cumulative across all roles so in this model the base role is the place to set the broadbrush 99% of the privileges and the other layered roles (Change Manager etc) just need the extra 1% between them.
Hope this helps
1 of 1 people found this helpful
I should also add that I’ve also seen some “schools of thought” around everybody, that’s Analysts and End Users alike, all sharing a common base role of say “Self Service User” as it is a fair point that everyone needs to be able to access the main application and be able to raise an Incident or Request for themselves, right!
So as an end user you are a member of this role only (managers excepted) but if an Analyst then you have this role plus another role at least (say “Analyst”) that gives you additional privileges to raise Incident and Requests and progress to completion for other users as well.
It all depends on how much you want to layer the privileges. Personally I used to be a fan on this method but moved over to the separate base roles for each user type being self supporting purely as it means that for many Analyst you only need to give them one role to do their job, so more simple to administrate IMHO.
In my designs i have a trigger that automatically adds Analysts and End Users to the system and also adds base Group and Roles, sets network login, sets non blank password and if Analyst sets their starting license type. Yes of course for Analysts you still need to add more Groups and Roles but otherwise for both user types they are ready to go as soon as they are imported; at least for basic access.
This is exactly what I have analyst and end user with self service and this configuration has caused some issues for me and specially with the confusing privileges given to managers of sections groups and head of departments groups... Actually all of these different groups and roles make it complicated and difficult to manage so I will check with our vendor and see if we can make it simpler by doing it based on a separate roles.
No problem; happy to help if I can.