We have a customized Force.com Site + Customer Portal for the authenticated portion of the Force.com Site. We have self registration enabled. Currently the nickname and alias fields are required on the User. They really don't make any sense for our application and, I'd imagine, not for everyone else's applications, since community nickname and alias aren't industry standard fields required on any other website I've registered for.

Since the alias is not required to be unique, I can simply hack off the first 8 characters or less of the last name and use that which enables me to be able to not present the user with an unnecessary alias field.

However, the community nickname is required to be unique, so it is a bit more tricky. Right now, I just let the user enter something for it, but it doesn't really make any sense, so I'd like to remove it.

1. Is there a way to make the community nickname field not required and/or not required to be unique for customer portal users?

2. If not, what is a good strategy for automatically generating them without having the user ever having to know about them?

For #2, I've thought of two possible solutions:

1. Have a custom setting that contains a number, say nicknameCounter, and use that as the nickname, incrementing it each time that it is used. The problem that I see with this is that it would be possible for a user to get the same number as another user if they both get their numbers before they increment. I could mitigate that by say, prefixing the increment to the first 10 characters of the last name + first 10 characters of the email, etc.

2. I've also thought about adding an autonumber field to the User called nicknameCounter and use that to populate the nickname, but I'm not sure how that will work timing wise.

Surely, other people have this issue. I'd appreciate learning how others handle it.

Thanks!

Attribution to: Peter Knolle

Possible Suggestion/Solution #1

What other information are your users entering?

Could you do combinations? FirstNameLastName_Zipcode or something like that?

Or include the email domain?

Attribution to: Salesforce Wizard

Possible Suggestion/Solution #2

Just use the username provided by the user and time in milisecond. Something like this

DateTime currentTime = System.now(); Long timeInMili = currentTime.getTime()/1000; CommunityNickname = username+timeInMili;

Attribution to: user3430

Possible Suggestion/Solution #3

i think you must be overthinking this. Given that the username is already unique, just copy that to the community nickname via a trigger. that is what has been configured for our customer portal + force.com site. Our users too do not need to know about the community nickname.

Attribution to: Arnaud

Possible Suggestion/Solution #4

I've been through this one. What I used was firstname+lastname. Then before creating the user, the controller checks the database to see if that already exists. If so, then it sticks a 2 on the end. Then check again. Keep incrementing until you're in the clear.

Unless there are hundreds of identically named people, you should not hit the query limit. :)

Attribution to: Shane McLaughlin

Possible Suggestion/Solution #5

Hmm, the docs seem to say that:

All requests are delimited by the trigger, class method, Web Service, Visualforce page or anonymous block that executes the Apex code. If the entire request completes successfully, all changes are committed to the database.

So for certain definitions of delimited by...class method a single method that inserts against a utility table containing just an autonumber name that is then deleted at the end of the method before returning its name value should provide you with a valid numeric nickname with zero rows used at the cost of 3 DML operations: one insert, one query and one delete.

Alternatively you could schedule apex job at crazy o'clock that deletes all save one max(name) row, saving you one Delete DML statement.

If you wanted to get crazy about it.

Attribution to: Baxter

Possible Suggestion/Solution #6

As you say the field is unique but does not apply to Portal customer. Given this we are using the SFID for the contact. We know it is unique by design and saves retrying for erros

Attribution to: NeilM
This content is remixed from stackoverflow or stackexchange. Please visit https://salesforce.stackexchange.com/questions/305