Posts Tagged ‘sharing model’
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.
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
- 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
- All options are available
- 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.
- Child objects can have their own sharing access level and ownership. Sharing access through hierarchies can also be disabled.
- 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
- 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)
- You want to share records owned by HVP users with internal users, groups or roles (includes portals users with roles)
- 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
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
- 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.
Now I’m sure there’s a reason for this but it makes me sad a bit. Especially when working with a team of developers. Recently I found myself in the following situation,
My team and I had been building a Force.com application and were interested in implementing an UAC model. We had setup the UAC model on one of the Orgs using profiles, roles and sharing rules(we had some issues here too) and then attempted to commit these changes into our SVN repository. Happy that things were going so well, each developer checked out the code and BHAM! we were no longer able to deploy object definitions. [Slow pan to me on my knees screaming to the heavens. A thunderbolt, then a thunderclap overhead] Read the rest of this entry »