How it works...

We started by creating a base role that gives users basic access to the platform. The base role, for example, gives users read access to business units, entities' schema, SDK messages, system forms, and so on. This role by itself does not give you access to anything else in the system, just blank access.

We then created a role to read accounts and contacts and finished off by creating a role that gives full write access to the accounts and contacts. Note how we left off Assign and Share, as these are special privileges that can be forked into their own security role.

The union of all three roles will give a user all privileges required to access the system and read/write to accounts and contacts:

We provided the privileges at a Parent: Child Business Units level. However, this can be done at any other level depending on your requirements. Refer to the introduction of this chapter to understand the different levels and some of their respective scenarios.

We assigned all the security roles to the root business unit. Roles created at a parent business unit level are inherited by all children business units.
Furthermore, to package security roles in a solution, they have to be defined at the root business unit level. As a rule of thumb, it's always best practice to define security roles at the topmost business unit.
..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.118.20.68