What are Forms?
A form is a reusable template. It defines what a candidate sees and does at a step in their onboarding workflow. You build a form once and it can be used across any placement it is added to.
Forms collect information including name, address, document upload, whatever the situation calls for, but they also do so much more...
- A form can also display information such as 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 such as 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 execute integrations such as 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 candidates.
- 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.
Forms are accessible via the Onboarding Portal > Configuration > Forms:
*Note* You will need the following permissions to access Forms:
- View Forms
- Create Forms
For more information on permissions, please see the article titled Onboarding - User Groups and Permissions.
Where Forms Come From
Your account has a forms library. There are two ways forms get into it:
- Global Forms are pre-built forms for the things most accounts need including the 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 are the forms that you build within the Onboarding Portal.
All forms are accessible within your account's library.
Form Versions
Every form has versions. The version is what holds the actual content including 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 is a work in progress. You can edit it. It's not yet selectable to put on placements.
- Published is finalized. To make further changes, you create a new version.
- Deprecated is superseded by a newer version. The form still exists, but new placements pick up the latest version.
Publishing vs Deploying Forms
Publishing a version is not the same as deploying it.
- Publish finalizes the content of the version.
- Deploy makes the version 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. Each will need to be deployed separately.
Form Fields and Their Roles
A form is built out of fields. Around twenty types are available, falling into four categories:
- Collecting Fields capture information from the candidate. These include 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 the contents of the form. When a candidate signs, the Onboarding Portal captures their IP address, the timestamp, and a cryptographic hash of their submitted answers.
*Note* 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 the configuration you've set on the form.
Combining content blocks with a signature field is what makes a form work as an acknowledgment. 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 then read and acknowledge.
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.")
*Note* For more information, please see the article titled Onboarding - How to Show/Hide Form Fields.
Form Translations
Forms support translations at the "version" level. Each language is added as a separate translation while the version is within a "Draft" status. Once the version is published, its translations are locked.
*Note* Candidates see the form in their selected language. An employee who picks Spanish sees Spanish labels, help text, and options as they fill the form out.
Once the form is submitted, the underlying field paths and entered information within the form stay consistent in English.
If a signed document has to be in the employee's own language for your records or for a regulator, you will need a separate form built on a PDF in that specific language, and a policy that assigns it based on the employee's preferred language.
For more information on translating a form, please see the article titled Onboarding - Form Translations.