Expanding the Sharing Model
In Security Part 3 of this series we looked at collaboration at the entity and object record level. Assuming that there is some degree of editing or viewing restriction a record owner can designate a unique group of users additional rights pertaining to that record. This type of sharing works extraordinarily well with users at the same level such as sales representatives. Considering that there is fierce competition among representatives, it is critical that access to potential and current clients is “by invitation only.” In this paradigm the invitation is on a case-by-case basis.
Both Salesforce and Dynamics promote hierarchical access through Roles and Business Units, respectively. Put simply, this means that a Vice President may have access to all records available to managers under her and each manager may have access to all sales representatives under him. This mode of sharing starts to break down when users with different roles or in different parts of the hierarchical tree require access to a specific group of records.
In order to circumvent the role and business unit restrictions we employ Owner Teams and Public Groups/Sharing Rules. For our example we have a company with two divisions. Each division has a single VP and multiple managers under the VP. Each manager is in charge of multiple sales representatives.
In this scenario Manager B is often traveling and needs someone to assist her sales representatives when she is out of the office. Manager A, while he is in a different division, handles similar types of accounts and is able to easily fill in when needed. The triangle represents a business unit in Dynamics and a role and subordinates in Salesforce. Both managers have access to all accounts owned by the sales representatives they manage but nothing beyond that. Even the VP’s in each division can only access accounts in their own divisions. Only the CEO has global access.
Our task is to provide manager A with access to all accounts to which manager B has access.
Owner teams are one way to achieve this goal. In the above figure there are two divisions, East and West. Each division has two regions. Assume that there are business units for each as outlined below:
The logic to make this work is straightforward. Teams are similar to users in that they can be given security roles. All we need to do is to create a team under Manager B’s region (Region 1 West), give the team the appropriate security role, assign Manager A to that team, and we are done.
Instead of creating one team, we will need to create two public groups and link them with a sharing rule. Personally, this is a little less intuitive but as we will see it affords some extra flexibility.
According to Salesforce documentation, “a public group is a collection of individual users, other groups, individual roles, and/or roles with their subordinates that all have a function in common.” The first group consists of all of the sales representatives who report to Manager B. The second group, similar to the Dynamics Team we created, has a single member, Manager A.
The next step is to define the sharing rule. It specifies which records are shared (in this case by owner) and what group to share these records with:
Both platforms offer considerable flexibility with respect to custom sharing scenarios. Salesforce has an additional out-of-the-box option that adds more granular functionality. Note in the above figure the options in Step 2. For our example we used the “record owner” rule type. We could have used the “based on criteria” rule type instead.
Using criteria it is possible to, for example, share only those opportunities that are in a certain stage. Note that you cannot simultaneously share based on owner and criteria. However, it is possible to add custom fields that are populated with owner and/or manager information and filter on those using criteria-based sharing.