This article was written for the Winter’14 release of Salesforce Communities.

Salesforce Communities is a platform that allows our customers to connect with people outside their organization using data, collaboration, and content. While most Salesforce customers have a decent understanding of Salesforce CRM and Force.com licenses, the license structure for Salesforce Communities is a bit more complex. This article seeks to explain the structure, capabilities, and design philosophy behind the communities licenses as well as the role that legacy portal licenses play in communities.

 

 

Internal and External Licenses

 

Internal licenses such as CRM and Force.com are typically sold to employees who work inside the customer organization. As you embark on your journey to become a customer company, we believe that your employees will be key to your success. That’s why any of your employees and users with a Salesforce internal license can access external Communities at no extra charge. All internal licenses are supported except the Chatter External license.

External user licenses are targeted at people outside your company, such as partners or customers. External licenses include legacy portal licenses and Communities licenses. Users with a portal license can access both portals and communities; users with a community license can only access Communities.

How you provision community users is beyond the scope of this article but it’s worth understanding the basic mechanics. In essence, all you need is a Contact record. From there, select “Enable Customer User” or “Enable Partner User” to create an external user:

Upon clicking, you are taken to the user record page. If you try this out on your org, you’ll notice that the User License and Profile drop-downs are populated with external licenses and their corresponding profiles.

Click ‘Save’ to create the external user.

 

 

Legacy Portal Licenses and Communities Licenses

 

When starting your journey to communities (especially if you’re running our legacy Customer Portal or Partner Portal), it’s important to note a few critical points:

  • We removed the distinction between Partner Portal and Customer Portal. You can mix and match employees, partners, and customers on a single Communities platform.
  • Customers who own legacy portal licenses can continue to renew those licenses and purchase new units of those licenses, or they may purchase new communities licenses.
  • All legacy portal licenses work with Salesforce Communities. In most cases, there is no compelling reason to swap your legacy portal licenses for the new communities licenses.
  • Communities are configured separately from the legacy portals, but have many of the same configuration options. This allows our customers to move to communities when they’re ready.
  • Communities has feature parity with portals. The work you’ve done in portals is not lost when you move to communities, but there are some considerations. Consult the migration cheatsheet for details.

 

Salesforce Communities introduces two new licenses that are intended as long-term replacements for the legacy portal licenses:

  • Customer Communities — our high-volume license
  • Partner Communities — our “premium” license. It has all of the Customer Communities license capabilities plus access to sharing, roles, reports, and dashboards.

 

Each communities license comes in two flavors: member-based and login-based. Salesforce customers who do not currently own legacy portal licenses must purchase the new communities licenses to create a new community. For more details on license capabilities, check the Communities licenses feature comparison.

 

 

 

License Features

 

The Customer Community license is similar to a High Volume Customer Portal license and is well-suited for business-to-consumer communities with large numbers of external users. The Partner Community license is similar to a Gold Partner license and is well-suited for business-to-business communities, such as a partner community.

This table shows which features are available to users with Customer Community or Partner Community licenses.

Our Communities license based offering comes with great features and capabilities:

  • Access to Chatter Answers, Ideas, and Knowledge (read-only) for self-service Communities
  • Read/write on cases and read on accounts and contacts for Customer Communities
  • Access to Chatter to drive social collaboration
  • S1 mobile support (mobile browser) for all members coming in Spring’14 (safe harbor)
  • Access to CRM data (based on sharing settings)

 

Notice the difference in sharing capabilities between the Communities licenses:

  • Customer communities, our high-volume license, does not have access to sharing rules and the role hierarchy. We provide a sharing alternative called Sharing sets.
  • Partner Communities has access to roles (up to three per account) and sharing rules

 

 

Member-based vs Login-based licenses

 

Customer Community and Partner Community licenses are offered as member-based or login-based:

  • A user with a member-based license can log in to communities as often as he wants
  • A user with a member-based license consumes one license per community he is member of
  • A user with a login-based license consumes a login each time he logs in to the community

Once you’ve decided on the right license mix, you need to select a license block size that fits your needs. Salesforce lets you mix and match member-based and login-based licenses of the same type, allowing you to optimize your license allocation based on usage.

Access frequency determines what license model is best. Login-based licenses are well suited for members with infrequent logins to your communities. Member-based licenses are well suited for members who frequently access communities. Administrators can monitor license allocation and usage by using our reporting engine.

Think of it like this:

  • With member-based licenses, you are buying user seats
  • With login-based licenses, you are buying access capacity.

We suggest you consult with your Sales Executive to determine the optimal license mix for your use case.

 

 

How logins get calculated?

 

First, let’s explore how login-based licenses work. With login-based licenses, you purchase an amount of monthly logins for your members. For instance, if you purchased 20K logins, you can use 20K logins every month. The logins consumed reset to 0 at the end of each calendar month.

A login is consumed each time an external user submits his username and password to log into the community (or legacy portal). The same rule applies if the user is accessing Communities from a mobile device. The mobile app consumes a login each time it requests a refresh token.

An org-level perm lets you control the user session duration. This setting applies to all users, external and internal.

 

What happens if I go over my monthly limit allocation?

Don’t worry, we have you covered. We offer a generous login overage consumption policy. You won’t get charged extra as long as:

  • You stay under 300% of purchased login for any given month
  • Or you don’t have three consecutive months of extra usage

Note that we won’t shut down your site when you hit one of those limits.

The flexibility of this model allows you to buy for your average usage instead of buying for your peak usage.

 

Is there a limit on the number of login-based users I can create?

Yes, there’s a 1/20 login to user ratio limit. For instance, if you purchased 1000 monthly logins, you can create up to 20000 users. Customers very rarely hit that limit.

 

Can I report on login consumption?

Yes, you can. All logins are stored in the LoginHistory table for up to three months. You can use the API or standards reports to measure login consumption.

 

 

 

Moving from One License Type to Another

 

You can easily switch users from a login-based to a member-based license, and vice-versa, as long as the user remains on the same license type (Partner Community or Customer Community).

If you own portal licenses, there’s no real benefit to swapping those licenses to Partner Communities or Customer Communities licenses. The Gold Partner license maps to Partner Communities and the HVPU license maps to Customer Communities, meaning that users with those licenses have access to the same feature set. If you own a different legacy portal license type such as Customer Portal Manager, you retain all portal license capabilities when you use this legacy license in Communities.

For more details on how to move from one license to another, check Migrating From Portals to Communities, section User Licenses.

 

 

How many communities do I get?

 

Salesforce provisions one community per Communities license block purchased. It’s usually a good practice to keep communities to a minimum to avoid creating siloed communities and reduce administration efforts.

The total number of communities provisioned is visible in the Communities settings. The field is called ‘Maximum number of active communities’.

It indicates how many communities you can have in status ‘Preview’ or ‘Published’.

Customers with Communities licenses on PROD can perform a Sandbox refresh to get those licenses on Sandbox. Customers on Developer Edition orgs get 10 licenses of each Communities license type:

  • 10 login-based Customer Communities licenses
  • 10 member-based Customer Communities licenses
  • 10 login-based Partner Communities licenses
  • 10 member-based Partner Communities licenses

 

Your Account Executive can help set up a Communities trial on our PROD org.

 

tagged , , Bookmark the permalink. Trackbacks are closed, but you can post a comment.
  • John Szurley

    Great post. Thank you!

  • http://www.streamlineba.com Marc Pellegrini

    Nice explanation of Communities. But, I’d like to share my experience setting up a Customer Community which has been a challenge. The biggest frustration has been that certain advertised features are not actually available. For example, there is NO access to Accounts/Contacts (supposed to be fixed in Spring ’14?) and access to Assets is limited — you can’t search for them in Global Search nor via Lookup and you can’t list them. Sharing records, list views, etc are a challenge — sharing sets have limited options. I hope Spring Release fixes these and other issues.

  • ram_sj

    Thanks for great post in time, I was looking for this answers to be confirmed.