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:
- Manually delete and re-create each sharing rule by hand in the browser, or
- Programmatically delete and re-create the sharing rules in bulk
- 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:
- Exporting all the sharing rules metadata as xml
- Constructing a destructiveChanges.xml file to delete all the sharing rules
- Updating the exported xml metadata files with the correct “share with” roles
- 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
- Go to Setup | Develop | Tools
- Download “Force.com Migration Tool” zip file and unzip the folder on your computer
- Read the Readme.html file to setup the pre-requisites (Java, Ant, etc.)
- In the “sample” folder, update the build.properties file per the Readme.html
- 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>
- Open a command console to the “sample” folder and run the build command: ant retrieveUnpackaged
- Make a new folder “sample/destructive”
- 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>
- 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>
- 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>
- 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 - 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.
- Open a command console to the “sample” folder and run the build command: ant deployUnpackaged
- Congratulations, you’ve re-created your sharing rules to NOT share with Portal Roles!
Hi Doug! I am wondering if you can deploy External Sharing model through ANT? I have tried and have been unsuccessful, but I am unsure if I selected the correct Metadata type.
LikeLiked by 1 person
Hi Holly,
There may be a much simpler way to do this than my original post of using ant. If you’re setting up a Community then navigate to Setup | Communities | Communities Settings. On that page scroll down to section “Sharing Tools” and click on “Convert Community Member Access”. That will walk you through converting existing sharing rules and report folder sharing to remove any unintentional sharing to external roles.
https://login.salesforce.com/_ui/networks/setup/NetworkSettingsPage?setupid=NetworkSettings
https://login.salesforce.com/ui/setup/portal/RoleConversionWizardSplashPage?setupid=NetworkSettings
Hope that helps!
Doug
LikeLike
Hi Doug,
Thank you for the information. Yes that does help! But I am wondering if I have to physically click the button âEnable External Sharing Modelâ rather than deploy the change through ANT. Would you happen to know?
Holly
LikeLiked by 1 person
My guess is that you have to enable External Sharing first before there would be the new partner roles available, or at least have a single community enabled. To test it out you can create a free dev org and play in there without affecting your production or sandbox environments.
https://developer.salesforce.com/signup?d=70130000000td6N
LikeLike
Nicely explained Doug 🙂
LikeLiked by 1 person
Thanks Atul!
LikeLike
Don’t you think what SFDC has done is 100% correct when enabling External Sharing? The current implementation before the change is that all users, internal and external have access to records in the system based on the sharing rules created. When you enable it, in order to not break expected behavior, all sharing rules have the least restrictive selection, sharing with Roles and Internal/Portal Subordinates? To do anything else would cause existing sharing rules to operate differently than originally intended.
LikeLiked by 1 person
Hi Tyler,
I don’t believe there is a right or wrong answer here because each company may view how they want the default external sharing to be differently. Some may expect the external sharing to be as open as their internal sharing where others don’t.
At the time of this post, there was no (or I was unaware of) any option to automatically switch our sharing rules to be more restrictive in external sharing (which the company I was at wanted external sharing to be much more locked down than internal) so we had to re-create the rules.
Personally, I think erring on the side of caution when potentially exposing data to external community of non-employees should be taken. When working as a consultant, I had a few clients that I got called in to fix their community sharing because they learned that their original sharing rules were too lax and were letting their customers see each other’s data like invoices and orders.
I highly encourage anyone adopting communities or enabling external sharing to thoroughly research and understand the sharing impacts to community users.
The free research and study guide for the Sharing and Visibility Designer architect certification exam are good starts.
LikeLike
Hi Doug, very informative article.
I have query regarding Role Hierarchy. When the portal user is created, its role reports to Role of the Contact creator. Is there any way to change it?
E.g. User A has created contact 1 for Account 1. By default, the portal role reports to Role of User A. User B shares the same role as User A, therefore he can view the same data as User A, which is not relevant to him.
How can I stop it?
Thanks for your help.
Kind Regards,
Renu
LikeLike