With the shift from Portals to Communities, salesforce.com delivered an attractive package of changes and improvements for a critical feature. However, one subtle change in Communities produced significant implications for Portals-to-Communities migrations and new Communities implementations: the username namespace.
What do you do with usernames that were once acceptable but can no longer be used? And how do you prevent future collisions with other companies and their communities, so that we all play nicely as multi-tenants in the Salesforce world?
In short, there are a few options you can adopt, depending on your use case and appetite for supporting customizations:
- The domain-qualified username; or
- The community-qualified username; or
- A (domain-community-qualified) hybrid username using both of the above schemes, and probably the best option of the three
All naming conventions are described below, and in all options the optimal implementation requires that you create a custom login page.
Background
Every username has an interesting property: The username must be unique within a given namespace or context. For example, you and I can both use the username "superuser", if you register "superuser" with Twitter and I register "superuser" with Instagram. In this case, Twitter and Instagram represent two unconnected namespaces. But as soon as you try to register the same username with Instagram, you'll get an error telling you that the username is already taken (by me).
Salesforce used to have separate namespaces for every single portal. This means that I could log into my company's org as martyc@slalom.com and also log into a partner portal as martyc@slalom.com, even though the usernames were identical. The reason is that in the Portals age, Salesforce considered my company's org and the partner portal as distinct and separate where usernames were concerned.
But with Salesforce Communities, usernames are all of a sudden pooled together into redesigned namespaces. Partner Community usernames now exist in a namespace that is shared among all internal organizations and partner communities, even including salesforce.com's own Partner Portal. On the other side, the namespace for Customer Community usernames is unique for each org, but the namespace includes Partner Community and internal usernames within the same org.
Companies that want to create a consistent customer or partner experience should choose a naming convention that minimizes the likelihood of username collisions.
Edit: Customer Community usernames share a namespace with other Partner Community and internal usernames within an org, but not with other orgs. The post originally stated that Customer Community usernames were pooled together with Partner Community usernames and internal usernames across all orgs. Props to Andy Ognenoff for noting this inaccuracy!
Domain-Qualified Usernames
The domain-qualfiied username is a naming convention where a community user's username also contains that user's email domain. For example, John Smith is a Salesforce user at Acme Corporation, which has a partnership with the Zenith Group. Knowing that John's regular username is jsmith@acme.com (also his email), Zenith's admin sets John's partner community username to be jsmith.acme.com@zenith.com.
Effectively, the domain-qualified username contains the following elements, which can be joined and transformed as you wish. The example above shows a period between the partner's prefix and domain, with the parent company's domain coming last.
- Customer/partner email prefix (e.g., jsmith)
- Customer/partner email domain (e.g., acme.com)
- Parent company's domain (e.g., zenith.com)
For best results, you should implement a custom login page that accepts the user's email as the username, transforming that email to the community username behind the scenes.
| Sample Community Login URL | What the User Enters | Username Stored in Salesforce | Sample Email |
|---|---|---|---|
| https://zenith.force.com/partner/login | jsmith@acme.com | jsmith.acme.com@zenith.com | jsmith@acme.com |
| https://zenith.force.com/partner/login | martyc@slalom.com | martyc.slalom.com@zenith.com | martyc@slalom.com |
Community-Qualified Usernames
The community-qualified username is a naming convention where a community user's username contains an additional "subdomain" after the '@' symbol. For consistency and easy decision-making, you can adopt a community's URL path as the subdomain. For example, Jane Doe is a customer of two divisions within Gamma Corporation, and Jane is also a customer of the Delta Group. Jane logs in as "jdoe" to all three communities, even though Jane's true usernames for the three communities are:
- jdoe@products.gamma.com
- jdoe@services.gamma.com
- jdoe@my.delta.com.
As you can see, the usernames only differ in what comes after the '@' symbol. In this case, they key components in the username are:
- Unique prefix (e.g., jdoe), self-selected by the user or auto-assigned by the parent company
- Unique community subdomain (e.g., services.gamma.com), which includes the parent company's primary domain
Again, for best results, you should implement a custom login page. This time the custom page should accept the unique prefix (that comes before the '@' symbol) as the username, and then add on the community subdomain behind the scenes.
| Sample Community Login URL | What the User Enters | Username Stored in Salesforce | Sample Email |
|---|---|---|---|
| https://gamma.force.com/products/login | jdoe | jdoe@products.gamma.com | jane.doe@gmail.com |
| https://gamma.force.com/services/login | jdoe | jdoe@services.gamma.com | jane.doe@gmail.com |
| https://delta.force.com/my/login | jdoe | jdoe@my.zenith.com | jane.doe@gmail.com |
Hybrid Usernames
The (domain-community-qualified) hybrid username is a naming convention that combines the elements of both the domain-qualified username and the community-qualified username. As a result, the hybrid username can provide the following benefits:
- Intuitive username for the customer or partner. Customers and partners can log in using their emails.
- Minimized risk of duplicate usernames, across all Salesforce orgs and communities
Inside an org, every community username contains:
* Customer/partner email prefix (e.g., jsmith)
* Customer/partner email domain (e.g., acme.com)
* Unique community subdomain (e.g., services.gamma.com), which includes the parent company's primary domain
Due to the complexity of the stored username, you must implement a custom login page to succeed with this option. The login page should accept the user's email as the username, again transforming that email to the community username behind the scenes.
| Sample Community Login URL | What the User Enters | Username Stored in Salesforce | Sample Email |
|---|---|---|---|
| https://zenith.force.com/partner/login | jsmith@acme.com | jsmith.acme.com@partner.zenith.com | jsmith@acme.com |
| https://zenith.force.com/customer/login | martyc@slalom.com | martyc.slalom.com@customer.zenith.com | martyc@slalom.com |
| https://gamma.force.com/products/login | jane.doe@gmail.com | jane.doe.gmail.com@products.gamma.com | jane.doe@gmail.com |
Other schemes?
If you have other user naming conventions or username schemes for Salesforce Communities, please share them in the comments below!
