← All help topics

TwinaForms Help

Submit actions — write form data back to Salesforce.

A submit action defines what TwinaForms does in Salesforce when a user submits the form: create a new record, update an existing one, find-and-update a match, or save many rows from a repeat group. A single form can run several actions in sequence, with each one feeding into the next.

How it works

When a user clicks Submit, TwinaForms runs your submit actions server-side in the order you set. Each action chooses a Salesforce object and a command (create, update, find-and-update, save records list), then writes the form values into the Salesforce fields you've mapped.

A typical example: a customer fills in a "Contact us" form. A submit action takes those values and creates a new Case in Salesforce with the Subject, Description, and SuppliedEmail populated — ready for your support team to triage.

Build a submit action

Open the Submit Actions tab inside the Designer and click + Add submit action. You'll choose three things:

  1. Command — what TwinaForms should do in Salesforce.
  2. Salesforce Object — the target object (Case, Contact, Opportunity, etc.).
  3. Field mappings — which form values write to which Salesforce fields.

Command types

  • Create record (create) — insert a new record. Map form fields to the new record's fields.
  • Update by Id (updateById) — update an existing record. You provide the record Id, usually from a hidden field, a URL parameter, or a prefill alias.
  • Find and update (findAndUpdate, Pro) — query Salesforce with match conditions, then update the first matching record. Optionally fall back to create if no record is found.
  • Save records list (upsertMany, Pro) — save multiple rows from a Records List (repeat group) element. Each row becomes a child record under a parent.

Match conditions (for find-and-update)

If you chose Find and update, you also set match conditions — they work exactly like prefill conditions. A condition compares a Salesforce field to a value source:

  • URL Parameter — from the form URL's query string.
  • Form Field — the current value of a field on the form.
  • Literal Value — a fixed string or number.
  • Alias Reference — a field from an earlier prefill or submit action.

If multiple records match, TwinaForms updates the first one. Set "If no match found" to either fail with error or create instead, depending on the behavior you want.

The alias — "Store result as"

Every submit action can store its result under a name you choose — the alias. The alias is how you reference the produced record later, either from a follow-up submit action or from a prefill action in a multi-step flow.

For example, a submit action that creates an Opportunity might use newOpp as its alias. A later action can then reference newOpp.Id as the parent for Opportunity Line Items, or newOpp.AccountId to update the related Account.

Naming tip: use clear, intentional aliases like newCase, updatedContact, or opp. They'll appear in dropdowns when you configure the next action, so a useful name saves time later.

Map fields to Salesforce

Mapping happens inside the action's configuration panel. For each form field you want to write to Salesforce, add a row pairing it with a Salesforce field on the target object:

  1. Open the submit action in the Submit Actions tab.
  2. Scroll to the Field Mappings section.
  3. Click + Add mapping.
  4. Choose the Form field from the dropdown (e.g. email2).
  5. Choose the Salesforce field on the target object (e.g. Case.SuppliedEmail).

Only mapped fields are sent to Salesforce — everything else on the form is ignored by this action. Form fields that aren't mapped to anything are still useful: they may participate in formulas, conditional logic, or other submit actions.

See all mappings at a glance: the Submit Actions tab's right panel shows a summary of every form-to-Salesforce mapping for the current action. Useful for reviewing or auditing all mappings at once without scrolling through each one.

Chain actions with the alias

A form can run several submit actions, in the order you set. Each action stores its result under an alias, and later actions can reference that alias to pick up the produced record's Id or any of its fields.

A common pattern is creating an Opportunity, then creating its line items:

  1. Action 1 — Create an Opportunity. Store result as newOpp.
  2. Action 2 — Save records list on Opportunity Line Item, mapping the Records List rows to OLI fields. Set the parent relationship to OpportunityId = {newOpp.Id}.

If an earlier action fails, the later ones don't run. Use this to your advantage — put validation-sensitive work first so the rest only runs after the parent record is safely created.

Test before publishing

The fastest way to validate a submit action is to publish to a sandbox or scratch org, submit the form once with sample data, and inspect the result in Salesforce. Then check the form's Submission Logs in the Designer — the log records every action that ran, the Salesforce Ids produced, and any errors with messages from the Salesforce API.

Common errors:

  • Mapping to a Salesforce field that doesn't exist (typo or deleted field).
  • Missing a required Salesforce field that wasn't in your mappings.
  • Trying to update a record the running user doesn't have access to.
  • Using an alias reference that didn't get a result — for example, the prior action failed or returned nothing.
Heads up: field mappings are validated at publish time, not while you edit. A typo in a Salesforce API field name won't be caught until the form goes live and a submission fails. Always test once before sharing a form publicly.