Identifying your record access requirements is an essential step that you should do before procuring user licenses or setting up your community for the following reasons:
1) Sharing options in Communities are affected by the type of Community user licenses you have (Customer or Partner)
2) Even with the more robust Partner license, there are still some “gotchas” when it comes to sharing in a Community
3) You may end up needing to adjust internal sharing settings so you don’t inadvertently grant Community users access to the wrong records.
License Types
Before you say to yourself, “My Community users are my customers–I need Customer licenses”, dig a little deeper. Salesforce has a great chart here that compares features for Customer vs. Partner Community licenses. In a nutshell, Customer licenses are designed for high-volume applications without complex sharing requirements. Partner licenses have access to more object types. For example, if you need your Community users to access Leads, Opportunities, Campaigns, or to upload Content, you will need Partner licenses. The other important note is that Partner license has roles and sharing rules available but basic Customer license does not. Likewise, Apex sharing and manual sharing are not available for Customer license.
Important Update: In addition to the above options, Salesforce has now made Customer Plus license available, which grants the following permissions on top of Customer: full access to Accounts, view access to Content, ability to create Tasks, view access to Reports and Dashboards, AND role-based sharing. This new license is a helpful middle-road option that will grant much-needed additional flexibility to most applications that are more complex than basic customer support. The main distinction of Partner Community license is access to the “premium” standard objects Lead, Campaign, and Opportunity.
Sharing with Customer License: Sharing Sets
The option you do have available for sharing records with users with lowly Customer license is called Sharing Sets. These essentially allow you to grant a user access to records based on affiliation with the user’s contact or account (or a contact or account related indirectly to the user through lookup relationships.) If the user’s account or contact record is populated in a lookup on the record, you can share it. To edit sharing sets, go to Settings under the Communities menu. Note that you specify profiles the sharing set applies to since Customer users don’t have roles.
Use Case: you want to share cases created on behalf on a Community user by internal users (where the Community user is the contact on the case) with that user.
Sharing with Customer License: Share Groups
Sharing sets are geared towards sharing records owned by other users with Community users. Share Groups, on the other hand, allow you to go the other direction and share records owned by Community users with other users. You can use share groups to share records owned by an external user (with a Customer Community or High-Volume Customer Portal License) with internal users, partner users, or other high-volume external users in the same account. To create a Sharing Group, you must first create a Sharing Set, then click into its name to access the Sharing Group sub-tab. Use Case: you want to share cases or another type of record created and owned by Community users with internal users or other external users in their account (the account restriction applies to high-volume external users only.)
Sharing with Partner License: Role Hierarchy
Partner users will see records owned by partner users in roles below them in the hierarchy. Each partner account may have up to 3 roles (Executive, Manager, and User). Using record ownership and the role hierarchy is the simplest way to share records among Partner users in the same account.
Use Case: you have a need for granular owner-based sharing where some Partner users should only see records they create, while others should see records created by others below them in their account.
Sharing with Partner/Customer Plus License: Super User Access
Partner users with super user permission can access records belonging to users in their account at their same role or lower in the role hierarchy, for Cases, Leads, Opportunities and Custom Objects only.
Use Case: you’re using Partner license and want to grant access to all records for the account to certain users and are fine with it opening up visibility to all the above objects. This also must be enabled in the Community settings and then manually enabled for each partner contact. For Customer Plus users, the super user permission can be granted via a permission set.
Sharing with Partner License: Sharing Rules
Owner and criteria-based sharing rules apply and can be used to share records with Partner Community users. To create rules that specifically apply to partner users, you can use partner roles and public groups. Partner users can be added to public groups just like internal users.
Use Case: you need to share all opportunities related to a particular partner account with all users in the partner account, but don’t want to open up the full super user access. You could create a criteria-based sharing rule where the Account ID is the partner account, sharing with the partner account executive role and subordinates. This works best if you work with only a small number of partner accounts, because it is a bit labor-intensive and will eat into your limit of 50 criteria-based sharing rules.
Sharing with Partner License: Manual Sharing
Manual sharing can be used for sporadic or one-off requirements to share records with partner users. Records can only be shared by internal users to partner users–partner users can’t manually share records with other users.
Use Case: Partners work closely with your internal users on only a few opportunities.
Sharing with Partner License: Apex Sharing
If your sharing criteria are more complex than criteria based sharing allows, or you work with enough partner organizations that you are in danger of hitting criteria-based sharing rule limits and/or managing them is an administrative burden, you may need to look into programmatic Apex-managed sharing. This can be complex to implement and should only be considered after other options have been ruled out. A related approach is to create a custom User interface with Visualforce that displays only selected records.
Use Case: you want to share only program records associated with the brand that a partner organization works with, the relationship is not tracked in an account lookup, and you don’t want to have to manually set up and maintain public groups.
Recommended Additional Reading: Getting Started With Salesforce Communities
Caitlin Marshall 
Best explanation ever, this is the only one where sharing options for partner and customer communities are clarified side by side, or in this case top to bottom, and with use cases.
Thanks for your feedback!
I have a partner community and a related org. I need to share records created by a partner user with a role present in org. Is it possible to relate the partner community roles with roles present in the org?
Yes. You can do this via sharing rules based on specific partner role, or you can add partner users to public groups just like regular users for more flexibility. There is also an available “All Partner Users” public group if you just want to share all partner-owned records, for example.
Good post, I have referenced several times during setting up our Customer Community. Been having a problem that I thought you might be able to help with:
I have created a Customer Community with Customer Communties license. I have a special object called Tasks (not standard object) that returns an Insufficient Privileges when I try to create a new record. The record and object have a lookup to Contacts, which is a requirement for the Object to be available for sharing sets. The profile allows access to this object. I think my problem is that this Task object should have Access Granted in Sharing Sets under Setup>Communities>Settings>Sharing Sets but it is not an available object in my list of available objects. The info icon says:
The Available Objects list excludes: • Objects with an organization-wide sharing setting of Public Read/Write • Custom objects that don’t have an account or contact lookup field
My custom object has a contact lookup field. The org-wide default is Controlled by Parent which is Contact which has a org-wide default that is Controlled by Parent which is Account which is set to Private. Seems to meet the above criteria.
The creation of these records works in our current Customer Portal but does not work in Communities. Do you have a quick suggestions of why this Task Object is not showing up in Available Objects under Sharing Sets.
Hi, there is one thing you can check here on the insufficient privileges issue. When you say your Custom Task has a lookup to Contact, does it actually have a Master-Detail relationship (since you say it is Controlled by Parent)? If so, there are actually two sharing settings within the field setup here that you’ll want to take a look at by editing the Contact Master-Detail field.
The default allows you to only create child objects if you have Read/Write access to the parent. The other option is to allow creation of child objects if you only have Read access to the parent Contact. I suspect you want the second option here, but you may have the first one selected. I would also expect that you can’t create a sharing set for an object that is Controlled by Parent–whatever’s in place for Contact would govern this custom detail object.
OMG! I have been wracking my brain on this. Thank you, Thank you, Thank you!!!!
That worked when I made the change. It is a Master-Detail relationship that had the Read / Write setting. In Sharing Sets the Account object was set to Read-Only. When I changed the Master-Detail Option to:
“Read Only: Allows users with at least Read access to the Master record to create, edit, or delete related Detail records”
it allowed the record to be created. It worked before on the other objects, without that change, because their Master-Detail relationship was with a Object that had a Private Organ-Wide Default (OWD) that did not have a Sharing Set access set to Read-Only.
The question is; what is the ramification of making this change on the field as opposed to setting the Sharing Set for Account to Read / Write. Account was initially set to Read-Only because we did not want our Communities customers to have any ability to change anything on the Account object but the Account OWD is already set to Private.
If you make the change on Account, it’s a more far-reaching change, because you’re opening up access to edit Account and other child records that are Controlled by Parent. If you change the setting just for the custom object in the M-D settings it only applies to that one object.
Hi Caitlin,
That’s a great explanation for a very difficult topic. It’s clearer than other documentation I’ve found, and I’ve been looking for some time!
I wonder would you be able to answer a question on “Community License Plus” user licenses and sharing from your own experience? We’re considering upgrading our “Community Licenses” to “Community License Plus” for the flexibility in sharing you mentioned in your blog.
“Partner Licenses” are too expensive ( we’re a non-profit ) so I hope the “Community Plus” middle ground will meet our needs. Our community users generally use only custom objects, Accounts and Contacts.
My difficulty is in creating teams with shared contact access between internal users on (Force.com and Salesforce licenses) and external community users without expanding Community User access too much.
Our community users have access to Contacts they create only, ( Contacts are set to private ) but all Accounts ( are set to public ) because our user added contacts can be residents in care locations and each user may add contacts to several accounts ( the care locations ).
We would like to expand access allowing contact sharing within teams with a combination of internal and external users. Roles sound like a good way to go here, but we’ve a very flat structure and I would have used public groups for this in the past.
Do you think I can achieve sharing for Contacts with Community License Plus?
I couldn’t get my head around sharing sets and if they would work, after attempts to use them failed for me I thought they might expand access too much or in the wrong way.
Is “sharing and roles” as a permission described on the Salesforce Community User Rights chart the same as available on internal licenses…with Sharing Settings for Public Groups available? With the licenses we currently have I can’t select external users at all (except partner user (we had a trial of these licenses) I’m not an APEX expert so APEX sharing is out of my league by a long margin.
I’d appreciate any advice or guidance you can provide!
This is a great blog post! Do you know if the CaseShare object can be used with the customer community license?
The use case I am trying to resolve with the customer community license is a parent-child account relationship
– A case may be created by a contact on the parent account
– A case may be created by a contact on the child account.
I would like to provide visibility of the case to the contact on the parent account in both scenarios.
Since sharing sets can only have 1 criteria I can support one use case or the other, but not both at the same time. I was thinking of using the CaseShare object as a workaround (Setting it up via Apex) but it is unclear if this object is supported for the community license.
Any thoughts would be appreciated.
This is a fantastic post!
Do you know if Sharing Sets are available for Community Plus licenses?
Hi Caitlin,
I am a new Admin. We have a Partner Community where only 3 Accounts have access. Each
Account has an Admin who should be able to CRUD all records for the Account (Account/Contact/Orders). Also this role should be able to add new users to the Account.
Rest of the Contacts in the Accounts are broken into Sales Teams. The Admin at the Sales Team level has CRUD for the Sales Team records.
Sales Teams are further broken into Groups. Each Group would have an Admin who would have CRUD to all the Group’s records. The we have team members who should have CRUD only on their own records.
I know that we have Profiles and Roles in the Salesforce org where we can control all this but in a Partner Community how would we do it?
Partner Community
– Sales Team Admin
– Group Admin
– Users
So an Account in the Partner Community can have several Sales Teams. Each Sales Team can be broken into several Groups. Each Group would have Users/Members
Thank you
I don’t have share sets? did they take this away?
Great demystifying post! Even Salesforce Documentation doesn’t break it down this clearly! Great Job!
This is a great blog post. The information regarding this is spread around or non existent and bringing it all together with use cases and screenshots is brilliant. Thanks!
Pingback: SALESFORCE CERTIFIED SHARING AND VISIBILITY DESIGNER! – Site Title
Pingback: About Sharing & Visibility Designer Certification! – Binod's Blog