The form worked. Salesforce got a second copy of the same person.

With a lookup that runs before the write, and an explicit decision about what happens when it finds nothing, one record, or several. The connector can search Salesforce on whatever combination of fields identifies a person in your business, then create or update depending on the result — and each lookup carries settings for the multiple-records case. The failure we see most often is a connector configured only to create, because it was built and tested with data that had never been submitted before. Deduplication is a design decision made before mapping, not a cleanup job afterwards.

Yes. A prefill connector reads existing Salesforce data when the form opens, so a known person is not asked for what you already hold. It can pull from related objects and records as well as the primary one, and a single URL parameter can drive a prefill that reaches across several objects — which keeps the link short while the connector does the work. Prefill is also a data-quality control, not just a convenience: a respondent confirming existing values produces far cleaner records than one retyping them.

A dynamic picklist builds a form's dropdown options from live Salesforce data instead of a list typed into the form. Options can come from a Salesforce picklist or from a live lookup based on other fields on the form. Use them wherever the list changes without anyone remembering to update the form — programmes, campaigns, locations, product catalogues, assigned staff. Static copies of those lists are the usual reason a submission arrives with a value Salesforce no longer accepts.

Yes. Record creation can be made conditional, so a submission writes an object only when the data warrants it — a skip formula on the connector step is the usual mechanism. This matters for related records: creating an empty child object on every submission because a section was left blank produces a Salesforce report nobody trusts. The condition belongs on the connector rather than in the form, because it is a statement about the record, not about what the respondent sees.

It depends on the stage the connector runs in and the error-handling option chosen. The connector logs every run, and a failing step can be configured to end execution and return an error rather than letting later steps continue against a record that was never created. A failed response can be corrected and reprocessed afterwards, in bulk on Essentials plans and above. The design decision is who finds out: a connector in the after-submitted stage runs once the respondent has already seen the thank-you page, so nothing tells them, and only monitoring will.

Almost always because Salesforce changed, not FormAssembly. A retired picklist value, a newly required field, a tightened validation rule, a changed record type or a permission adjustment on the integration user will all stop a mapping that was correct when it was built. Nothing in the form changed, so the form is the last place anyone looks. The fix is usually in Salesforce, and the durable fix is a change-control habit: whoever owns the org needs to know which fields a connector depends on.

Both are supported and the choice is organizational rather than technical. FormAssembly's AppExchange app lets users reach their FormAssembly account from inside Salesforce without a separate login, which suits teams who live in the CRM and want form building next to the records. Working in FormAssembly directly suits teams whose form builders are not Salesforce users — marketing, programme or admissions staff. The connector behaves the same way either way, so this is a question about who builds forms, not about capability.