This long overdue post provides a quick review of the Salesforce Communities functionality which became GA in the Summer ’13 release.
In my simplistic view Salesforce Communities is a way to bring external users directly into a Salesforce org in a restricted manner with a branded user-experience. This may be for collaboration purposes in the social enterprise sense (i.e. Chatter) or simply to extend a business process out to external parties.
In user license terms a single Community can support internal users and both customer and partner users – a key differentiator from the preceding portal functionality, where portals were limited to either customers or partners with no internal user access. A highly customised portal experience can be delivered using Force.com Sites (and Visualforce etc.), as per the traditional manner – or via Site.com, with its rich drag-and-drop build model. In both cases unauthenticated and authenticated interactions can be delivered. With Communities however the traditional (I mean outdated) portal look-and-feel is replaced with the standard Salesforce aesthetics, with the option to customise the header, footer and colour palette. It’s also straightforward to deliver a branded login page on a custom URL. All in all I think Communities provides a great advancement in terms of delivering branded, collaborative customer/partner interactions using the declarative build tools. Add to that the full collaborative power of Chatter and the Communities proposition is a compelling one.
Salesforce Communities
A very basic Community in preview mode – note the custom colour palette. The rather invasive Global Header can also be seen, thankfully this is now optional page furniture.
Chatter email branding – a previous pain point with branded Chatter implementations.
Branded login page with Authentication Service buttons.
What is it?
In principle a portal technology, in practice a restricted access entry point to a subset of data and functions from an internal Salesforce organisation – presented with a customised/branded UI and custom url.
Key points.
– Internal and external members. A community can contain members with Partner and Customer Community licenses, internal org licenses and legacy portal licenses.
– Custom URL. Communities can be exposed on a custom domain. The default is a subdomain on the force.com domain as-per Force.com Sites etc. Note, I’m unclear on how this works in terms of SSL, at this time it is not possible to upload a server certificate for a custom domain, therefore SSL isn’t supported. This limiting situation may change imminently, I believe a beta for exactly this type of functionality ran last year.
– Communities are built in Preview status, then published.
– Community tabs can be either Salesforce tabs (custom or otherwise) or provided by Site.com.
– Branded login page (header logo and footer text) – see screenshot. Basic customisation is possible, how effective this is will largely depend on the image etc. The login page supports selection of enabled Authentication Providers.
– Branded UI (header, footer images and colour palette). Again, this is light-touch cosmetic customisation and will work where a minimal brand presence is required – which is advisable for an immersive application.
– Accounts are enabled for Partner Communities. Up to 3 roles can be specified (which are direct children of the Account owner in the role hierarchy – consistent with legacy portal roles. The super user concept is also supported.
– Contacts are enabled for Customer Communities (HVPU – i.e. no role or sharing rules = Sharing Sets and Share Groups).
– Person Account can’t be enabled for Partner Communities. Person Accounts can’t be enabled as Partner Accounts and therefore can’t access partner portals, so this limitation is consistent.
– User Sharing can be used to control who can see who within the Community (as-per the internal org). A useful capability particularly in scenarios where senior employees may wish to observe a community but not be visible to all.
– Communities support self-registration.
– Mobile access enabled.
– Unauthenticated content, or highly customised interactions can be supported by either Force.com Sites or Site.com.
– Force.com Sites pages inherit the Community branding by default.
– Chatter Email Branding. System emails generated by Chatter can be branded in terms of logo and footer text. This removes the Salesforce branding which has historically been problematic with branded Chatter implementations.
– Ideas, Chatter Answers and Salesforce Knowledge can be enabled within a Community.
– Communities supports SSO for internal and external users via the SAML protocol and a SAML enabled Identity provider, or via external service providers (Facebook, Open ID Connect, Janrain and Salesforce).
User Licensing?
Customer Community License – Equates to a High Volume Portal User License (HVPU). Therefore the usual restrictions on HVPU record access apply (no role and no ownership or criteria-based sharing rules). Sharing Sets and Share Groups must be understood when considering an effective record access model.
Partner Community License – Equates to Gold Partner License.
The new Community user license types represent the two extremes of the portal licensing scale, with significant differences in capability and pricing. It is therefore good news that a single Salesforce Community can support both types enabling a blended view to be taken on the license model.
One final observation, the two key pre-requisites to implementing Salesforce Communities are a rigorous audit of the current state security model (record access, profile/permission sets, groups, folders, listviews etc. etc.) and a detailed future state design. In both cases this should cover specifics such as Chatter groups, user-sharing etc.. In my view it’s always better to be proactive and pessimistic when it comes to security.