Sharing

This diagram provides a high-level overview of Salesforce Sharing Architecture concepts and platform capabilities. This is the second in a five-part Salesforce Architecture reference series covering core application and system architecture topics.

Salesforce Sharing Architecture (PDF)

A fit-for-purpose sharing architecture is one of the fundamental elements that underpin a secure and performant Salesforce implementation. The sharing architecture defines the record-level visibility model and should be subject to periodic review and refinement to reflect shifting organisational factors. The most efficient sharing models make full use of implicit sharing via the Role Hierarchy, with minimal use of explicit techniques such as Sharing Rules. An implicit model is reliant on a well conceived Role Hierarchy that reflects data access across the organisation, and is therefore not necessarily aligned directly to the organisational structure. This is hard to achieve and requires an approach of continual adjustment throughout an implementation project and beyond. The benefits of this approach are manyfold; control, reporting, maintainability and performance being just examples. In regard to control, implicit access provides the record-owner level of access, which can’t be achieved via explicit means. With reporting, the dynamic filters “My Team’s Accounts” etc. are based on the Role Hierarchy, i.e. users in roles below the current users’ role etc. in addition with some reports the Role Hierarchy can be used to filter the output at runtime. In regard to maintainability, the proliferation of sharing rules often introduced to compensate for a substandard Role Hierarchy design is avoided. Finally, in the performance case, although sharing data (AccountShare etc.) is persisted at the time of configuration, and not calculated fully at the time of record access, there is still a performance consideration with complex sharing models. So in short, a sharing model that is predominantly implicit is better than an explicit model. Irrespective of whichever model is implemented, a comprehensive understanding of the explicit techniques and their primary use cases is important to ensure the sharing model is appropriately secure and maintainable.

For the first time in a number of releases, the Spring ’15 release introduces a new sharing model feature “Manager Groups”. This feature extends the capability of explicit sharing techniques (Manual Share, Sharing Rule and Apex Managed Sharing) enabling direct use of the management hierarchy, as defined by the Manager field on the user record. Manager Groups are system defined, per-user, and can be utilised in the same way Public Groups are used in the same contexts. For each user 2 Manager Groups are provided; “Managers Group” – immediate managers and their manager and so on (up the management hierarchy) and “Manager Subordinates Group” – the user’s direct reports and their reports and so on (down the management hierarchy). Unlike Role Hierarchy based sharing, Manager Groups share directly to each user in the hierarchy chain, not all users with the parent role.

Note, the Manager Groups feature was initially introduced in the Winter ’14 release and made available upon request. Spring ’15 makes the feature automatically available in all orgs.

Prior to the introduction of Manager Groups, sharing based on the management hierarchy relied upon the Role Hierarchy reflecting the management hierarchy, or elaborate explicit means. The Manager Groups feature now provides an efficient means to share data up and down the management hierarchy, leaving the Role Hierarchy to strongly model the data access requirements for the organisation.

Enable via Sharing Settings page

Manual Share

Sharing Rule Definition

References:
Sharing Records with Manager Groups
A Guide to Sharing Architecture
Designing Record Access for Enterprise Scale
Record-Level Access: Under the Hood

This brief post serves to clarify the sharing model related to Activities, i.e. Task and Event. For most implementations a public sharing model for Activity is highly appropriate and a necessary element of the CRM process. In some cases however a private model is required, perhaps where strict visibility rules must be applied in respect to Account and Contact, or where the activity itself is of a confidential nature. In the former example details of the Contact (Name, Title, Account Name) are revealed on the Activity record to assigned users (and those above them in the role hierarchy) who don’t necessarily have record visibility to that Contact or Account. This can be a problem. In the latter example, the interpretation of private OWD for Activity relates to editing of records, not visibility of records (as is the case for other objects) meaning there’s no mechanism to restrict access selectively to Activity records related to a given record. In mitigation, field level security (FLS) can be applied to hide fields from certain users, this approach can be effective but is not ideal. As such the implementation of a fully private sharing model for Activity can be difficult to achieve.

Activity Org-wide Default Implications
— Private : Read access to the [Related To] record provides read access to the Activity. Only the Assigned User and users above them in the role hierarchy can edit.

— Controlled by Parent : Read access to the [Related To] record provides read access to the Activity. Edit access is possible for the Assigned User and users above them in the role hierarchy or requires edit access to the [Related To] and [Who Id] records.

In considering the OWD settings above, the rules below must also be understood.

1. Activity Visibility. If the Activity is related to a Contact, then View access is required to the Contact, with the exception of the Assigned User (and role hierarchy) who can view the Activity regardless of Contact access. Private contacts can be problematic in this context.

2. Activity Edit. If the Activity is related to a Contact, then Edit access is required to the Contact, with the exception of the Assigned User (and role hierarchy) who can edit the Activity regardless of Contact access.

References
Help and Training – Access to Activities and Calendars
Idea – Support for fully private (no read or write) activity sharing model

Finally, this post concludes a series exploring record access considerations with the different portal user license types. This post covers the Partner Portal type.

By way of reminder, the decision tree below should be used when making the high-level decision on the appropriate license type for the different user populations within your portal.

Partner Portal
The Salesforce partner portal supports partner relationship management (PRM) scenarios such as Opportunity collaboration, Lead sharing etc. Enabling businesses to manage channel activities within Salesforce in parallel to their direct sales. As with all external user access scenarios it is imperative that the visibility model provides partners with relevant data access, but no more. Partner portal users have the Gold Partner user license type – it is my understanding that the Silver and Bronze license types are no longer available.

CRUD permissions :
Create on Account, Asset, Cases, Contacts, Custom Objects, Idea, Lead, Opp – basically all the SFA standard objects.
Read on most standard objects
Update – as create, excluding Idea

Default record access :
Partner portal users are placed in the role hierarchy as below, as descendant roles of the Account Owner’s role.

So for each account where a Partner Portal user is activated (Acme in the case above), a set of 3 roles is created under whichever role the account owner has allocated. Executive users can view manager owned records and so on. The number of roles created can be set between 1tans 3, giving control over partner user sharing granularity versus proliferation of user roles (and consequential impact on performance).

Sharing options :
Role-based and criteria-based (CBS) sharing rules, manual sharing, Apex Sharing, Apex Managed Sharing.
Account and Sales teams.
Can have the “Super User” permission – this provides access to data owned by users within the same role or below in the portal account hierarchy, limited to Cases, Leads, Custom Objects and Opportunities

Other considerations :
Introducing a partner portal requires a full analysis of the sharing model implemented within a Salesforce org. Public sharing means public to partners also. This principle equally applies to report and document folders. Listviews with names which reveal something you don’t wish your partners to see should also be secured.

Note. This page on the Salesforce help site provides an excellent reference for further information.

An interesting addition to the Summer ’12 release is the pilot of separate OWD settings on custom objects for external users. For example, a custom object may have public read-write sharing for internal users and private sharing for external users. In many cases this will simplify the sharing model significantly as the rules below have historically applied to all users including portal users and guest users.

Is there a user who can’t see all records == private
Is there a user who can’t edit all records == public read-only
else == public read-write

Applying the above OWD rules across internal and external users typically results in an overly private model for internal users and a resultant proliferation of performance-expensive sharing rules. The new separation of concerns here is a great improvement for custom objects, but not standard objects (hopefully this is on the roadmap).

Seemingly simple, yet powerful functional enhancements such as this that reduce the amount of custom configuration applied to an org are to be applauded.

This post is the second in a series exploring record access considerations with the different portal user license types. This post covers the Customer Portal Enterprise Admin type.

By way of reminder, the decision tree below should be used when making the high-level decision on the appropriate license type for the different user populations within your portal.

Customer Portal Enterprise Admin
The Customer Portal Enterprise Admin (CPEA) user license type relates to the Customer Portal Manager Custom license type (as displayed within Salesforce). Note, the Customer Portal Manager Standard license type is obsolete in the sense that it is not available to new customers. The CPEA user license provides coverage for use cases such as B2B empowerment to manage portal users (Delegated Portal User Admin), extended standard object permissions and non-trivial record access requirements (beyond those applicable to HVPU).

CRUD permissions :
Create, Read and Update on Account, Asset, Case, Contact
All on Custom Objects
Create and Read on Idea
Read on Article, Price Book, Product, Solution, Answers (Question, Reply)

Default record access :
CPEA users are placed in the role hierarchy as below, as descendant roles of the Account Owner’s role.

So for each account where a CPEA user is activated (Acme in the case above), a set of 3 roles is created under whichever role the account owner has allocated. Executive users can view manager owned records and so on. The number of roles created can be set between 1 to 3, giving control over user sharing granularity versus proliferation of user roles (and consequential impact on performance).

Sharing options :
Role-based and criteria-based (CBS) sharing rules, manual sharing, Apex Sharing, Apex Managed Sharing.
Case teams.
Can have the “Super User” permission – this provides Read and Update on cases submitted by all users related to the same account (includes case comments and attachments).

Other considerations :
The CPEA user license is significantly more expensive than the HVPU license types – for good reason, and should be used only when the additional functionality is necessary – perhaps in a complementary model. It always makes sense to perform a full upfront analysis of the access model requirements for a portal solution – retrospectively addressing functional issues incurred through the wrong license type selection can be costly and entail inelegant design compromise.

Note. This page on the Salesforce help site provides an excellent reference for further information.

When designing portal solutions on the Force.com platform it is imperative to understand the sharing model implications of the user licenses and related base user profiles in play. In this post I’ll outline the key considerations in respect to record access for high-volume portal user license types; Authenticated Sites (aka Platform Portal) and Service Cloud Portal. In both cases users do not have roles and can’t be added to teams, groups or sharing rules. So how do you provide record access?

Note, this topic (and complex sharing models in general) is fundamental to understand if you’re considering the Salesforce Certified Technical Architect certification.

So to start with, the decision tree below should be used when making the high-level decision on the appropriate license type for the different user populations within your portal.

The following items examine each of the HVPU license types in turn with a view to clarifying how record access is achieved and the constraints to consider.

Applicable to all user license types are the following record access rules, which should be considered carefully if a public sharing model is in place and a portal is added:
Read on all records where the object org-wide default is public read-only
Read-write on all records where the object org-wide default is public read-write

HVPU License Types:

Authenticated Sites
The Authenticated Sites, or Platform Portal User, license is intended for high-volume scenarios (up to millions of users) where access to Standard Objects is not necessary and record access requirements are simplistic.

CRUD permissions :
Read on Document, Price Book, Product, Account, Asset
Read and Create on Idea
Full access to Custom Objects

Default record access :
Custom object records owned by the user
Read on Account related to the portal user
Read and Update on Contact related to the portal user
Master records where the user has access to the detail record and vice-versa

Sharing options :
Sharing Sets – provides sharing to records (account, case or custom object) related to the portal user’s contact or parent account (via lookup field). Access level can be read-only or read-write but can’t be more restrictive than the OWD for the object. Sharing Sets are at the user profile level, not per-portal and each user profile can be associated with only one sharing set. For example – you can provide write access to the portal users related account via a sharing set, or provide full access to all custom object records in a private OWD object which are related to the same account as the portal user.

Other considerations :
A Share Group defined at the portal level provides access to records owned by HVPU to other users, via Public Group, Role, Role and Subordinates and Users.

Use case :
A reasonable exemplar use case for this license type would be event attendees registering for an event within an event management portal. In such a case the attendee may need to login after registration to provide further details, make payment, book a session etc. The attendee needs access to their own records held in custom objects and update permission on their Contact record. The attendee may also require visibility as to who else from their company is attending. Basically this license type is for external user Force.com solutions underpinned by custom objects.

Service Cloud Portal
Relates to the High Volume Customer Portal User License and is intended for high-volume scenarios (up to millions of users) where access to Standard Objects (cases etc.) is a definite requirement but record access requirements are simplistic.

CRUD permissions :
Read and Update on Account
Create and Read and Update on Asset, Contact, Case
Read on Document, Price Book, Product
Create and Read on Idea
Full access to Custom Objects

Default record access :
Records owned by the user
Read and Update on Account and Contact related to the portal user
Master records where the user has access to the detail record and vice versa.

Sharing options :
Sharing Sets – see above.

Other considerations :
Share Groups – see above.

Use case :
The typical use case for Service Cloud Portal licensing is mass B2C self-service support scenarios – offering case logging, idea creation etc.

In the next post I’ll extend coverage to the Customer Portal Enterprise Admin and Partner Portal license types.

Note. This page on the Salesforce help site provides an excellent reference for further information.