What is a Policy?

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

Every form that is a part of a placement is there because a policy states to include it. The policy engine decides what forms show up, and for whom.

Instead of having to assign every form to every candidate one by one, policies help streamline and automate the process. 

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?"

Policies can be found by navigating to the Onboarding Portal > Configuration > Policies:

The Parts of a Policy

A policy has three parts:

1. Rules indicate what has to be true for the 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 and you can require all conditions to match (an "And" group) or any of them to match (an "Or" group):
   
2. Forms are 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", which are 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 is whether every policy is either enabled or disabled. Newly created policies start as disabled and will need to be manually enabled:

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

• Policies evaluate when a placement is created. When a new placement enters the system, every enabled policy is checked on the account. Any policies whose rules match will assign their forms to the placement.
• Form conditions layer on top of policy rules. When a policy matches, each form's condition is then checked.
  • 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 trigger on their own. You will need to manually re-run policy evaluation on that placement.
• Multiple policies can match the same placement. A forklift driver in California might match both a "Forklift Driver" policy and a "California" policy at the same time. Both will trigger and both will assign their respective forms.
• Conditions are exact-match (case sensitive) by default. If a custom attribute value is "Offer Extended" (capital O) and your rule looks for "offer extended" (lowercase), the rule will not match.
  • This can be configured via the "Aa" button when adding/editing the rules and form conditions. If enabled, the rule/condition is case-sensitive. If not selected, the rules will match regardless of case-sensitivity ("California", "california", and "CALIFORNIA" will all match):
    
• Policies are reusable. One policy can apply to thousands of placements. Instead of writing a new rule per candidate, you write one rule that describes the condition, and it scales automatically.

Policy Example

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

With this information, you only need to write one policy:

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

And that's it. Now...

• Every new placement created with job of "Forklift Driver" gets the Forklift Certification assigned automatically.
• Placements for any other role are not affected.
• You haven't written any per-candidate policies. You've described the rule once, and the correct form is assigned to the right placements.

Adding Form-Level Conditions

The example above uses a tightly scoped policy of 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 and not to every warehouse hire.

This is where Form-Level Conditions come in:

• Rules: "placement.custom_attributes.location" is "Warehouse"
• Forms:
  • Hard Hat Acknowledgment with no conditions set; assigned to every warehouse hire
  • Safety Briefing with no conditions set; assigned to every warehouse hire
  • Forklift Certification with the "Condition" of: "job.name" is "Forklift Driver"
• Status: "Enabled"

Now when a warehouse placement is created, the policy's rules are checked first. If they match, it then checks each form's conditions. The Hard Hat and Safety Briefing forms are assigned to every warehouse hire while 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 abundance of overlapping policies.

Related Articles

• Onboarding - How to Setup Policies New
• Onboarding - Policy Rule Operators New