This begins a series of daily posts that I am calling 30 Days of Summer ’13, which is using a concept that I first saw employed by Jeff Blakenburg for his 31 Days of Windows Phone 7 series in October 2010. This series will consist of articles that will cover a multitude of different aspects of the Salesforce.com Summer ’13 release.
30 Days of the Salesforce.com Summer ’13 release
In Day 1, I thought it would be a good idea to discuss what could be considered the most significant part of the release, which is the addition of Communities. Communities are areas within your Organization where people outside your company can collaborate with employees and share information that is important to your business processes. These may include partners, vendors and customers. These communities can be customized to include your company’s colors, logo and other brand details to ensure familiarity to external users. What is great about Communities is that you can create multiple communities for different purposes. Instead of having one area for customers, where they have to navigate the area to distinguish between obtaining support and the sales space, your customers will be able to go to a Support Community to easily find the necessary information.
At this point, you’re probably saying to yourself “A place on our Salesforce.com environment that is available for people outside the company, such as vendors, distributors and customers that has the same look and feel as our website? Wait a minute! You’re talking about our portals!” In fact, I am talking about portals. As of the Summer ’13 release, the Customer Portal and the Partner Portal are NOT available for organizations that are not currently using them. If you are currently using portals, you will be able to use them as you have in the past or transition everything to Communities. When you do transition to Communities, there’s no need to update the profiles or licenses on the user records of those with access to the current portals if the Communities are configured similarly.
“Uh oh. He mentioned licenses. Why did he say licenses?”
With the introduction of Communities, there are now two additional licenses on the platform: Customer Community and Partner Community. The correlation of these two new licenses is:
||High Volume Customer Portal
||B2C connections with a large number of external users
And while these new license are available, Communities will still support existing internal and portal licenses, such as the Authenticated Website and Customer/Partner Portal licenses. (But not the Chatter External license.)
One last thing before we get into the configuration: Communities are available in Salesforce Touch with limitations. Obviously, any objects or other metadata that you have set up in a Community, but is not supported in Salesforce Touch, will not be supported in Salesforce Touch. In addition, Ideas communities and self-service access to Chatter Answers are not supported. Finally, and this is the tough limitation to live with, but any customization that is made will not be supported on Salesforce Touch. Therefore, if you customize your community to include your company’s branding, you will need to create a custom mobile client for the community to make it accessible on mobile devices.
Enabling Salesforce Communities is both nice and easy. The nice part is that you don’t have to contact your Account Executive to bring the Communities functionality to your Salesforce org. Simply go to Customize > Communities > Settings in Setup and select the checkbox next to Enable Communities. It’s that simple, yet…
There are a few important things to consider before making this simple configuration change. Once you make this change, there’s no going back. You can un-ring that bell, you’ve opened that can of worms, and other clichés that signify that the change cannot be undone. This is important because enabling communities adds a new header for every user in the organization, regardless of their membership in any community. It can be turned off through a setting in the Permissions section of Custom Profiles, but cannot be disabled for Standard Profiles. In addition to the new header, enabling Communities also facilitates a new theme in Salesforce, which updates the overall look and feel of the org.
Another important decision that needs to be made before enabling Communities is selecting a domain name for your communities. Technically, what you are choosing is the subdomain for your communities, and once this subdomain is chosen and Communities are enabled, it cannot be changed. Every community that is created has its own URL, but each URL shares the same domain name (or subdomain and top-level domain.) The different communities are distinguished by the full path of the URL, which is determined when the Community is created. For example, if you are creating a Community for customer support, you would create a New Community and set the URL to companyname.force.com/support during the process. When creating the Community, only the “support” part of the URL will be editable, whereas the “companyname.force.com” part was selected when Communities were enabled.
Creating Communities is really standard when compared to other areas of Salesforce.com configuration. When you go to Customize > Communities > Manage Communities in Setup, you click on the New Community button at the top of the list, add the name, description and URL path for external user access to the Community. One thing the Release Notes mention is the number of characters that are visible to the user in the drop-down menu on the global header. Users can only see 32 characters, but that includes a status indicator that notifies the user if the community is in Preview or Offline status. So, honestly, if you want your users to see the name of the Community, regardless of status, you want the name of the Community to be not more than 21 characters long.
“Customer Support Seven” is 22 characters
“Customer Support Four” is 21 characters
Instead of rehashing the information found in the release notes, I’m going to list a few quick notes that I found while reading about and walking through Communities in Salesforce.com. If you want to read more detailed information about Communities and implementing them up, check out a PDF provided by Salesforce.com called Getting Started with Communities.
- Members of a Community can be added through Profiles and Permission Sets only. In order to give access to a user outside of an approved profile, you will have to set up a permission set with the profile and the user.
- While internal users must use their username/password combination to access Communities, external users can access Communities a few ways:
- The standard username/password provided when they were given access to the Community,
- SAML for single sign-on if it’s configured in your organization,
- External authentication providers such as Facebook or Janrain. So, basically, Facebook.
- External users can also have the ability to Self-Register. The most interesting part of the self-registration blurb is the following line: When your organization enables Communities, a default set of self-registration Visualforce pages and associated Apex controllers are created.
- External users with access to multiple communities in an Organization will use the same login credentials to access all the communities.
There are a few pages about who can see what in Communities that I will review in a later day in this series. But, for now, there is a quick introduction into Communities: Day 1 in 30 Days of Summer ‘13