The Lever Data Model
This document gives a brief introduction to the primary working objects of Lever’s data model and what it all means for reporting considerations.
Core Lever Concepts
The following objects are core to Lever's data model and reporting.
- Candidate: The individual applying to one or multiple jobs. The candidate object holds the candidate-related fields: name, resume, credentials and other information not unique to any specific job application.
- Job Posting (“Job”): The job posting promoting a job where candidates can apply. The job posting contains metadata about the job, such as the department, location and hiring team members.
- Opportunity: A candidate’s application on a specific job is called an opportunity. A candidate can apply to multiple jobs and thus have multiple active opportunities. The opportunity object contains metadata unique to the application, such as the origin, source and hiring team members assigned. Scorecard feedback, interview records, and additional progress information will be tied to the opportunity.
- Requisition: Requisitions are optional in Lever, but if you use them this will be where headcount information, budget specification and approval workflows can live. The requisition contains metadata about department, team, and hiring team members, amongst other details in addition to the requested headcount.
Concept and Reporting Challenges to Keep in Mind
The Job, the Opportunity, and the Requisition each have a recruiter
Each core Lever object has an independent record of common fields, such as the recruiter and hiring manager. Sometimes these are the same across these objects, but they can differ! Sometimes the Opportunity's recruiter is not the same as the recruiter on the job posting associated with the Opportunity, for example.
- Many customers request reporting, grouping or filtering by “the recruiter” or “the hiring manager.” These hiring team roles can be assigned on the job, but they can also be specified on the Opportunity or the Requisition record independently. This can result in data divergence, where an opportunity can have one recruiter assigned, and the Job itself can have a different recruiter assigned. To make matters a little more complicated, the Requisition can also have a different assigned recruiter. There is no constraint within Lever that requires the different objects have the same hiring team member assigned.
- In Ashby, you can report with specification of the field on any of these objects. As you use type ahead on the field selector, you'll see the "path" from which the field is selected, e.g. "Opportunity > Recruiter" will select the recruiter from the opportunity, while "Opportunity > Job > Recruiter" will select the recruiter specified on the job's record.
Our recommendation: Most customers report based on the Opportunity’s hiring team members, but you can use Ashby to examine the Job’s and Requisition’s assigned recruiter and compare that against the Opportunity’s recruiter to detect any unexpected discrepancies.
Job postings and Requisitions are independent objects
Job postings and Requisitions can be created independently of each other and at any time. This means you can have a job posting open with active Opportunities and no underlying Requisition is required. However, you can link one or many Job postings to a requisition at any point in time.
Similar to understanding which object’s hiring team members you want to reference in reporting, metadata around the department, team, location and so on can differ between the Requisition and the Job posting.
A requisition is only associated with an opportunity at the offer or hired stage
Within Lever’s model, an opportunity is only associated with the Requisition at the time of offer approval or extension, or after a hire is made. This means that any Candidate or Opportunity-related reporting by requisitions necessarily will be implicitly filtered to opportunities at the offer or hired stages.
Time to fill is not well-defined in Lever
As described above, Job postings and Requisitions are independent and the relationship between them is “many to many” in Lever. This means a Job posting can be associated with multiple requisitions, and a Requisition can be associated with multiple job postings. A byproduct of this is a job posting can be opened and with active opportunities in the pipeline, and then at a later date, a new Requisition can be opened. The Requisition’s creation time does not necessarily precede recruiting efforts, so the notion of a “start time” is not clear.
Given a single Requisition can be associated with multiple Job Postings, the “close date” for a time to fill is also not clear: is it the first hire across any posting, the first hire from each posting, or the date which the Requisition itself is closed after all headcount is filled?
Our recommendation: If you are using Requisitions in Lever, go with 1 headcount per Requisition. This will allow a clear Requisition creation or approval date and Requisition close date, from which we can report a best effort time to fill metric. Additionally, if you integrate with an HRIS like Workday where you define your headcount, it’s likely the Lever integration will follow a 1-requisition-1-headcount sync.
A candidate can have multiple opportunities
It is tempting to report on “candidates”, but in most cases you do not want to, as the Candidate does not contain meaningful data about progress through your interview funnel. You’ll want to focus your reporting on Opportunities, as discussed in Reporting on Candidates vs Applications.
Working with Lever’s offer process
If your offers are managed outside of Lever, you will not be able to report on offer acceptance rates effectively. If you need to keep the offer letter outside of Lever's system, we recommend you can create an offer object in Lever and send the offer details externally (see “How do I send an offer outside of Lever?”). On this topic, we also recommend reviewing the ability to create offer custom fields that do not require re-approval (see “editable without requiring re-approval”).
Summary
There's a lot more to Lever's data model than summarized above, but in our experience, a majority of reporting and reporting challenges relate to the topics covered here. Conceptually, one of the biggest takeaways here is that these core Lever objects are mostly independent despite having some optional dependencies across each other, and the core fields of interest such as Recruiter or Hiring Manager can be different on different objects. This isn't a blocker, as we can help you report and identify such cases, but it is a point that can lead to unexpected results or confusion in report results. If you have a question, or a specific point of interest or suggestions, feel free to reach out to the Ashby team!