Spring ’15 Chatter Features

In advance of taking the Spring ’15 certification maintenance exams I’ve been reading the release notes one more time, with a focus on the broader picture, not just the platform elements and headline features that catch the eye during the pre-release phase. I tend to follow this regimen for every release and inevitably the detail of a number of smaller features/announcements are picked up that were simply skimmed on the first review, or indeed added to a later version of the release notes – this happens (so always check you have the latest version). In regard to Spring ’15 the low-key features of interest relate to Chatter and are covered briefly below.

1. Add Records to Chatter Groups
With this feature it’s possible to relate arbitrary records to a Chatter Group via the “Add Record” publisher action on the Group Layout (this needs to be configured). The utility of this feature appears to be twofold; convenience and communication. For example, if we have a collaboration group for a sales campaign, we can now list the targeted account records on the group page and access via a convenient link. It would seem that the relationship is one-way, it doesn’t appear possible to view the groups to which a record is related from the record detail page. Note, feed posts at the record level are not shared with the group.

Group Records 1

Group Records 2

2. Question-to-Case (GA)
Chatter Questions is a great collaboration feature in its own right, enabling expertise across the internal or external community to be brought to bear on posts structured as questions, with specific functions for answers, mark-as-best etc. As the name implies Question-to-Case allows a question to be escalated to a case from within the feed, with the feed post marked visibly as such.




A further extension to this feature, Knowledge Deflection for Chatter Questions is currently in beta. The functionality of this should be evident.

3. Action Links (GA)
Buttons can be added to feed posts that download a file, access a web page or call a 3rd party API. Action links can be grouped within an Action Link Template and packaged for ISV distribution. Action links are functionally very interesting, given the use cases they open-up, however the implementation is non-trivial and warrants a follow-up post.

It’s interesting to see how the Chatter product continues to evolve release-on-release. The direction the product is taking appears sensible, i.e. finer grained control via increased Trigger coverage (custom moderation etc.), richer content previews and extended external integration capability. Top of my wish list incidentally would be an enhancement to Topics to allow post activity from associated records (Topics for Objects) to be automatically shared and pushed out to topic followers via digests. This could be an optional flag that marks the topic as aggregating. With this model, users can simply follow a topic and have content pushed to them proactively that is either directly related (feed post association) or indirectly (feed post against an associated record). Such a feature would really help transition many notification use cases from email/task to Chatter.

Salesforce Topics

One of the more interesting (but low-key) functional enhancements to arrive on the Salesforce platform over recent releases is Topics.

All Topics Page

A Topic can be viewed as a consolidation of the collective enterprise intelligence around a specific term or theme, across both the collaboration dialogue and the business processes managed within Salesforce. In practical terms this translates to Chatter posts and Object records being assigned one or more new or existing Topics. All assigned records and posts then display on the Topic page – providing the consolidated view of everything happening across the enterprise that pertains to the Topic. This is incredibly powerful in terms of both data categorisation and the insight possible from considering the holistic view of a contextual theme or initiative.

Topic Page - Feed tab

The Topic functionality doesn’t end there; from a Topic page (see screenshot above) it is possible to endorse users as experts on the Topic thereby harnessing knowledge within the enterprise and providing an effective means of channeling communication such as a questions, suggestions and so on. Note, users can elect to remove themselves from the Knowledgeable People list.

Topics can be followed (if feed tracking enabled for Topics) and favourited which enables interested users to be updated proactively. Discussion of Topics is tracked at the Group and User level, the Chatter tab also shows the Trending Topics area which highlights recent activity, this excludes Topic used solely in private Groups or record feeds.

Note, as a point of clarification Topics differ from Groups in that they collect posts from across Chatter and also records.

Primary Use Cases

1. Topics provide a good solution option for any data categorisation or notification requirement relating to enterprise-wide initiatives or themes.
2. Topics map well to Organisational concepts such as departments, virtual teams, projects etc.
3. Topics could provide a useful (albeit elective) notifications model where the Topic feed is used to push notifications to users interested in new transactional records related to the Topic theme, which could represent a reference data type such as a region, product or channel.

Key Considerations

Topics for Object. Once enabled for an object, records can suggest Topics based on the values in selected fields. Whilst a Topic has a feed, record assignment does not generate a post. To mitigate this, Topic assignment can occur via #hastag in a post to the record feed. Additionally, feed activity related to a record is not viewable on assigned Topic pages. The concept relates to grouping and categorisation of records, not consolidation of feed items.

Global Search enabled. Topics appear as a distinct Object within the Record search results.

List Views. Topics can be referenced in List View filter criteria.

Reports. With Winter ’15 the reporting options are limited to those below (to my understanding) via CRT. Reporting on record level assignment isn’t there as yet.
–Topic – list of topics with # talking about statistic
–Topic Assignment – count of assignment per record type (key prefix)

Knowledge Articles. Topics can be added to Knowledge articles enabling end-user categorisation of published articles in addition to pre-defined data categories.

Customisation. Apex triggers can be defined on the Topic and TopicAssignment (assignment of a topic to a FeedItem or a record) objects, which are also API accessible.

Permissions. Profile permissions (or permission set) control who can create, edit, delete and assign topics. Defined topics are public regardless of whether they are solely used in private groups or on records.

Topics for Objects – Screenshots

1. Add a Topic to a Record

Add Topic to Record

2. Topics Assigned to a Record

Record with Topics

3. Topic Page – Records Tab

Topic Page - Records Tab

Salesforce Communities at a Glance

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

Communities 1

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.

Communities 2

Chatter email branding – a previous pain point with branded Chatter implementations.

Communities 3

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.