Understanding registration forms

Last updated: October 1, 2026

A registration form is the first page someone fills out from a registration link. It creates their employee record — that's the one job it's built for. This article covers what a registration form can hold and where the rest of your questions should go.

What it is

When someone opens a registration link, the first thing they see is a registration form. Submitting it does two things: Onboarded creates the employee record from their answers, then creates the placement (or placements) the link was set up for. From there, the employee moves on to the forms that placement needs.

If you don't pick a form, Onboarded uses its built-in New Employee Intake form, which asks for first name, last name, address, and email. You can swap in your own form in two places:

  • Dashboard registration links — Employees → New Registration Link → Registration Form.

  • TempWorks job apply links — Account Settings → Integrations → Configure next to TempWorks → the Configuration step → Registration Form.

If you remember nothing else: a registration form creates an employee. It isn't the place to collect answers about the job, the application, or screening.

Why it matters

It's tempting to load a registration form with every question you want answered up front — availability, shift preferences, screening questions. But a registration form only saves answers to the employee record, and it runs before that record exists. Treating it as a general-purpose form leads to forms that get rejected, answers that land somewhere nothing reads them, and automations that never fire.

This matters most when:

  • You're replacing New Employee Intake with your own form.

  • You want to ask screening or pre-qualification questions before someone goes further.

  • You want an automation to react to something the employee answered at registration.

How it works

What a registration form can hold

Onboarded checks your form when you select it — in TempWorks settings as soon as you pick it, and in the registration link dialog when you click Generate Link. A form passes when:

  • It has a deployed version in the mode you're working in (test or live).

  • It has exactly one page.

  • Every input field writes to an employee.* path — employee.first_name, employee.address, employee.custom_attributes.preferred_shift, and so on. See 📄 Understanding field paths. Display-only fields — content blocks, review tables, PDF View fields, timers — are allowed regardless of path.

  • It includes employee.first_name and employee.last_name.

  • It includes every field your duplicate detection matches on. If Match Criteria under Employee Duplicate Detection (Registration Link) includes Email, the form needs employee.email. Phone needs employee.phone. SSN needs the full SSN field or the partial SSN custom attribute you've configured.

  • Every custom attribute it writes to already exists in your organization.

When a form breaks a rule, Onboarded tells you which one — for example, Registration form must contain only employee fields. Found: "placement.custom_attributes.shift" or Registration form must contain exactly one page. Point the field at an employee.* path, or move the question to a form that's assigned after registration.

Where the rest of your questions go

Anything that isn't about who the employee is belongs on a form your policies assign to the placement. Those forms run after the employee and placement exist, so they can write to placement paths, span multiple pages, and drive automations. The employee goes straight into them after registering, so it still feels like one flow.

Automations don't fire on registration itself

Automations trigger on tasks and placements — a task's status changing, a placement being created, and so on. Submitting a registration form is neither. To act on an answer, ask the question on a form that's assigned after registration and trigger on that form's task. For something you want to happen the moment someone registers, like a welcome email, trigger on placement.created.

Example

Take a staffing account that wants to flag applicants who can't work weekends. The first instinct is to add Can you work weekends? to the registration form, saved to an employee custom attribute. The form passes the checks — but nothing acts on the answer. No automation fires when registration is submitted, so a "no" never reaches a recruiter.

The setup that works:

  • The registration form stays short: first name, last name, email, phone, and address.

  • A one-page screening form with the weekend question is assigned to new placements by policy. The employee moves into it right after registering.

  • An automation triggers when that screening form's task is completed. When the answer is no, it logs a message on the employee's TempWorks record so a recruiter can follow up — see 📄 How do I log a message on a TempWorks employee record from an automation?

The employee sees the same questions in nearly the same order. The difference is that the answer now lives on a task an automation can see.

Read next