Understanding forms

Last updated: July 7, 2026

Forms are the reusable templates that drive every step of a candidate's onboarding flow. They collect information, display content, capture acknowledgments, and trigger integrations — often all in the same form.

What it is

A form is a reusable template. It defines what a candidate sees and does at a step in their onboarding flow. You build a form once; Onboarded uses it across thousands of placements.

Forms collect information — name, address, document upload, whatever the situation calls for — but they do more than that. A form can also display information: rich text, embedded videos, content blocks that pull in the candidate's name or any custom attribute. Combined with a signature field, a form becomes an acknowledgment artifact — a digital handbook the candidate reads and signs, an offer letter they confirm receipt of, a safety policy they attest to. And forms are also where you configure and trigger integrations — running a background check with a specific vendor package, syncing data to an HRIS, or kicking off any other connected workflow.

So a form is four things at once:

A way to collect data from candidates.
A way to display information to them.
A way to capture acknowledgment via e-signature.
A way to trigger integrations with external systems.

Most real-world onboarding forms blend two or more of these. A state tax form walks through the rules, collects the inputs, and ends with a signature. An employee handbook displays the policy with embedded video and ends with an e-signature. An offer letter renders the candidate's name, role, and pay rate from variables, then captures their acceptance. A background check form configures which vendor package to run, then kicks off the case as soon as the candidate submits.

When you hear "I-9," "W-4," "background check authorization," "offer letter," or "employee handbook acknowledgment" — each of those is a form on your account.

Why it matters

Most of what an HR Engineer configures in Onboarded is forms. New compliance requirement? That's usually a new form. Custom employer paperwork? A form. Updated state tax withholding? A new version of an existing form. New handbook acknowledgment? A form. Switching background check vendors or packages? Configured on a form.

Once you understand:

where your forms come from,
how they go from "I made it" to "it shows up on placements,"
and how versions move through publish and deploy,

most other configuration tasks fall into a familiar shape.

How it works

Where forms come from

Your account has a forms library. There are three ways forms get into it:

Global forms — Onboarded provides pre-built forms for the things most accounts need: I-9, W-4, state withholding forms, background check authorization, and many more. You adopt a global form to add it to your library.
Custom forms you build — for paperwork specific to your organization, you can build a form from scratch in the form builder.
Form requests — if you have a paper-heavy form (e.g., a PDF a customer hands you) and want the Onboarded team to build it for you, you can submit a form request.

All three paths land in the same place: your account's library.

Versions

Every form has versions. The version is what holds the actual content — the fields, layout, and rules. When you make changes to a form, you're creating a new version.

A version has one of three statuses:

Draft — work in progress. You can edit it. It's not yet selectable to put on placements.
Published — finalized. To make further changes, you create a new version.
Deprecated — superseded by a newer version. The form still exists, but new placements pick up the latest version.

Publish vs. deploy

This is the part most often missed. Publishing a version is not the same as deploying it.

Publish — finalizes the content of the version.
Deploy — makes the version actually available for placements to use.

And deployment is mode-specific:

Deploying to test mode makes the version usable in your test environment.
Deploying to live mode makes it usable in your live (production) environment.

These are independent. Deploying to test does not deploy to live. You have to deploy to each mode separately.

If you publish a form, deploy it to test, then go look for it in live mode, you'll see it as Deployable, not Deployed. That's not a bug — you haven't deployed it to live yet. This is the single most common source of "why isn't my form showing up?" confusion.

What forms can do — fields and their roles

A form is built out of fields. Around twenty types are available, falling into four rough categories:

Collecting fields — capture information from the candidate. Text, dropdown, date, file upload, currency, address, and most other types.
Display fields — show information without collecting anything. The most flexible is the content block, which holds rich text, embedded videos, iframes, and variable references like the candidate's first name or any custom attribute you've defined. Other display-only types include QR codes and computed values.
Signature fields — capture an e-signature that serves as the candidate's acknowledgment of whatever the form says. When a candidate signs, Onboarded captures their IP address, the timestamp, and a cryptographic hash of their submitted answers. If the candidate's submitted answers are later edited, the answer hash no longer matches and the signature is invalidated. That's what makes the signature e-sign compliant: it's verifiably tied to the version the candidate signed and to the exact answers they submitted, and it can be produced as evidence in an audit record.
Integration fields — connect the form to an external system. The form is where you configure the integration's parameters — for example, which Checkr or Yardstik package to run for a background check, or how fields map to your HRIS. When the form runs, the integration runs with it, using whatever configuration you've set on the form.

Combining content blocks with a signature field is what makes a form work as an acknowledgment artifact. You can write an entire employee handbook into a single form using content blocks — pulling in the candidate's name and other details from variables — end with a signature field, and have a meaningful, e-sign-compliant record that they read and acknowledged it.

Each field can optionally have a visibility switch: a rule that shows or hides the field based on what's been entered in other fields. ("Only show the spouse's name field if the candidate selects Married.") We'll cover building fields and rules in separate how-tos.

Translations

Forms support translations at the version level. Each language is added as a separate translation set while the version is a draft — once the version is published, its translations are locked. Candidates see the form in their selected language; the underlying field paths and submission data stay consistent in English. See 📄 How do I translate a form into another language? for the full workflow.

Example

Take an account that needs an employee handbook acknowledgment — a form that displays the company's policies and captures each new hire's signature confirming they've read them. Here's how it gets from idea to a candidate's screen:

Go to the form builder and create a new form. It starts as a draft.
Add a content block with the handbook's text — including a header that pulls in the candidate's first name from a variable. Embed a short welcome video.
Add a signature field at the end so the candidate can acknowledge they've read the handbook.
Publish the version. The version is now finalized, but it's not yet live anywhere.
Deploy to test mode and run a fake placement through it to confirm the variables, video, and signature flow work as expected.
Deploy to live mode. Now it's available for real placements.
Add the form to a policy (e.g., "all new hires") so it actually gets assigned to the right placements.

From step 7 onward, every new placement gets the handbook with their name pre-filled, the welcome video embedded, and a signature line at the end — no per-candidate work.