Sharing is complex, but necessarily so. It gives you incredibly fine-grained control over data access through it’s flexibility but requires quite a deep understanding to do it properly.

There are great articles out there that describe sharing in detail e.g.

Force.com object and record level security

An Overview of Force.com Security

I don’t want to recreate what’s in those articles, instead I’m providing a short, sharp cheat sheet of the major topics you need to understand. So without further ado…

Sharing Cheat Sheet

Sharing Metadata Records

• “Object[Share]” for standard objects
• “Object[__Share]” for custom objects
• Fields: access level, record ID, user or group ID
• Share records are not created for for OWDs, role hierchies or the “View All” or “Modify All” permissions

Implicit Sharing

• For Accounts, Contacts, Cases and Opportunities only.
• A platform feature, cannot be disabled.
• Access to a parent account—If you have access to a child contact, case or opportunity record of an account, you have implicit Read Only access on that account.
• Access to child entities—If you have access to a parent account, you may have access to the associated contact, case or opportunity child entities. Access is configure per child object when creating a new role.

Organisation-Wide Defaults (OWD)

• All standard objects use sharing access through hierarchies and this cannot be disabled
• Public (Read or R/W) can be seen by all users (including portal)
• Can’t be changed for contacts if person accounts are enabled

No Relationship

• All options are available

Master Detail

• Child objects have their sharing access level and ownership dictated by their parent. This also stands for any grandchildren. The parents value for “Grant access through hierarchies” is also inherited.
• Child objects don’t have a share-record of their own and will be shared along with the master record.
• In fact you cannot even define sharing rules from the object detail-page.

Lookup

• Child objects can have their own sharing access level and ownership. Sharing access through hierarchies can also be disabled.

Manual Sharing

• Removed when owner changes
• Removed when access via OWD becomes at least as permissive as the share
• Private Contacts (those without an Account) cannot be shared manually

Apex Managed Sharing

• Can be used for Manual Sharing although it isn’t called Apex Managed Sharing in this context
• Using Apex to share Standard Objects is always considered Manual Sharing i.e. Apex Managed Sharing is only really a feature for Custom Objects
• Maintained across ownership changes
• Requires “Modify All” permission

Recalculation

• Need to create a class that implements the Database.Batchable interface
• The recalcuation is run when the OWD for the object changes
• The OWD for the object in question must not be the most premissive access level

Choosing the Right Share Type

“Traditional” / Ownership-based Sharing Rules

• You want to share the records that a user, group, queue or role own with another user, group or role (includes portal users with roles).

Criteria-based Sharing Rules

• You want to share records based on values of a specific field or fields with another user, group or role (includes portal users with roles).

Apex Managed Sharing Rules

• Your sharing requirements are batshit cray-cray. Examples include:
  • Sharing multiple records at once
  • Sharing records on object A based on criteria being met on object B
  • Criteria-based sharing using a field not supported by “Criteria-based Sharing”

Manual Sharing Rules

• The record owner, or someone with modify all permission, wants to share an individual record with another user, group or role (includes portal users with roles)

Share Groups

• You want to share records owned by HVP users with internal users, groups or roles (includes portals users with roles)

Sharing Sets

• You want to “share” records with HVP users. These records need to fulfill the following criteria:
  • Objects has an organization-wide sharing setting different from Public Read/Write
  • Objects is available for Customer Portal
  • Custom object has a lookup field to account or contact

Portals

High Volume Portals (Service Cloud Portals)

• Include High Volume Customer Portal and Authenticated Website profiles
• They have no roles and can’t participate in “regular” sharing rules
• You can share their data with internal users through Share Groups
• You can share object records where the object is a child record of the HVP user’s contact or account. This is done with Sharing Sets.
• They can also access records that are:
  • Available for portal, and
  • (Public R/RW OWD, or
  • (Private OWD, and
  • They own the record))
• They can access a record if they have access to that record’s parent and the OWD is set to “Controlled by parent”
• Cases cannot be transferred from non-HVP to HVP users

other portals

• Have a role hierarchy at most 3 levels deep and can participate in regular sharing
  • Person accounts only have a single role
  • Business accounts can have 1 – 3 roles.

Large Data Volumes

• Defer sharing settings (enabled by logging a case) and group calculation on large data loads and modifications

If you’ve got any other items you think should be in this list, let me know in the comments. Peas oat.