Fields not being created in other object

[Mike-Cleaver-LB]

We are setting up person accounts
logging:
Submitted Values: {Birthdate__c=1987-12-10, CommunityNickname=mike qattest3, Email=[email protected], FirstName=Mike, LastName=Cleaver, Marketing_Optin__c=true, MobilePhone=002211, confirmPassword=HIDDEN, password=HIDDEN}
Record Id found was: null
About to create new Person Account
Person Account to create: (Account:{RecordTypeId=012Mn000000byhxIAA, FirstName=Mike, LastName=Cleaver, Marketing_Optin__c=true})****

I can't work out why the extra fields aren't being mapped. email, mobile are the important ones. We're also missing the marketing opt in (which is the same API name in both object).

what i can see in the code is

Configurable-Self-Registration-for-Experience-Cloud/Configurable Self Registration LWC/Custom Registration/force-app/main/default/classes/SiteRegistrationController.cls

Line 261 in b247d4d

if(checkFieldExists(objectMetadata, fieldName)) {

this checks if the field exists on the account object, which it doesn't; mobile and email are personmobile and personemail so my understanding is the code never assigned those values. I don't understand why the marketing optin fields doesn't map as that exists the same in both account object and user. Community nickname also doesn't save in the user record.

1.88, clean install.

[Mike-Cleaver-LB]

the logging shows the mapping of marketing optin happened but the record doesn't have the checkbox set

[Mike-Cleaver-LB]

I have worked around the person account fields not populating, however, I would still like to know if the communitynickname can be correctly populated in the user record, currently it is defaulting the siteuserXXX value
[edit] is it because of this line? user.CommunityNickname = 'SiteUser' + System.now().getTime();
Seems to hard set the nickname even if specified in the custommetadata?

[jlowe-SFDC]

@Mike-Cleaver-LB - where is the field created for the Person Account? Is it on the Account or Contact object? I've seen this before, where a customer created a custom field on the Contact for a similar field, and to populate it via the form you have to use the field reference with "__pc" not "__c" as the Account is a combination of both records. The checkIfFieldExists() method will then work as intended.

Note though that the same limitation applies as before on this, in that this might not map to the user correctly if its Contact and thus has the "__pc" suffix as a field on a user can never have this type of field. In this respect, I really think you need to separate out concerns and not try to handle some of these mappings to the user object via the component and have a separate solution if this is the record that will be maintained in your Exp Cloud site.

As for the Community Nickname, you're right in that you can't override this currently. Its hardcoded to the value in the code:
user.CommunityNickname = 'SiteUser' + System.now().getTime(); and it processes the form inputs just before this so it means the hardcoded value overrides whatever is submitted.

Changing it to something like this might work but I haven't tested it:
user.CommunityNickname = String.isBlank(user.CommunityNickname) ? 'SiteUser' + System.now().getTime() : user.CommunityNickname; - alternatively, I wouldn't get the user to provide that during registration and provide a method to do this once logged in. You can maybe handle this via a Login flow so they are prompted to set it during first login?

For Email/Mobile - use "Email" or "Mobile" as the API field names in custom metadata and the controller will map them automatically to the Person Account fields for PesonEmail and PersonMobile. It will also then successfully map them to the user.

Possibly a bug here, in that the logic should be MobilePhone... might need to change this. Let me know.

[Mike-Cleaver-LB]

All the fields are on the account object. so the __c mapping should be fine.

As for the mapping, won't the checkfieldexists return false because the account doesn't have email or mobile?
I used whatever metadata was supplied for the email and mobile.

i have added, as part of my PR, a code change to allow entering of the community nickname

[jlowe-SFDC]

I'll look back at the previous appExchange release (v1.8) before all of the passwordless and latest changes as I could swear this was working previously!

[jlowe-SFDC]

For the field check, the 'Email' > 'PersonEmail' field was actually outside of the checkExists() method call! So I've broken that...

There was never the same for mobile so that is new, but the same change applies to get it working again I think. It should also be 'MobilePhone' as the field name it looks for. Could you try making this change in your version to see if this fixes that part?

[Mike-Cleaver-LB]

it's from the package and is mobilephone, so that's already correct I think
**

**

[jlowe-SFDC]

I've done some more testing this side.

In the latest version, I definitely broke the logic for mapping the packaged metadata fields to a Person Account. As you mentioned, the code was checking for 'Email' and 'MobilePhone' against the Account object which don't exist. They are called PersonEmail and PersonMobilePhone when using Person Accounts. So the logic for mapping the packaged fields to the appropriate Person Account fields never happens. It's an easy fix by moving the logic outside of the checkfieldexists method... The change is:

I've also tweaked the logic so that it references 'MobilePhone' and not 'Mobile'.

For the checkbox called Marketing Opt In mapping issue. It's likely to be permission related. I managed to reproduce it in my environment. The code is stripping inaccessible fields after it logs the "Person Account to create" so what you see there isn't necessarily what gets mapped if your guest user doesn't have access to the Marketing Opt In field...

SiteUtilities.messages.add('Person Account to create: ' + newPersonAccounts);
SObjectAccessDecision securityDecision = Security.stripInaccessible(AccessType.CREATABLE, newPersonAccounts);
srList = Database.insert(securityDecision.getRecords()[0], false);

To fix it, check that you have added the read/edit access to the "Custom Self Registration - Guest Access" Permission Set and ensure that is assigned to the site's guest user. I have added some logging into the custom object so its obvious that's what its doing and update the documentation.

[jlowe-SFDC]

I've checked in v1.89 branch with the changes mentioned in this issue. It'll go on the AppExchange soon but available here.

[Mike-Cleaver-LB]

tested with 1.89 it is still not creating a person account with all supplied details.

Custom field (marketing_optin) is working by the looks

Submitted Values: {Birthdate__c=1990-01-16, CommunityNickname=PartialMatchTest, Email=test+uatdup@domain, FirstName=Partial, LastName=Newname, Marketing_Optin__c=false, MobilePhone=0422062145, confirmPassword=HIDDEN, password=HIDDEN}
Record Id found was: null
About to create new Person Account
Person Account to create: (Account:{RecordTypeId=012Mn000000byhxIAA, FirstName=Partial, LastName=Newname, Marketing_Optin__c=false})
Created Record Id returned was: 0018r00000ZTaHBAA1
External User Id created was: 0058r00000AafzmAAB
User successfully registered and was logged in.

[jlowe-SFDC]

What fields are not being mapped correctly in your example? In my tests, it works to map the mobile phone and email as per above comment with the logic change.

In your unmanaged version, have you tried looking at the full debug logging to see if there are any errors on create that aren't being output in the custom object? Initial thoughts are that maybe its the record type Id that the guest user doesn't have access to or those Email/Phone fields are not granted. The logs should output those in the new logging logic I added with the removedFields() method call. Without access to your org or full logging its hard to suggest what else it could be as this is now working as designed for me.

[Mike-Cleaver-LB]

yeah sorry. I will have a deeper dive into this.

[Mike-Cleaver-LB]

So in the example above it is missing the email and phone number which are standard metadata records provided by the managed package. I will try with my dev org shortly and see if i can't get that replicating the issue or work out what's different. I had a look in the quip and couldn't see any special migration steps between 1.88 and 1.89 so assume the same component works etc.

[Mike-Cleaver-LB]

I can confirm the repo version deployed directly works correctly. So either 1.89 hasn't got that fix or the 1.89 isn't in use in our community some how. I will try and re-publish and see if that fixes anything

[EDIT] redeploying didn't fix
the data sent from the component is not mapped to the person account in 1.89 as far as I can see.