I guess the topic roles is burning a lot of ressources to find the best constellation at the IT departments for the related departments by thinking about the best choose.
As we know there are a couple of modules existing, and at the same time are couple of risk existing by define wrong rules.
The same table I need to create also for Delete, Edit, Export, Import List, Mass Update and View rights.
My questions are:
makes it sense to work on a default table which depends from the business the end users are working? I think it would safe time during setup the roles because a lot businesses are similar.
First I need to define the “globale” role, which modules should be typically visible regardless of business?
last but not least, this anywhere such are thinking already existing to avoid also here a senseless waste of time?
I’m sure that could be helpful work for the community.
As I’m at the beginning I would be happy to find some experts in this regard.
Yes, I know it, but for me it is to “roughly”. More important for me are the individual business specific rights like Account, Delete, Edit, Export, Import List, Mass
For example it makes no sense for me that the owner has “all right”.
The admin should be have all right but not the owner.
My Idea is to have a business specific introduction into the roles topic with recommended default values.
BTW, any recommendation which modules are should be just for the admin purpose?
I hope my wish is not too perfectionist with my German roots.
Before CRM launch I need to know each smallest thing about the CRM world.
You better keep it simple at the beginning, because you won’t find much documentation on this. Not the kind that you’re asking for - high-level, philosophical, principled discussion of how it should be.
You just need to start playing with it, try and understand 3-tiered security well, because it’s complicated. I don’t fully understand it; I always struggle with it when I have to change something. But I can get things working with a more iterative, experimental approach.
Remember the level that everybody forgets: assigning specific records to security groups. That’s really where you know who-gets-what-access. Your table can’t possibly reflect that. You also need to understand the record-creation dynamic well, and the inheritance options for this.
The “assigned user” mechanism is important in SuiteCRM. It’s a great way to pass work around and assign responsibility. So probably your concept of “owner” also needs to evolve as you understand how you can use it to your advantage.
If it’s a big enough company, and you have some money for your project, I would advise getting a consultant to help.