+ Start a Discussion

Site.createPersonAccountPortalUser returning null


We've been finding that, intermittently, the Site.createPersonAccountPortalUser(userObj, newUserOwnerId, recordTypeId, password) method is retuning a null value, instead of a valid Id for a new User record. No exception is thrown; just a null value is returned.


When this happens we look at the org and find that a User record WAS inserted, as well as *multiple* Account records.


We have been unable to reproduce this using identical input data. 


Has anyone else seen this behavior? 


Has any progress been made here?  I'm running into the same thing, except nothing is getting created.


No. Went up thru SFDC support but no help. It's a bug. Finally had to do something on the client side to minimize the problem. Here's the full story (I wrote up an article to blog but never posted :P )


Site.createPersonAccountPortalUser Misfires

Sometimes the API doesn't tell you the whole story. Documentation on the Apex Site class method, createPersonAccountPortalUser(), is an example.

According to the doc, createPersonAccountPortalUser() will return an ID for the User that has been created. Sometimes, though, the method will return null. It will appear to execute successfully with no exceptions being thrown but the ID is simply null. Why?

The background code checks or is otherwise subject to system validation rules. To be expected, right? So if there's a validation problem due to a, say, a duplicate username, the User will not be created. The Site admin may even get an email like:

There was an error in registering a user in site Your_Portal. The error message is: Duplicate Username.<br>Another user has already selected this username.<br>Please select another.

The trick is that no exception is thrown by createPersonAccountPortalUser, just a null ID. You apex code doesn't know anything has gone wrong and proceeds accordingly.

In addition to returning a null value, though, createPersonAccountPortalUser appears to *create a Person Account record* anyway. This may be due to the out specific use case (see below) but be forewarned.

Moral? Always null-check the returned value. If null is returned, check for this condition. Better yet, check possible validation violations before kicking off this method. Best, it may be difficult to anticipate them all, so do both.

More details

In our case this came up when providing a self-registration form. This is the typical use case, I assume. We found when going to production that two situations might cause this problem to surface.

First, users are lovably capricious. Give them a button and they might click once, twice, twenty times before the Sites portal has a chance to process the request and respond. If you're button uses an ajax-driven command link, like ours did, you need to be ready for multiple, identical requests.

Second, granted users are unpredictable, in our observations this happened much too consistently to be users every time. We found that well over half the time the ajax call hit the server exactly twice. Something about the client-server chain was causing the Site to want to run the request twice.

Whatever the cause, if you use createPersonAccountPortalUser() in a method called with an ajax-driven Visualforce component, be aware of misfires not readily apparent in the API.


The method can return null if the user is already logged in. One thing to do would be to validate the user is a guest user before calling Site.createPersonAccountPortalUser


Also might return null if there was an error creating the account.


Do you have any other debug information?