Keep the role, application ID and counting definition beside the result. Current active applications answer where work sits now. Recorded stage history answers which stages have evidence of a visit. Neither view alone establishes a finished-cohort conversion rate.
Start with one role and five original records
Fictional role R1; snapshot October 13, 2026. Each ID represents one application to R1. There are no actual applicant identities, hiring decisions or demographic attributes in this example.
| Application | Current state | Explicitly recorded stage history |
|---|---|---|
| C1 | Review; active | Review |
| C2 | Review; active | Review |
| C3 | Interview; active | Review → Interview |
| C4 | Offer; active | Review → Offer directly |
| C5 | Withdrawn | Review → withdrawal |
The role's configured stages are Review, Interview and Offer. Tests is not configured for R1. Label that state explicitly instead of substituting a zero that suggests an available stage with no applications.
Count the current active applications
The current-active view contains C1, C2, C3 and C4:
- Review: 2, from C1 and C2.
- Interview: 1, from C3.
- Offer: 1, from C4.
These mutually exclusive current states total 2 + 1 + 1 = 4 active applications. Show one withdrawn application, C5, separately. Including C5 in the active Review count would erase its withdrawal.
Keep “R1; current active; October 13, 2026” visible above this view. If another role is selected later, refresh the application IDs, stage configuration and counts together. Carrying R1's Tests label or history into another role would create a result without matching evidence.
Count explicit visits without inventing a missing event
For this exercise, the history view includes all five applications, including the withdrawn one, and counts only explicitly recorded stage visits. Count each application once per visited stage even if a future record contains repeated visits.
| Recorded stage | Applications with an explicit visit | Count |
|---|---|---|
| Review | C1, C2, C3, C4, C5 | 5 |
| Interview | C3 | 1 |
| Offer | C4 | 1 |
| Tests | Not configured for R1 | Not configured |
The stage counts overlap. Adding 5 + 1 + 1 produces seven stage memberships, not seven unique applications. There are still five distinct application IDs in this supplied history.
C4 has an Offer event and a documented direct move from Review. An Interview event is not supplied. Preserve that jump note; do not create a visit merely to make the funnel look linear. C5 remains in historical Review because that visit occurred before withdrawal.
Check the reporting system's definition
Greenhouse's current-pipeline documentation distinguishes current and historical display options and explains the difference between zero and a stage absent from the job. It also warns that its linear-progression reporting can include skipped intermediate stages.
The explicit-event view above intentionally avoids that inference. It is an original reconciliation exercise, not an exact reproduction of a Greenhouse report or export. When importing a report into a workbook, document its actual counting rules before comparing it with recorded event history.
A configured stage with no matching applications can correctly show zero. An unconfigured stage should show not configured. Missing event data is another state again: it calls for investigation, rather than an invented visit or a confident claim that no visit ever occurred.
Make the workbook support both views
Use a role/stage-configuration sheet, an application snapshot sheet and a stage-event sheet. Retain the role ID and application ID in every join. The snapshot supplies current state and active/withdrawn status; events supply the history evidence. Do not let a presentation chart generate the missing source events.
Place the current-active total, withdrawn count and explicit-history definition where a reviewer can inspect them together. Offer status does not establish an accepted offer or a hire. This unfinished snapshot supports reconciliation and workload questions, not applicant ranking or a completed hiring outcome.
Copy a recruiting dashboard brief
Prepare a recruiting dashboard specification in US English.
Maintained ATS or workbook and required format: [enter]
Role IDs and configured stages: [paste]
Application IDs, role IDs, snapshot states and active/withdrawn status: [paste]
Explicit stage events, direct jumps and snapshot date: [paste]
Source-report counting rules: [paste or NOT SUPPLIED]
Separate current-active counts from explicitly recorded historical visits.
Show role scope, included IDs and snapshot date. Keep withdrawn applications
separate in the current view; state whether history includes them.
Deduplicate each application within each visited stage. Do not add overlapping
stage counts as unique people or infer skipped visits. Preserve jump notes.
Distinguish configured-zero, not-configured and missing-evidence states.
Do not infer hires, accepted offers, applicant rankings or completed-cohort
conversion from an unfinished snapshot.
Return the source-sheet design, checked counts and labeled views in the
required format. If requested, specify a sanitized HTML review snapshot
with local current/history selection. No hire/reject/send controls, ATS
integration, saved editing, automatic decisions or live refresh promises.
Reconcile C4's jump and C5's withdrawal with the maintained application records before sharing the counts. NOS can save and display a sanitized HTML review snapshot that puts the IDs beside the two counting definitions. Keep the ATS or workbook as the maintained source, and resolve missing stage evidence there before describing a visit as recorded.