How to enable: (Internal) How to Turn On Parent/Child for a Team
Support resource: +Parent/Child Reqs [WIP]
Parent/Child job association is a model some teams use to manage their requisitions. It’s more common for teams that are hiring for the same role at a high frequency – these roles are often referred to as Parent Jobs, Pipeline Jobs, Evergreen jobs, etc.
The benefit of using this model is to keep all candidates and pipeline conversion metrics in one job – the Parent Job. It also minimizes work in the ATS in that recruiters only need to add candidates to one job instead of multiple jobs that are continually opening and closing.
Once a candidate reaches a certain stage, the user would reject the candidate from the Parent job and move them into the Child job to finish the process. Different teams move the candidate at different stages; the most common being right before, during, or right after the offer stage.
Below is an example of four Parent Jobs in a Gem report. Noticed how the pipeline funnel ends abruptly between the Offer and Hired stage. This issue will happen in any reporting tool if Parent apps aren’t associated with Child apps.
With Parent/Child app linking enabled, when a candidate reaches the offer stage and the user moves them from the Parent Job to Child Job, they’ll reject the candidate out of the parent job using a specific rejection reason. An example could be “Moved to Child Req”
When that specific rejection reason is used, Gem will know to link that candidate’s Parent application to the Child Job. Gem will then fold the Child Job’s data back into the Parent in the background so that the user will only need to look at the Parent job to get a view of the entire pipeline (see below).
The child job will be hidden in Gem reporting to prevent double-counting. However users can drill down into the application details (by clicking on the number in the Hired column) to get a breakdown of what Child Job a particular Parent application is linking back to. The Child job names will be hidden in the main report rows, and in the filters and group by dropdowns, but they will be visible in the drill down views (see below).
Here’s the logic for how the linking process works. Gem identifies the parent and child applications by looking at only two things:
- Is the application closed with the special rejection reason? → if yes, this is a parent app
- Once Gem find a parent app… was another application for this candidate opened within 3 days of when the parent app was rejected? → if yes, this is the child app
FYI There is an edge case that our team hasn’t accounted for yet. If the same candidate who was rejected off the parent app has another non-child app created within the 3 day window (either by the candidate applying to another role or a recruiter creating a new app), then that new app AND the child app could be associated with the parent app. I haven’t had clients run into this problem and our eng team has ideas for potential solutions but it’s not something they are focused on at the moment.