Dependent custom fields overview

Permissions: Site Admin, and Job Admin who can manage custom fields

Product tier: Available for Expert subscription tier

Dependent custom fields allow your organization to create a nested structure of custom fields with defined relationships between parent and child fields. As your organization becomes more complex, there may be a large number of custom fields that do not apply to every single new hire. Irrelevant fields increase the risk of making a mistake, missing a field, or entering a field incorrectly.

Dependent fields are available on three object types:

  • Offers
  • Openings
  • Jobs

The nested structure of dependent custom fields creates a guided path for users when creating an offer or opening and limits the exposure of fields based on the criteria you define.

Parent / child dependencies

When configuring dependent custom fields, your organization will be defining parent/child relationships between custom fields.

For offers, the parent / child relationship dictates when a child custom field will be visible in the Create an Offer dialog box and is based on the option selected in the parent custom offer field.

Custom fields already in a parent / child dependency can subsequently be dependent on another custom field in a nested parent / child dependency. Your organization can think of the nested parent/child dependency as a family tree of custom fields that will display in sequence the child custom field based on the option selected in the parent custom field.

Note: Greenhouse Recruiting currently supports a three-level nesting structure for dependent custom fields (in other words, grandparent / parent / child).

Here's an example of what that looks like when creating an offer.

dependent__1_.gif

Once configured, the dependencies for each field will be listed on their respective custom options page.

Note: The child in any dependency will always be displayed in bold.

Dependent custom offer field example

Use Case: Your organization hires employees who are either paid a salary or hourly. Currently, a Salary offer field and Hourly Pay Rate offer field are both visible in the Create an Offer dialog box. Users will need to know which field to fill-out and can potentially mistakenly fill out both fields.

Rather than having both a Salary offer field and an Hourly Pay Rate offer field visible in the Create an Offer dialog box, build a parent/child dependencies between an Employment Type field, Salary field, and Hourly Pay Rate field. By creating these dependencies, either the Salary field or Hourly Pay Rate field will appear only after the corresponding parent field (Employment Type) option is selected.

Artboard.png

 

Additional resources

To learn more about how to create and manage your organization's dependent custom offer fields, check out: