Mapping fields to Salesforce

Mapping is what turns an answer into data. Each field can be mapped to a Salesforce Object.Field target, and processing uses that mapping to decide where the answer lands.

Note: mapping decides what processing writes. It does not change what a respondent sees, and an unmapped answer is still captured and still visible in the responses console. See Processing responses onto records.

Map a field

1. Select a field on the canvas.
2. In the inspector, next to Salesforce mapping, click Map field.
3. Pick an object in the left column, then a field in the right column. Use the search boxes to filter long lists.

The picker stays inside the inspector panel, and long object and API names wrap rather than being clipped, so the list stays usable however deep your schema goes.

The picker only lists what you can actually write. If an object or field you expect is missing, your user has no access to it: ask an admin, or pick a different target. A mapping that arrives another way, from an imported blueprint for instance, and names a read-only field is refused outright, with a message saying the field is not writable and cannot receive submitted values.

New forms start unmapped, including every one of the ready-made starters. See Mapping a starter form for the recommended mapping for each of them.

Review every mapping at once

Deselect everything on the canvas and use View field mappings under Data on the right rail. The Field mappings overview lists every mapped field in one place: label, type, its target chip, and a match badge on any field ticked for matching. Click a row to jump to that field’s settings.

Check this list before publishing. A field you meant to map and did not, or a match flag ticked by mistake, is easy to miss when reviewing fields one at a time and obvious in the overview. Publishing also warns you when fields are unmapped, telling you how many of how many.

Where a form maps to more than one object, two more settings follow from your mappings: record types and the form’s object model. On an org that uses person accounts, mapping anything onto Account has one more decision attached to it: see Person accounts.