Dependent custom fields allow organizations to create nested relationships between custom fields, enabling dynamic visibility of specific fields based on the values selected in others. This structure helps reduce clutter, improve data accuracy, and guide users through only the relevant fields when creating offers, jobs, or openings.
Dependent fields are available on three object types:
- Offers
- Openings
- Jobs
Nesting custom fields in parent/child relationships helps streamline workflows and minimize data entry errors. Parent field selections can also control which options appear in a child field, ensuring users see only the most relevant choices.
Parent / child dependencies
To configure dependent custom fields, define a parent/child relationship between custom fields. A child field becomes visible only when a specific option is selected in its parent field.
For offers, this dependency determines when a child field appears in the Create an Offer dialog box. Any custom offer field can be used as a child field. To be used as a parent field, a custom offer field must be either Yes/No or Single select. If you're configuring option-level filtering, single select parent fields must have 25 options or fewer.
Dependencies can be nested up to three levels deep (grandparent, parent, and child), creating a structured hierarchy similar to a family tree. Each level displays conditionally based on the preceding field's selected option.
Once dependencies are set, they are listed on each field's Dependencies tab within Custom Options. In this view, child fields appear in bold.
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.
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.
...
Your organization offers two types of employment – salaried and hourly. Without dependencies, both the Salary and Hourly Pay Rate offer fields are always visible when creating an offer, increasing the risk of user error.
By creating dependencies between the Employment Type, Salary, and Hourly Pay Rate fields, users see only the relevant pay field based on their selection. For instance, if "Hourly" is selected in the Employment Type field, only the Hourly Pay Rate field appears.
Additionally, your organization can limit which options appear in a child field based on the selection in a parent field. For example, if "Career Level" is the parent field, selecting "8 - Associate Manager" can restrict the visible options in a dependent Variable Pay field to only those applicable for that level – ensuring clean, error-free data collection.
Additional resources
To learn more about how to create and manage your organization's dependent custom offer fields, check out: