A document is a form, and fields are how you build it

When people picture an e-signature, they picture the signature box. But a well-built signature request is really a small form: a set of fields placed exactly where the signer needs to act, each one telling the signer "do this here." Get the fields right and signing is a guided two-minute glide; get them wrong — a missing date field, an ambiguous text box, a required field nobody can find — and the signer stalls, emails you a question, or signs the wrong thing.

This is a plain tour of the field types you place on a document, what each one is for, and how to choose between them. It builds on placing fields efficiently with reusable templates and field-tag auto-placement — this article is about which fields, those are about placing them at scale.

Signature and initials

The two fields at the heart of every request:

  • A signature field is where the signer adopts the document. They sign it once per signature field — typed in a font, drawn with a finger or mouse, or applied from a saved signature, all equally valid under US ESIGN and UETA when the signer intends to sign.
  • An initials field captures a lighter-weight mark, used where a full signature would be overkill but you still want the signer to actively acknowledge a specific spot — the bottom of each page, a particular clause, an acknowledgment line.

The distinction is more about signal than legal weight: as covered in signature vs. initials, a signature says "I adopt this whole document," initials say "I specifically saw and accept this." Use initials to draw the eye to a clause that matters, not to litter every page out of habit.

Date, text, and the data fields

Around the signature sit the fields that capture information:

  • A date-signed field stamps the date automatically when the signer completes the document — you don't ask them to type it, and they can't backdate it. This is the right way to record when; see adding a date-signed field for why an auto-stamped date beats a typed one.
  • A text field collects free-form input — a title, an address, an account number. Where you already know the value, prefer a merge field that arrives prefilled over asking the signer to type it.
  • A name or title field can auto-fill from the recipient's details, so the signer confirms rather than retypes.

The guiding principle: make the signer type as little as possible. Every text field is a chance for a typo and a moment of friction.

Checkboxes and dropdowns: capturing choices

Some documents need the signer to decide, not just sign:

  • A checkbox records a discrete acknowledgment or election — "I have read the disclosure," "Add the optional warranty." It produces a clean yes/no in the record, which is exactly what you want to be able to prove later — paired with a versioned consent disclosure, a ticked box is strong evidence the signer affirmatively agreed.
  • A dropdown (or radio group) presents a fixed set of options and records which one the signer chose — a plan tier, a payment cadence, a jurisdiction. It keeps the answer constrained to valid choices instead of free text you'd have to interpret later.

These fields turn a signature request into a lightweight intake form, capturing structured decisions alongside the signature rather than chasing them in a separate email.

Required vs. optional, and assigning fields to recipients

Two settings quietly govern how a multi-field document behaves:

  • Required vs. optional. A required field blocks completion until it's filled — the signer literally cannot finish while a required signature or checkbox is empty. This is your guarantee that nothing essential gets skipped. Mark optional only what truly is.
  • Recipient assignment. On a multi-recipient envelope, each field is assigned to a specific signer, so the buyer sees only the buyer's fields and the counter-signer sees only theirs. A field assigned to the wrong recipient is a classic cause of a stuck request — the person who could fill it never sees it.

Getting these right is most of what separates a request that completes cleanly from one that generates support questions.

Conditional fields: showing fields only when they apply

The most powerful field behavior is conditional logic — a field that appears (or becomes required) only when another field has a particular value. Tick "Yes, I want the add-on" and the add-on detail fields appear; choose "Wire transfer" from a dropdown and the bank-detail fields unfold; leave them unselected and the signer never sees clutter that doesn't apply to them.

Conditional fields matter because they let one document serve branching cases without forcing every signer through every field. The alternative — multiple near-identical documents, or a single form bristling with "leave blank if not applicable" fields — is slower for the signer and messier in the record. With conditional logic, the signer sees a document tailored to the path they're actually on, and the completed record contains only the fields that were genuinely in play.

A note on the record: whatever fields a signer fills, the hash-chained audit trail captures the document exactly as completed and seals it, so the conditional path the signer took is part of the permanent, verifiable evidence.

Choosing well

The skill is restraint. Place the fields the document genuinely needs — signature where adoption happens, initials where you want focused acknowledgment, an auto-stamped date, checkboxes for the decisions that matter — assign each to the right recipient, mark the essentials required, prefill what you already know, and use conditional logic to hide what doesn't apply. The result is a request the signer can complete without thinking and a record that's clean to read back. Build it once as a template and every send inherits the layout. Try it free and place your first set of fields.

This article is general guidance, not legal advice; confirm what your specific documents require with your counsel.