The top section of the toolbox lists every Record Type in the system. Expanding one shows its fields, and those fields can be dragged onto the form exactly like the fields in the other toolbox sections.


Building forms this way is worth the habit. A field dragged in from a Record Type arrives already configured to match the record: it is the right kind of field, it has the right name, it is already set to save into the record, and any list of choices it has is already filled in. A field dragged from the Input Fields section instead has to be set up by hand, and a single typo in the Field Name means the answer is written to the wrong place - or to nowhere useful - without anything on screen looking wrong. Set the Record Type up first, then build the form from it.


What arrives with the field

Each Record Type field becomes the E-form field type that matches it:

  • A Text field, or any type with no closer match, becomes a Text field.
  • A Numeric field becomes a Number field.
  • A Date field becomes a Date field.
  • A Yes/No field becomes a Checkbox.
  • An Option field, in any of its forms, becomes an Option List.
  • A Multi-Option field becomes a Multi-Option field.
  • A User List field becomes a User List field.
  • A Linked field becomes a Linked Field.
  • A Hidden field becomes a Hidden field, with Always Use Latest Record / Form Value already turned on so it always reflects what the record holds now.


Whichever type it is, these are set for you:

  • Save to Record is on, so the answer reaches the record without anyone having to remember.
  • The Field Name is the Record Type's own field name, spelled exactly as the record expects it.
  • The Field Label is the Record Type field's heading, so the form asks the question the same way the record screen does.
  • The Default Value is the one defined on the Record Type field.
  • The field is stamped with the Record Type it came from, which is what lets the designer keep it in step later.


Everything else - where the field sits, how wide it is, whether it is required, its conditions - is yours to set as normal, and is described in Common Field Settings and Field Conditions.


Option lists stay in step

An Option or Multi-Option field dragged in from a Record Type arrives with its choices already filled in and with Sync Options With RecordType turned on. That setting means the list is refreshed from the Record Type every time the form is loaded, so a choice added to the Record Type appears on every form that uses it without any of those forms being opened and re-saved. This is the single biggest reason to drag option fields from the Record Type rather than build them by hand.


If a particular form needs a list of its own - a shorter set of choices, or wording that only makes sense on that form - you have two ways to break the link: turn Sync Options With RecordType off on the field and edit the list, or drop a plain Option List from the Input Fields section and fill the choices in yourself. Editing the list while the setting is still on achieves nothing, because the next load overwrites it.


A Cascading Option field brings its limiting values across as each choice's Filter value. Point the field's Filter Options By setting at whichever field on the form supplies that value and the list narrows itself as the user answers, the same way it does on the record screen.


Linked fields bring their whole setup

A Linked field is the one that saves the most work. It arrives with the record type it looks into, the field whose value is saved, the field the user sees, the auto-populate mapping that fills in other fields when a value is chosen, the limits on which records are offered, and the search behaviour - all copied from the Record Type. A lookup that took a page of settings to configure once is a single drag on every form after that, and it stays consistent everywhere it is used.


Line item fields

If the Record Type has line items, the list shows those fields too, and below them a ready-made LineItems table.


Drag the table on and you get the whole line item entry area in one go: a column per line item field, in order, each already the right type, with a first row primed with the defaults. Numeric columns come set to two decimal places with a Sum in the footer, so an amount column totals itself. The table can add rows, shows its footer, and is marked as a line item table, which means its rows are written to the record's line items rather than being kept as an ordinary table inside the form. This is what makes the rows show up as line items on the record afterwards.


The individual line item fields are also listed separately, above the table. Dragging one on its own gives you a plain field with that name, not a line item; use them only where a single value from the set is genuinely wanted somewhere else on the form, and use the LineItems table for entry.


Using a field more than once

Ordinary fields are renamed automatically when the same one is dropped twice, so a second Amount field becomes Amount1 and the two stay separate. Record Type fields are deliberately exempt: drop the same one twice and both keep the record's field name. Both then read and write the same record field, which is how a value can be shown on one page and confirmed on another, or repeated in a summary at the end of a long form.


Starting a whole form from a Record Type

For a form that is mostly just the Record Type's fields, there is no need to drag them one at a time. On the E-form list, the arrow beside the New button opens a list of Record Types; choosing one creates a new form with every field already on the first page, and the LineItems table after them if the Record Type has line items. The form is named after the Record Type with a short unique suffix.


What it gives you is a starting point, not a finished form. It has no headings, no layout and no containers, and the form's own settings - its name, which Record Types it belongs to, where it is shown, and how it saves - still have to be filled in. Treat it as a way to skip the tedious part and then arrange the form properly.