Salesforce has given its customers a great deal of functionality with their Communities offerings. It brings external customers and partners into business process with some easy-to-use out of the box functionality. While out of box functionality is always nice to have, it’s also comforting to have the ability to build a fully custom, branded Community using Visualforce. I’d like to share four things I wish I knew before my first implementation of a Salesforce Customer Community. They deal with funky email patterns, how licensing can impact design, and some best practices for the technical team implementing the Community.
1. (Publishing a Community === Tremendous Email Capabilities)
There is a very important note about the functionality that is attached to “enabling” profiles for a community. Both partner and customer communities have the ability to select profiles that can use the Community (see image 1 below); What you should know is that every time you add a new profile to a community, the welcome email that is setup for the Community will be sent to users in that profile. If you accidentally add an internal user profile, expect that all of those internal users will get the welcome email; which can be nice, or very, very annoying based on the timing of when you’re trying to add users. It is very normal to consider (and adjust) who can use the community before finalizing the welcome email – so be careful!
Image 1: Community Profiles
There is also another detail about welcome emails that is quite confusing when you have a requirement of self-registration. Salesforce provides you an Apex class called “Site” which you will undoubtedly use if you plan to build a custom registration controller. It has, among many methods, one important method called createPortalUser (see Salesforce documentation here.) This method, as you might guess, creates a new portal user. However, a small detail is that there is a fourth parameter which takes a boolean input to tell the Salesforce servers whether or not to send the welcome email. Based on your configuration in the Community, and your usage of this parameter, it is actually possible of emailing the exact same user registration two welcome emails, or none. Also, it’s very easy to get the configuration out of sync between Sandbox and Production so be sure to double check what actually happens with respect to welcome emails in every environment (Sandbox vs Production).
2. Licensing Causes Complicated Solutions!
As you may or may not know, Salesforce has very specific differences between Customer Community licenses, and Partner Community licenses. Most of these differences come in the form of restricted object access (among other restrictions). I couldn’t stress reading this Salesforce document enough. It is very important! Also, here is a graphic (pulled from this fantastic blog post by Steven Herod) with some more details around which objects are NOT editable using a Customer license. Namely, you cannot edit, or create Accounts, Opportunities, or Leads.
Given the restraints due to licensing, it is important to remember that workarounds and additional functionality can be used to offset some of the limitations. For example, if there is a requirement that end-users of a Customer Community need to edit the address of the account they are a part of, you might consider using a child object under account called “Contact Information” that allows many addresses, phone numbers, email addresses etc to be managed from the Community without ever hitting the limitation. Let your design juices flow!
3. if(customerCommunity){ return noRolesOrStandardSharingModel;}
While Communities have a lot of similar functionality to standard Salesforce out of the box, like tabs, list views, detail pages etc, one aspect of Customer Communities that is much different is the set of tools used for record level sharing. Nicely stated in this stackexchange post by greenstork, “Customer communities users do not have access to the full sharing model but can share records in a limited way using sharing sets and groups. These sharing tools basically allow for sharing of any object accessible to the Customer Community license between users on the same account, determined by an account lookup on the object.” Here is a Salesforce overview of Sharing Sets as well as their guide to Granting Community Users access to records.
EDL Consulting has done a good job of describing the “how” of sharing sets in this blog post. Please familiarize yourself with the limitations around sharing to prevent a serious headache later on (that is, unless you plan to handle security in your visualforce controllers).
4. useContinuousIntegration() && System.assert(complicatedUATprocess, true)
While you may or may not used a continuous integration before, I would urge you to try to get it working for any upcoming branded (Visualforce-based) Salesforce Community implementation. At Silverline, we use Jenkins on an Amazon server for CI; but, there are other options like Bamboo or Drone.io. Also there is an abundance of helpful material to setup CI. Here are just a few of my favorites:
Salesforce CI with Drone.IO from VerticalCoder
One driving force to use CI is that having end-users/business units looking at a Community that is currently under development is a seriously complicated affair. Your business units will see partially functional requirements and report that it isn’t working (even though the developer already went home for the day and is fully aware that things are not finished). So, managing the bug reports can become overwhelming in a hurry. This leads me to my last piece of advice: use a webform for UAT, not a shared spreadsheet. Tools like Smartsheet or Google Forms allow you to create a publicly accessible web page, with configurable questions to allow your end-users to easily submit tickets. This will make your life much easier!
Hopefully this post helps you keep some limitations front of mind before your next buildout of a Salesforce Community. If you have any questions, please post them below. Interested in learning more? Read about our work with communities here.
