Security

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.