Understanding signatures and acknowledgments

Last updated: July 30, 2026

A signature field captures an employee's electronic signature, binds it to the version of the form they signed and the answers they submitted, and produces an audit-defensible record of acknowledgment for compliance and legal requirements.

What it is

A signature field is a form field that asks an employee to sign their name electronically. When they submit, Onboarded captures the name, the timestamp, the IP address, and a cryptographic hash of the employee's submitted answers on the version of the form they signed. That combination—signature + timestamp + answer hash, against an immutable form version—is what makes it an audit-defensible acknowledgment, compliant with electronic signature laws like the US ESIGN Act and UETA.

If you remember nothing else: a signature proves three things at once: who signed it, when they signed it, and that their submitted answers haven't been edited since they signed.

Why it matters

Signatures appear wherever you need legal proof that an employee agreed to something at a specific moment. This matters most when:

A regulatory body (like a state labor agency) audits your onboarding and asks for proof of employee consent.
You need to prove an employee acknowledged a policy, offer terms, or I-9 instructions at the time they onboarded (not months later).
A dispute arises over whether the employee saw and accepted certain terms.
Both an employee and an employer need to countersign the same document — for example, an offer letter.

Without a signature on a form, you have no auditable proof that the employee saw what you showed them, or that they agreed. With it, you do.

How it works

The signature field itself

A signature field appears in your form like any other field. You can optionally configure it to auto-populate the signer's name using a template (e.g., pulling the first and last name from employee.first_name and employee.last_name), or you can leave it empty so they type their name at signing time. See 📄 Understanding Signature Field Configuration for the full breakdown of template vs. manual entry modes.

Content blocks + signature = acknowledgment

A signature alone doesn't prove acknowledgment without context. You pair the signature field with content blocks above it—text, policies, or form instructions—that explain what the employee is signing. That pairing (content + signature) creates the acknowledgment artifact. The employee signs against a specific form version, and that version is locked—if you later need to change the wording or add a field, you publish a new version and re-assign the task on the new version, leaving the original signed task intact.

What's captured at signing

When an employee submits a form with a signature field, Onboarded records:

name — the signature itself (what the employee typed).
signed_at — the exact timestamp of submission, to the millisecond.
ip_address — the IP address from which they signed.
user_agent — the browser/device they used (for device validation if needed).
hash — a cryptographic hash of the employee's submitted answers, used to detect later edits to those answers.

All five are persisted to your account. The IP, timestamp, and user-agent form the audit trail. The hash is the tamper-evidence mechanism.

Form version immutability

A signed task points at a specific form version, and that version doesn't change. If you later decide the wording needs an edit or a new field needs to be added, you publish a new form version and re-assign the task on the new version. The originally signed task and its content stay exactly as the employee saw them.

This is the first piece of audit defensibility: a regulator can pull the signed task and see the form version the employee signed, byte-for-byte the same as the moment they signed it.

Input-change invalidation

The second piece is the answer hash. When an employee signs, Onboarded hashes their submitted answers and stores the hash alongside the signature. If those answers are later edited—typically when an admin reopens the task through a change request and the employee updates something they previously submitted—the hash no longer matches and the signature is invalidated. Your audit record reflects this: this acknowledgment was invalidated when the employee's submitted answers were edited on [date].

Editing the form's configuration—labels, paths, content blocks, validation rules—doesn't break a past signature, because configuration changes live on a new form version. Editing the employee's submitted inputs on a signed task is what triggers invalidation. Change-request workflows are covered separately.

Signature limits and multi-signer flows

Most forms have one signature, signed by the employee. Some workflows — like an offer letter — also need an employer countersignature: the employee signs to accept the terms, and the employer signs to confirm them.

When a form has both an employee and an employer signature, each is captured at the moment that the signer submits their pages, with its own timestamp and hash.

One last distinction worth flagging: a signature field is not the same as a consent checkbox. A checkbox proves an employee clicked "I agree." A signature proves they agreed, and when they agreed, with tamper-evident proof. Use signatures for compliance-critical acknowledgments; use checkboxes for lightweight confirmations.

Making an acknowledgment enforceable

A checkbox only proves acknowledgment if the employee can't move past it. New checkbox fields are created as required, so the employee can't submit the page until they check it. Write the attestation itself as the field's statement — that text is what the employee is agreeing to, and it's what gets carried into review tables and audit PDFs alongside their answer.

Older forms sometimes render an acknowledgment as a Yes / No pair instead of a checkbox. That's a legacy display carried over from an earlier version of the form builder; new fields use the Default checkbox display, and only Onboarded can switch a field back to Yes / No. If an employee is reaching the end of a form without ever confirming something you thought was mandatory, an optional legacy Yes / No field is a likely cause — check whether the field is required before looking anywhere else.

When the action happens outside Onboarded, a checkbox isn't enough. If a step sends the employee to an external site — a tax-credit questionnaire hosted by a provider, a benefits enrollment page — Onboarded has no way to confirm they finished it. Pair the link with a required signature on an explicit attestation ("I have completed the questionnaire at the link above"). That moves your record from "we showed them the link" to "they attested they completed it," which is the version that holds up in an audit.

Designing acknowledgments for long documents

Long PDFs — employee handbooks, multi-policy packets, anything past a few pages — create a design question: how do you prove the employee read the whole thing?

The pattern that holds up in compliance audits is a single signature on the final page, paired with an explicit acknowledgment statement above it. The statement names what the employee is attesting to, the form version carries the full document content immutably, and the signature binds the employee to that version at that moment. You don't need a signature on every page to make the acknowledgment audit-defensible — you need one signature against an immutable version of the full document.

Place a content block immediately above the signature field with language like:

I acknowledge that I have reviewed the entire document above and agree to its contents.

Adjust the wording to match the document — for an employee handbook, "I have received, read, and understood the Employee Handbook"; for a policy packet, "I acknowledge receipt of the policies listed above." The pattern stays the same: name what's being acknowledged, then collect the single signature.

For documents that need an employer countersignature too, the same pattern applies on the employer pages — one acknowledgment block, one employer signature at the end.