Community username uniqueness - revisited

Question

Yes, yet another question regarding this subject... But even if there is some information on salesforce forums, I think some of that is outdated (since the Portals became Communities and there were some changes in the few last releases). Maybe someone experienced with Communities in their present state (May 2015) could provide an answer that would be valid for Summer'15 release?

But let's go to the point, let me explain the details:

Our organization has the "ACME" Community created. We need to create "ACME" Community users from Apex (this functionality is exposed to the guest users by RemoteAction calls from custom VisualForce page that has some functionality "injected" by the usage of Javascript framework that makes XHR calls to VF through VisualForce Remoting). That is the technical background.

Now, the external app needs to create a Community user. It uses the email form for the username (eg. "[email protected]"). Under the hood, we are appending the suffix consisting of constant string denoting our community name and InstanceName (eg. EU1) from Organization object. The real SFDC Community username then becomes eg. "[email protected]".

I think that it is enough for providing the uniqueness on production. But what if we have 5 sandboxes, and all of them will land on the same instance, eg. CS15? Will our application be able to create the Community user with name [email protected] on each of the sandboxes?

And what if the other company that uses salesforce will create their community also named "ACME" and this will also land on the EU1 instance? If John Doe would also like to create user with the same name "[email protected]" (let's say this time typed in manually)? Will there be a username conflict (duplicated usernames)?

Answer 1

Each of your sandboxes will have a unique url and as such, each of the test communities for those sandboxes will also have a unique url. I'd recommend you append with the suffix of the sandbox name instead of the server instance, e.g. sb1, sb2, sb3, etc. I can't imagine it being very likely that another company's SF community instance of a company named "ACME" would cause an issue with user names if you took that approach.

It wasn't clear to me, but it sounded as though the basic email user name duplicity was already handled on the ACME domain side, if not, that's where I'd expect the root of most issues to come from.