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.