Vertical Sharing
In Part 1 we explored the security roles and how they impact access to the objects or entities. Now we are going to examine record-level rather than object-level access.
To review, recall that Dynamics CRM’s security roles intermingle record and entity level access whereas there is a clear separation of concerns with Salesforce user profiles. Having made this distinction, Salesforce introduces a base level of security that impacts object and record access simultaneously albeit in a different manner than Dynamics CRM.
Organization-Wide Defaults
Each object in Salesforce must be assigned an organization-wide default which sets minimum access privileges. The choices for most objects are straightforward: read/write, read only and private.
Both platforms operate on the same principle, and a very important one indeed: access can never be taken away. It can only be granted.
In contrast to Dynamics CRM, where access rights are granted primarily within each security role, Salesforce grants these at a global level irrespective of the user profile. This will result in a paradigm shift for Dynamics CRM administrators. If an object is given an organization-wide default of Public Read/Write the concept of sharing does not exist.
Huh? Well, think about it. If the MINIMUM access for everyone is read/write, then everyone can read and write every record and sharing is superfluous.
In the above figure note that several objects have the access of public read only. This means that everyone can see every record. However, no user (other than administrators with global access) can edit a record unless she owns it. This concept is of course consistent across both platforms.
Allowing Greater Access
We learned in the previous post that default access for an operation in Dynamics CRM (editing, for example) can be limited to the user, anyone in the user’s business unit, anyone in a higher business unit that contains the one in question (such as a manager) and finally the entire organization.
This is where things get quite confusing. Although Salesforce has similar sharing defaults the terminology is different and unlike Dynamics CRM the settings are not in one area.
The following table is a rough comparison of the generic access levels for editing assuming that the organization wide default for the object in Salesforce is set to public read only and every user profile has edit rights for the object (not the record).
Business Units and Role Hierarchies
These are fairly similar with some caveats. A Dynamics CRM business unit is a required assignment for teams, users and security roles. In other words, each of these must be associated with a business unit.
Business units and roles are hierarchical. Each can have children, and those children can have children, just as with any tree structure.
Roles in Salesforce also have associated users. However, security profiles are assigned to the user, not the role hierarchy.
A full understanding of Business Units and Roles is well beyond the scope of a simple blog post. Regardless, thorough knowledge of this topic is critical particularly in reference to Dynamics CRM if you are a Salesforce administrator.
In Salesforce the lack of connection between roles and profiles makes it easy to change the configuration later in a project. Dynamics CRM makes inherited duplicates of security roles each time a new business unit is created and the tight connection between the two makes alterations more complex.