PersonAccount and Account Object mapping

[afortuna97]

Is your feature request related to a problem? Please describe. We can't write on the Account object's fields (by the flow invoked by SFCC creation/update) instead of on those on the Contact (with PersonAccounts)

Describe the solution you'd like A way to update the Account fields associated with the PersonAccount created by the SFCC connector on SFDC

Describe alternatives you've considered Contact fields (linked to PersonAccount) update, but it's not the best solution

[olegforce]

1. What is the business value or rationale for updating Account fields if you use PersonaAccount setup?
2. What is the functional GAP if you use only Contact fields in the PA scenario?
3. Why usage of Contact fields is not "the best solution" in your perspective?

[nek4life]

We need this functionality too. We have custom fields on Account that need to be updated when a user is created. Currently that is not possible through the mapping object.

The custom fields were added to the Account object prior to having the connector setup and now we have dependencies on them elsewhere so changing attribute the location to the Contact object is not trivial.

[nek4life]

Following up here. The business case for needing this functionality resides in the fact that __pc fields cannot be used when performing an upsert on the Account object and some fields need to reside on the Account object in order to have the ability to upsert these records. The reason for this seems to be that on upsert the underlying Contact object has yet to be created so this operation fails.

Organizations that use the person contact model may choose to put their custom fields on the Account object for this reason. Having the ability to sync fields from Commerce that are used by other integrations to service that depend on having upsert capabilities are a must for this reason.