Posts Tagged ‘Sharing Rules’
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.
Recently I came across a rather confusing situation with my Force.com application. I had whittled down my profiles; implemented a marvelous role hierarchy; and a number of sharing rules, and although my application was functionally restricted i.e. object-level access, field-level access etc., the data didn’t seem to be restricted by the sharing model i.e. I could see data created by user A when logged in as user B, even though I had explicitly disabled this behaviour.
The application I’m developing may not be the same or even similar to yours, especially since I don’t use any standard pages. I suspect that if I had use more of the standard functionality I may have guessed at the solution a bit earlier. Read the rest of this entry »