Group Membership Operations and Sharing Recalculation

The Salesforce Role Hierarchy, Public Groups, and Territories are closely connected to sharing rules and the special security features of Salesforce applications. Because of these relationships, seemingly simple changes to groups and group membership can sometimes involve substantial recalculations of users’ access rights.

For example, when an administrator moves a user from one branch of the hierarchy to another, Salesforce performs all of the following actions to ensure that other users have correct access to data owned by that relocated user.

• If the user:
  • Is the first member in his or her new role to own any data, Salesforce adds or removes access to the user’s data for people who are above the user’s new or old role in the hierarchy.
  • Has a new role with different settings for accessing contacts, cases, and opportunities, Salesforce does the following to reflect the change in settings.
    • Adds shares to those child objects where the new settings are more permissive
    • Removes existing shares where the new settings are more restrictive
  • Owns any accounts that have been enabled for either the Customer or Partner portals, Salesforce removes any child portal roles from the user’s original role and adds them as children to the user’s new role.
    • Salesforce also adjusts boss-implicit shares, which provide access in the hierarchy to records owned by or shared to portal users. See Implicit Sharing.
    • Salesforce must perform these tasks for every portal-enabled account the user owns.

    Note

• Salesforce also recalculates all sharing rules that include the user’s old or new role in the source group. It removes all of the user’s records from the scope of sharing rules where the old role is the source group and adds those records to the scope of rules where the new role is the source. Depending on the sharing rule settings for accounts, Salesforce might also add or remove shares to account child records.

  If the user owns portal accounts, and there are sharing rules that use portal roles as the source group, Salesforce might need to recalculate those rules. Some sharing rules might no longer be valid given the user’s new location in the hierarchy, in which case an administrator might need to modify or delete them.

  Note

During the user’s move, the managers in the branch above the user’s old role lose access to all the data that the user owns, as well as to child records shared through the managers’ role settings. Managers in the branch above the user’s new role will gain access to the user’s accounts and to child records according to their own role settings.