External Sharing Model Considerations

When preparing to rollout a Customer or Partner Community, or anytime making a change that would allow external users to access your org, you should carefully review your sharing settings to ensure people have the correct access to data. For a quick refresher on Salesforce record access, please check out this “Who Sees What” video series.

At the time of this writing, I’m configuring our first Partner Community. As I would imagine with most companies, we don’t want partners seeing each other’s data which may include orders, cases, and other account data. So I started reading up on my options for restricting data access for external partners while also preserving the openness we have with our internal employees. This is where External Sharing Model comes in to play.

What is External Sharing Model?

External Sharing Model allows you to define different organization-wide defaults and sharing rules for internal and external users. Perfect! This means you can have one set of sharing settings for your employees and a different set of sharing settings, usually more restrictive, for your partners and customers whom you allow login access to your org. For example, our sales reps should have public read access to accounts, but our partners should only have private access to the accounts we explicitly share to them.

From the Salesforce help docs, external users are more formally defined by their license type:

• Authenticated website users
• Chatter external users
• Community users
• Customer Portal users
• Guest users
• High-Volume portal users
• Partner Portal users
• Service Cloud Portal users

Partner Roles

In my sandbox, when I created my first partner account and partner contact/user, I noticed this also created a new user role with same name as the account (e.g. AW Computing Partner User) and which reported to the role of the account owner (e.g. SVP, Sales & Marketing). Interesting.

Also worth noting, this now introduced new role options for use in sharing rules. Instead of the two original options of “Share with Roles” and “Share with Roles and Subordinates” the new options included:

• Share with Portal Roles
• Share with Portal Roles and Subordinates
• Share with Roles
• Share with Roles and Internal Subordinates
• Share with Roles, Internal and Portal Subordinates

I knew I wanted my more “open” sharing rules to only be for internal employees so they should share with Roles and Internal Subordinates and not with the Portal Roles or Portal Subordinates.

Unfortunately, once I enabled External Sharing Model, Salesforce by default changed all sharing rules using the original option “Share with Roles and Subordinates” to be “Share with Roles, Internal, and Portal Subordinates”.

Do you see the problem here?

By default, once I enabled external sharing then all my sharing rules now share with external users. Yikes! I would have expected Salesforce to err on the side of caution and have mapped to “Share with Roles and Internal Subordinates” but they didn’t. So I now have a crisis opportunity to review my existing sharing rules and modify them to meet my new requirements. Unfortunately, I have dozens of pre-existing sharing rules that now must be corrected, and doubly unfortunate is that the “share with” property of a sharing rule cannot be edited. Doh!

Dealing with Side-Effects of Enabling External Sharing Model

I’m aware of three options at this point, I can either:

1. Manually delete and re-create each sharing rule by hand in the browser, or
2. Programmatically delete and re-create the sharing rules in bulk
3. Use the Convert External User Access Wizard in the Setup | Communities | Communities Settings

.

If using the Wizard (#3) above does not suffice then here are the steps to mass change the sharing rules (#2) using the Force.com Migration Tool which is a Java/Ant-based utility for easily making bulk changes to metadata.

The solution involves:

1. Exporting all the sharing rules metadata as xml
2. Constructing a destructiveChanges.xml file to delete all the sharing rules
3. Updating the exported xml metadata files with the correct “share with” roles
4. Deploying the newly revised sharing rules to Salesforce

.

Due to the re-calculation time Salesforce needs to compute the sharing changes, I recommend performing this update during non-peak hours. People may suddenly lose access to records and see “Insufficient Privileges” errors if they try to use the system while the sharing rules are being re-created. As the administrator performing these changes, you’ll receive an email notification once processing has completed. Depending on the amount of data in your org and number of sharing rules, this processing time may take a few seconds to a couple minutes.

Re-Creating Sharing Rules with Force.com Migration Tool

1. Go to Setup | Develop | Tools
2. Download “Force.com Migration Tool” zip file and unzip the folder on your computer
3. Read the Readme.html file to setup the pre-requisites (Java, Ant, etc.)
4. In the “sample” folder, update the build.properties file per the Readme.html
5. In the “sample/unpackaged” folder, replace the provided package.xml contents as below per metadata api:

   <?xml version="1.0" encoding="UTF-8"?>
   <Package xmlns="http://soap.sforce.com/2006/04/metadata">
     <types>
       <members>Account.*</members>
       <name>SharingCriteriaRule</name>
     </types>
     <types>
       <members>Account.*</members>
       <name>SharingOwnerRule</name>
     </types>
     <version>33.0</version>
   </Package>

6. Open a command console to the “sample” folder and run the build command: ant retrieveUnpackaged
7. Make a new folder “sample/destructive”
8. In the “destructive” folder, create another package.xml but without <types> as below.

   <?xml version="1.0" encoding="UTF-8"?>
   <Package xmlns="http://soap.sforce.com/2006/04/metadata">
     <version>33.0</version>
   </Package>

9. In the “destructive” folder, create a destructiveChanges.xml that explicitly lists the sharing rules to delete (wildcards are not supported when deleting metadata). In the below, replace the values of the <members> tags with the appropriate <FullName> values from the retrieved sharing rule metadata xml from step 6. The syntax is just like package.xml:

   <?xml version="1.0" encoding="UTF-8"?>
   <Package xmlns="http://soap.sforce.com/2006/04/metadata">
     <types>
       <members>Account.My_Criteria_Rule_1</members>
       <members>Account.My_Criteria_Rule_2</members>
       ...
       <members>Account.My_Criteria_Rule_N</members>
       <name>SharingCriteriaRule</name>
     </types>
     <types>
       <members>Account.My_Owner_Rule_1</members>
       <members>Account.My_Owner_Rule_2</members>
       ...
       <members>Account.My_Owner_Rule_N</members>
       <name>SharingOwnerRule</name>
     </types>
     <version>33.0</version>
   </Package>

10. In the “sample” folder, edit the build.xml by copying lines about 40-42, the “deployUnpackaged” target, and paste them as another target in the file. Name this target “destructive” and change the deployRoot attribute of its <sf:deploy> tag to be deployRoot=”destructive”.

    <target name="destructive">
      <sf:deploy
        username="${sf.username}"
        password="${sf.password}"
        serverurl="${sf.serverurl}"
        maxPoll="${sf.maxPoll}"
        deployRoot="destructive"
        rollbackOnError="true"/>
    </target>

11. Open a command console to the “sample” folder and run the build command: ant destructive
    Warning: This will DELETE all metadata specified in destructiveChanges.xml
12. Now that the old sharing rules are deleted from Salesforce, we need to update the metadata xml from step 6 in the “sample/unpackaged/sharingRules” folder and replace all <roleAndSubordinates> tags to be <roleAndSubordinatesInternal> tags.
13. Open a command console to the “sample” folder and run the build command: ant deployUnpackaged
14. Congratulations, you’ve re-created your sharing rules to NOT share with Portal Roles!