TwinaForms Help
Create From Layout — one click to a working draft.
Create From Layout reads a Salesforce object's page layout and turns it into a TwinaForms Draft — all the layout's elements come over, and the prefill and submit actions are created and wired to every field automatically. Use it when you want a form that already mirrors how your team works with the same record in Salesforce.
What it does
Pick a Salesforce object and TwinaForms creates a new Draft form based on the object's page layout. Every supported element from the layout shows up on the form's canvas, in the layout's order. On top of that, TwinaForms also creates the prefill and submit actions needed for the form to work end-to-end, and sets the aliases on every field so the data flows correctly in both directions.
The output is a regular Draft — edit anything you like before publishing.
How to clone a layout
- Open the Designer page in TwinaForms.
- In the top-right toolbar, next to the + New Form button, click Create From Layout.
- Choose the Salesforce object you want to build the form from.
- Confirm. A new Draft is created and the Designer opens to it.
What gets generated
For a typical clone, the Draft contains:
- An input element for each field on the object's page layout (with the matching input type — text, number, picklist, date, lookup, etc.).
- The layout's sections preserved where it makes sense for a public-facing form.
- A Prefill action, with an alias, that can load the existing record. Every field is mapped to its corresponding source on the alias.
- A Submit action, with an alias, that writes the form values back to the same Salesforce object. Every field is mapped to its corresponding target on the submit alias.
The form is functional immediately after creation — preview it, polish it, and publish.
What's skipped
Two categories of fields don't come over from the layout, intentionally:
- Salesforce system fields — Owner, Created By, Created Date, Last Modified By, Last Modified Date, and System Modstamp. These are managed by Salesforce itself, so they're not surfaced on the form.
- Formula fields — Salesforce formula fields compute their own value server-side, so there's nothing for the visitor to input. They are not included in the cloned form.
Other fields that don't have a TwinaForms equivalent (e.g., Rich Text Area, compound Address, Geolocation, Encrypted Text) are also omitted. Add equivalent plain Text or Text Area fields after the clone if you need to capture similar data.
Multilingual support
The clone is multilingual. When you choose a non-English form language, TwinaForms requests labels from Salesforce in that language, so object, section, and field labels come from your org's Translation Workbench translations when they exist. If a label hasn't been translated in your org, the clone falls back to the base English label — the form is still created, and you can edit the label directly in the Draft.
What to check afterwards
The clone is a strong starting point, not a finished form. Before publishing, walk through:
- Field labels — some internal Salesforce labels are too technical for external users. Rephrase them where needed.
- Hidden / internal fields — the layout may include fields your team uses but visitors shouldn't see. Set those to Hidden behavior or delete them.
- Required flags — required-on-Salesforce isn't always the same as required-for-the-visitor. Adjust per field as needed.
- Submit mode — confirm whether the form should update an existing record only, create only, or update-or-create. You can change this in the Submit Actions tab.
- Submit and prefill aliases — the clone wires every field to the action aliases automatically; spot-check a few to confirm everything looks right.
- Translations — if the Salesforce label for a field hasn't been translated yet and you want it translated, either add it to Translation Workbench in Salesforce or edit the label directly in the TwinaForms Draft.