Person accounts

If your org uses person accounts, a form that maps anything onto Account has one extra decision to make. This page is only relevant on those orgs.

Two Account entries in the picker

The mapping picker’s object list carries two Account entries: Account, a business account, and Person Account. They write to the same place, but they offer different fields, because the two kinds of account genuinely accept different ones.

Entry	What it offers
Person Account	The person fields (Person Email, Person Mobile, First Name, Last Name, Salutation, and any field you added to Contact), plus every ordinary Account field a person account also carries, such as Phone, Billing City and Owner
Account	The ordinary Account fields only. The person fields are hidden, because a business account cannot store them

Picking Person Account also sets this form’s Account record type to Person Account, saved with your next Save draft. The panel says so when you pick it. That pairing is the point: choosing the fields and choosing the record type separately is how forms end up contradicting themselves.

The record type must be chosen, even with one active

On a person-account org, an Account-mapped form must choose its record type before it can publish, even when only one Account record type is active. Elsewhere a single record type is its own answer. Here it is not: with nothing chosen, the platform falls back to the record type of whoever processes the submission, which decides business-versus-person by accident.

Choose it in Settings, under Record types.

Publishing is refused if a Business Account form maps a person field. The message names the offending fields. Fix it by choosing Person Account in Settings, or by mapping those questions elsewhere.

Full name on a person account

A single full-name question mapped to Account.Name is split across First Name and Last Name when the form creates a person account, exactly as it is on Contact: Ada Grace Lovelace becomes First Name Ada Grace and Last Name Lovelace. The picker marks that field split into First / Last so you can see it will happen.

Matching stays inside the kind of account the form creates

A Person Account form that matches on, say, phone number will not adopt a business account that happens to share it. It creates a new person account and leaves the business one alone. See Matching: update instead of duplicate.

If processing fails with a field error

Two error messages point back to this page, and both should only reach forms built outside the builder, by blueprint import or a data load, because the picker and the publish check prevent them otherwise:

The submission’s error says	What it really is
Bad field names on insert or update, naming a person field	A person-only field is being written onto a business account. Set the form’s Account record type to Person Account, or map those questions elsewhere
Unable to create or update Name, with wording about security settings	Despite the wording, not a permissions problem: a full name is being written whole onto a person account, which stores First and Last instead. Choose the Person Account record type and the value is split for you