As a Salesforce Gold Partner, we love to work with the whole gamut of Salesforce solutions. In particular, many of our technical consultants specialize in Marketing Cloud, Sales Cloud and Communities (among other things).
Communities happen to be one of my favorite offerings to work with and implement. They’re rich in features, and they can quickly help connect a business to its customers and vice versa.
Thinking about getting started with a community for your own customers or dealers? Here’s the inside scoop on five things you should know:
#1: Licensing: Different Editions & Types
Salesforce licensing for external community users comes in basically three main editions: Customer, Partner and Lightning External. Within each edition, there are two types: Member-Based and Login-Based.
Tip: think of the three editions as level of access and the types as how often the community will be used.
- Customer (aka Self-Service) – I consider this the minimum needed for external access and collaboration, but note that even without specific licenses, external people can still have some access to a community. A support portal would be the prime example here, e.g. if you want users to be able to create a case and access knowledge articles.
- Partner – This next level is designed for B2B interactions where you want to pull in sales data as well. This is basically a PRM (Partner Relationship Management) license.
- Lightning External – This edition offers a more custom experience for almost anyone. This could be used to create a customer forum, display data external to Salesforce, or build full enterprise portals that handle everyone.
Note: Both Customer and Lightning External technically have two options each themselves – Standard and Plus – that allow further granularity for accessing different objects in the Org.
- Member-Based – This license type is much like other standard Salesforce license types. It’s generally a higher fixed monthly amount per license, and the user assigned with it can log in as many times as they want to.
- Login-Based – This license is best for those external users who might only login 1-3 times a month to check something. The purchasing is different, too. With Member-Based, the company purchases a license for how many users will be accessing the community. With Login-Based, however, the company purchases a number of logins per month. Users who are assigned this license type then consume one of these logins each day they sign in. The way the licenses show up in your Org is also unique: it’s a 1 to 20 ratio. So, if you purchase 1,000 logins per month, the org will get provisioned 20,000 login licenses that you assign to specific users.
#2: Domain Name
While each Org can have up to 100 communities, each with their own unique aliased domain name, the Org itself will have a default domain name that it uses for the base URL for all communities. This is a *.force.com domain like businessname.force.com.
All communities will have a corresponding URL under this main domain as default:
This domain *.force.com cannot be changed after you’ve enabled communities in your Org.
While those URLs are great for testing, they aren’t the best for getting your name and brand out there on its own. Brainstorm ideas for what the domain will be once the community is launched, but also plan for the future. Subdomains I think are the best option here. So carrying on with the above example, let’s pretend our company’s public website is www.businessname.com. A good support community domain could then be: support.businessname.com. Using subdomains for each community saves you the cost of buying more Top Level Domains for each community, and it keeps your communities linked to your main website, too.
As with many things in Salesforce, creating a community in a sandbox instead of production is a safer way to build and test your ideas. This will also allow any code development that is needed to be brought in as well, such as Lightning Components, custom triggers and such.
If you’ve created or updated the community in a sandbox, you’ll eventually want it to be in production. Deploying a community – or, more precisely, community components – can be a little tricky. Here are some things to keep in mind:
- Deploying a community can delete pages. Usually deployments are additive only, but when deploying the main components of the community, it overrides that structure completely. That means pages removed in sandbox will be removed from production.
- Changing the entire community template won’t deploy. If you change the template in sandbox, manually change it in production first before you deploy the community components.
- Deploy profiles and permission sets with the components. As with Custom fields and Objects, if you want permissions to come along, you’ll need to include those Profiles in the Change Set or Package, too.
Audience targeting is also manual. If you have certain pages set to show to certain audiences, those settings will need to be manually set up again after deployment.
Note: there are more caveats and gotchas that Salesforce has compiled in a nice list that I’ll include in the links at the end of this post.
Salesforce communities come with several out-of-the-box templates that give you a great launching point to start your community. All can be customized and branded to fit your corporate colors and logos.