Onboarding - Understanding Field Paths

Understanding Field Paths

A field's path is the address where its value is stored. Every field has one.

There are two type of field paths:

  • Form-Local Path
    • Starts with "form."
    • Stores the answer only on that specific form.
  • Entity Path
    • Connects the field to a record that exists outside the form including the employee (employee.first_name), the employer (employer.name), the client (client.name), or the job (job.address.state).

When you point a field at "employee.first_name", you are not creating a new "first name" that only the form knows about. You are connecting the field to the employee's actual first name, the same one every other form and record uses.

That one connection is what lets a form show information you already have and keep your records current at the same time.



Paths Are Connected to Entity Types

A path always names the entity it belongs to:

  • employee.
  • employer.
  • client.
  • job.
  • form. (for Form-Local Paths)

The prefix is how the Onboarding Portal knows which record to read from and write to. For example, "name" on its own is not linked to the entity, while "job.name" is linked to the job connected to this placement and "employer.name" is linked to its employer.

Because a path resolves against the records connected to the placement, the entity has to exist.

  • "job.name" only has a value when the placement has a job attached; if a form runs in a context where that object isn't present, the path has nothing to resolve to and comes back empty.

Placement-level data takes the same rule one step further:

  • "placement.custom_attributes.*" only resolves when the form is running on a placement, so the Onboarding Portal knows which placement to read from. Placement attributes aren't selectable as field paths or content variables, they live in the policy and rules layer, where they decide which forms get assigned.

*Note* For more information, please see the article titled Onboarding - Policy Rule Operators.



Reading - The Form Arrives Pre-Filled

When you preview a form, or when an employee opens it, each field's path is resolved against the connected records. A field pointed at "employee.first_name" shows the employee's existing first name already filled in; a field pointed at "employer.name" shows the employer's name.

A Form-Local "form." path has no outside record to read from, so it starts empty. The field path will only hold what gets entered on the form itself.



Writing - The Answer Updates the Record

When the form is submitted, a field connected to an entity writes its value back to that specific record.

For example, if an employee corrects the address on a field pointed at "employee.address", the employee record is updated with the new address so the next form they open will automatically reflect the update.



Where You Can Use a Path

The same path system shows up in more than one place. You can use a path:

  • As a field's path, connecting the field to an entity type, as described above.
  • In a review table which lists the paths you want to show and renders their current values without collecting or changing the information. This is the right tool when you want an employee to see an object (their employer's legal name) without being able to edit it.
  • As a content-block variable to add an object into body text.



Finding the Right Path

You don't have to memorize paths. As you type in a field's Path, a dropdown suggests matches as you go including built-in facts with friendly labels like First Name (employee.first_name) and Employer Name (employer.name), alongside the custom attributes defined on your account. Pick one from the list to connect the field to that record.

Custom attributes show up here too, grouped separately from the built-in paths. Once you create a custom attribute on an entity, you can reference it exactly like a built-in path.

*Note* For a list of default field paths, please see the article titled Onboarding - Default Field Paths.



Selecting the Right Form

The paths a form can reference depend on whether it's one of your account's own forms or a global form (a shared, pre-built form designed to be adopted across many accounts).

A global form can only reference the built-in field paths that every account has. These forms are unable to reference account-specific custom attributes,

On your account's own forms, you can reference both the built-in field paths and the custom attributes you've defined.

Related Articles