Understanding policies

Last updated: April 29, 2026

Policies are how Onboarded decides which forms get assigned to each placement. Once you understand policies, almost everything else in the platform follows.

What it is

A policy is a rule. It says: "When a placement matches these conditions, assign these forms."

Every form on a placement is there because a policy put it there. The policy engine is the conditional rule fabric that runs underneath everything else in Onboarded — and decides what shows up for whom.

If you remember nothing else: policies are the conditional logic that connects placements to forms.

Why it matters

Without policies, you'd have to assign every form to every candidate one by one. Hire a forklift driver? Remember the forklift certification. Hire a contractor? Remember the W-9, not the W-4. Hire someone in California? Remember the DE-4 state tax form. Different roles, different states, different documents.

With policies, you describe each rule once. Onboarded does the routing forever after.

This matters most when:

You hire across multiple roles or job types with different document requirements.
You operate in multiple states or jurisdictions and need different forms in each.
You hire on behalf of multiple clients (in a staffing context) and each one needs slightly different forms.
You're scaling up — what was tractable to manage by hand at 50 placements per month doesn't survive 500.

The HR Engineers who get the most out of Onboarded are the ones who internalize the policy model first. Once you can think in policies, every new requirement maps to a question: "What's the rule? When does it apply? What does it assign?"

How it works

A policy has three parts:

1. Rules — what has to be true for this policy to apply. Rules evaluate facts about the placement: state, job, employer, client, custom attributes you've defined, and so on. A policy can have one rule or several combined together — you can require all conditions to match (an And group) or any of them to match (an Or group).

2. Forms — what gets assigned when the rules match. One policy can assign one form or many. Each form on the policy can optionally have its own Conditions — a second-layer rule that decides whether that specific form gets assigned when the policy applies. When a form has no conditions set, you'll see an Add condition prompt next to it in the Conditions column; that means the form is assigned every time the policy matches.

3. Status — every policy is either enabled or disabled. A disabled policy is completely ignored, even if its rules would match. Newly created policies start as disabled — you have to flip them on intentionally.

A few things to know about how policies behave in practice:

Policies evaluate when a placement is created. When a new placement enters the system, Onboarded checks every enabled policy on the account. Any policies whose rules match assign their forms to the placement.
Form conditions layer on top of policy rules. When a policy matches, Onboarded then checks each form's conditions. A form is assigned only when both the policy's rules and the form's own conditions are met. A form with no conditions set is assigned whenever the policy matches.
Policies don't auto-re-evaluate when placement attributes change. If you create a placement in Texas and later update it to California, the California-specific policies won't fire on their own — you'd need to manually re-run policy evaluation on that placement. We'll cover that in a separate how-to.
Multiple policies can match the same placement. That's expected — a forklift driver in California might match both a "Forklift Driver" policy and a "California" policy at the same time. Both fire, both assign their forms.
Conditions are exact-match. If a custom attribute value is Offer Extended (capital O) and your rule looks for offer extended (lowercase), the rule won't match. This is the single most common reason a policy or form "isn't firing" — the value isn't what you think it is.
Policies are reusable. One policy can apply to thousands of placements. You don't write a new rule per candidate — you write one rule that describes the condition, and it scales automatically.

Example

Take an account that hires across a range of roles — warehouse staff, office workers, and forklift drivers. They have one specific compliance need: every forklift driver must complete a forklift certification form as part of their onboarding.

You write one policy:

Rules: job.name is "Forklift Driver"
Forms: Forklift Certification
Status: enabled

That's it. From that point on:

Every new placement created with job = Forklift Driver gets the Forklift Certification assigned automatically.
Placements for any other role aren't touched. They get only the standard onboarding forms.

You haven't written any per-candidate logic. You've described the rule once, and Onboarded routes the form to the right placements.

When form-level conditions help

The example above uses a tightly scoped policy — only forklift drivers — so every form in it should be assigned to every matching placement. But sometimes a single policy needs to bundle related forms that don't all apply to every match.

Imagine a "warehouse onboarding" policy that applies to all warehouse staff. Most forms (hard hat acknowledgment, safety briefing) should be assigned to everyone in the warehouse. But the forklift certification should only be assigned to actual forklift drivers — not to every warehouse hire.

That's what form-level Conditions are for:

Rules: placement.custom_attributes.location is "Warehouse"
Forms:
- Hard Hat Acknowledgment — no conditions set; assigned to every warehouse hire
- Safety Briefing — no conditions set; assigned to every warehouse hire
- Forklift Certification — Conditions: job.name is "Forklift Driver"
Status: enabled

When a warehouse placement is created, Onboarded first checks the policy's rules. If they match, it then checks each form's conditions. The hard hat and safety briefing forms are assigned to every warehouse hire; the forklift certification is assigned only to forklift drivers.

Form-level conditions let you bundle related onboarding requirements into one policy instead of spreading them across many — keeping the right form on the right placement, without an explosion of overlapping policies.