Understanding what to ask employees versus pull from existing data

Last updated: July 30, 2026

A well-designed form only asks the employee for data Onboarded doesn't already have. Everything else is either shown back to them in a content block, used to auto-populate a signature template, or omitted from the form entirely.

What it is

When you build a form, every field is a small ask of the employee — read it, type the answer, move on. The longer the form, the more fatigue compounds, and the higher the chance someone enters something wrong on a field where you already had the right value sitting in the placement record.

The mental model: a form collects what you don't know; it doesn't re-collect what you do. The data you already have in employee, employer, placement, job, and client records doesn't need to be re-typed by the employee. It needs to be displayed, referenced, or quietly used to drive the form's behavior.

Why it matters

Onboarding fatigue is real. Every redundant field is a chance for a typo, a mismatch between the placement and the form, and an extra reviewer cycle for someone on your team to reconcile the two. Forms that ask for data you already have also signal sloppiness to the employee — they assume your systems don't talk to each other.

This matters most when:

  • The placement was created from an ATS that already supplied start date, job title, location, or pay rate.

  • The form is a translated dual-language document where every redundant field has to be maintained in two places.

  • The form will be filled out by an employer or HR reviewer rather than the employee — the data is sitting one click away in the placement view.

  • You're building a long PDF mapping where each unnecessary field is one more PDF coordinate to maintain.

How it works

For any piece of data you're tempted to add as a form field, ask one question first: does Onboarded already have this? If yes, you have three choices instead of asking for it.

Option 1: Display it in a content block

A content block is read-only and renders live data via variables like {{employee.first_name}}, {{client.name}}, or {{job.name}}. The employee sees the value but can't change it. This is the right choice when the employee needs to see the data — for context, to confirm it's correct, or because the form's PDF mapping requires the value to render somewhere on the page — but doesn't need to enter it.

See 📄 How do I add a content block with variables to a form? for the field-by-field walkthrough.

Option 2: Auto-populate a signature template

A signature field has a template option that builds the signer's printed name from fact paths — usually employee.first_name and employee.last_name. The employee still signs (the legal act of signing isn't bypassed), but they don't re-type their name. This is the right choice for signature fields specifically. See 📄 Understanding Signature Field Configuration for the full breakdown.

Option 3: Remove the field entirely

If the employee doesn't need to see the data and doesn't need to confirm it, the field doesn't belong on the form at all. The data is already on the placement; the PDF mapping (if there is one) can pull from the placement directly; the form stays focused on what the employee actually contributes.

This is the option most people skip. They've already added the field; deleting it feels like undoing work. Delete it anyway — the form is shorter and the placement record stays the source of truth.

Custom attributes live on placement, not the employee record. Placement-level data like start date, pay rate, location, and employment type usually lives at placement.custom_attributes.{field_name} — not employee.start_date or similar. Double-check the path in the form preview's Facts panel before you assume the variable will resolve.

When you do need to ask

Three cases where collecting the data from the employee is still the right call:

  • The data isn't reliable yet.

  • Compliance requires the employee to enter it directly. I-9 Section 1 has to be completed by the employee in their own hand — pre-filling it from another record defeats the point.

  • The form catches errors by design. Asking the employee to type a value you also have on file lets you compare the two and surface mismatches — useful for SSN, date of birth, and address verifications.

Example

Take an account building a state-specific direct deposit form. Their first draft has 11 fields: employee first name, employee last name, employee email, employee SSN, employee address, employer name, employer address, employer EIN, start date, pay frequency, and a bank routing/account section.

Walking through each field against the data Onboarded already has:

  • Employee first/last name — already on employee. Use a content block at the top of the form to greet the employee by name. Remove the editable fields.

  • Employee email — already on employee. Remove.

  • Employer name, address, EIN — already on the employer record. Map them to the PDF directly; don't ask the employee to type them.

  • Start date — already on the placement. Display in a content block ("Your first day is {{placement.custom_attributes.start_date}}") if the form needs to show it; otherwise, remove.

  • SSN — keep as a field. Compliance requires employee entry, and matching it against the employee record on submit catches typos before payroll picks it up.

  • Address — keep if your account doesn't already verify employee address via IDV; otherwise display in a content block for the employee to confirm.

  • Bank routing and account — keep. The employee is the only source.

The form drops from 11 fields to 3 editable fields plus 2 content blocks. The employee spends 90 seconds instead of 5 minutes. The PDF still renders every value because content blocks and PDF mappings both pull from the same fact paths.

Read next