Understanding Signature Field Configuration

What it is

Every signature field has a Signature Field Configuration panel in the form editor. It holds one setting: the list of field paths — called the template — that the platform uses to build the signer's name. Leave it empty and the employee types their own name. Populate it with paths like employee.first_name and employee.last_name and the platform constructs the name automatically when the employee reaches the field.

How it works

Template mode

You provide one or more field paths in the Template Paths area of the configuration panel. When the employee reaches the signature field, the platform looks up each path in the task's facts and joins the resolved values with a space. The employee sees their name pre-filled — they click once to sign, no typing required.

Two quick-add buttons cover the most common setups:

• Use Employee Name — adds employee.first_name and employee.last_name

• Include Middle Name — adds employee.first_name, employee.middle_name, and employee.last_name

You can also enter paths directly in the text area, one per line, for less common scenarios — such as employer representative names or values stored in custom attributes.

Manual Entry mode

When no template paths are configured, the employee sees a text input labeled Enter your name to sign. They type their name and then click to sign. This is the default state for any signature field you add to a form without opening the configuration panel.

As a convenience, once an employee types their name on a manual-entry signature field, the platform remembers it for the rest of the session. If the same form has multiple manual-entry signature fields, the employee only types once — each subsequent field pre-fills with the name they already entered.

Fallback behavior

If template paths are configured but one or more of them doesn't resolve to a non-empty string — because the referenced data isn't available yet — the field falls back to manual entry automatically. The employee sees the text input and types their name. A misconfigured or incomplete template won't block signing; it degrades to the manual experience instead.

Why it matters

Without template configuration, every employee types their own name at signing time. In practice this produces inconsistency: legal names, nicknames, abbreviations, and formatting variations all end up in your audit exports. For forms that feed downstream PDF outputs or compliance records, that inconsistency can be a problem.

With template configuration, the name comes from the employee record — the same data your HR system already holds. Every signature on that form uses the same format, tied to the same profile fields.

This matters most when:

• Your forms run at scale and you need consistent, auditable signatures

• The form produces a PDF output where the signature name feeds into visible fields

• You want to reduce friction — especially in multi-step onboarding packets where an employee signs more than once

Example

Take an account running a new hire offer letter acknowledgment. The signature field sits on the final page of the form, assigned to the employee. Without template configuration, each new hire types their own name — and over thousands of completions, the audit trail shows a mix of "John Smith," "Jon Smith," "J. Smith," and "John A. Smith."

With Use Employee Name selected, the platform pulls employee.first_name + employee.last_name from the employee record. Every new hire sees their name already filled in and clicks once to sign. The audit export for each task shows the same name format, matched to the employee record.

Read next

• 📄 Understanding signatures and acknowledgments

• 📄 Understanding what to ask employees versus pull from existing data