One Candidate, Multiple Jobs: Prevent Cross-Role Status and Evidence Errors

Three entities that must not be collapsed

Person: identity and appropriately shared contact details, subject to permissions and retention rules. This layer can help detect duplicates and prevent unnecessary outreach.

Application or job consideration: the relationship between that person and one role. It has a specific brief version, stage, owner, source and decision. A decline belongs here unless an explicitly justified broader restriction applies.

Evidence item: a statement, document excerpt, interview observation or verification record with provenance and scope. An item may be relevant to more than one role, but its interpretation is not automatically portable.

Current ATS documentation makes this distinction concrete. Ashby explains why reporting on applications is usually more useful for pipeline stages, and Greenhouse lists application-specific fields separately from candidate-specific fields. Workable also maintains job-specific candidacies for the same person.

A worked example with two different bars

Imagine that a candidate has operated Kubernetes workloads and performed security reviews. The infrastructure role requires owning on-call incidents; the security role requires threat modeling and review of access controls. The same resume is relevant to both, but each role has a different missing piece.

For the infrastructure application, record that incident ownership is not yet established and request a specific example. For the security application, record the threat-modeling excerpt and ask about the scope of responsibility. Do not average these into one global match score. A 70 percent overall score would conceal why the candidate is worth interviewing for one role and uncertain for the other.

If the security manager later confirms an example that also informs the infrastructure role, that new evidence can be considered where access and purpose allow. It still needs to be evaluated against the infrastructure criteria and recorded as a separate decision.

The difference between copying and transferring

Copying a candidate into another job creates or maintains a separate job consideration. Transferring can change the existing application relationship and its reporting history. The exact behavior differs by ATS and configuration, so check the system documentation before building an integration.

In Workable, copying creates independent job profiles while moving removes the person from the original job pipeline. Ashby preserves historical information during certain transfers. Neither action should be treated as a harmless user-interface shortcut. Test the implications for stage history, scheduled interviews, attribution and communications.

Keep one identity without merging the wrong people

Duplicate detection often uses email, phone or profile links, but those identifiers can change or be shared. A matching name is especially weak. Before merging profiles, review conflicting contact details and documents. Greenhouse and Ashby both warn that reversing a merge can be difficult or impossible through the normal interface.

A safe workflow marks potential duplicates for review and preserves a traceable decision. It does not merge people automatically because a fuzzy name match crossed an arbitrary threshold. The cost of a false merge can include exposing private notes to the wrong reviewer and corrupting application history.

Do not leak decisions across permission boundaries

An external agency recruiter might be authorized to see one vacancy but not another. A hiring manager may have access to the candidate profile but not to a confidential application. The existence of a second application does not grant access to its interview notes, protected information or rejection reasons.

Design the review layer to inherit job-level permissions. When displaying a shared candidate profile, reveal only the information the viewer is allowed to use. Test with two users who have different access scopes, not only with an administrator account.

Counting candidates and counting applications

Suppose eight people generated twelve applications and four interviews. The unique-person count is eight, the application count is twelve and the interview count is four. If the agency reports twelve candidates, it inflates reach. If it reports only eight applications, it understates screening workload. Both views are useful when labelled accurately.

Use candidate counts for questions about unique people and application counts for questions about job-level outcomes. Keep sources and ownership attached to the relevant job consideration. A candidate sourced for one vacancy can later apply directly to another, and attribution should not be guessed from the oldest record.

A practical cross-role QA checklist

1. Create one synthetic candidate with two applications and different statuses.
2. Verify that rejecting the first does not reject the second.
3. Change the brief for one job and confirm that only its evidence assessment becomes stale.
4. Confirm that a restricted reviewer cannot see private notes from the other job.
5. Test duplicate warnings without executing an irreversible merge.
6. Export the pipeline and check person counts against application counts.
7. Reconcile a candidate transfer and confirm that the original history remains intelligible.
8. Test a withdrawal or contact restriction and decide explicitly which scope it affects.

These tests are small, but they catch errors that can otherwise remain hidden until a client receives the wrong report.

Where a second-review tool should sit

An evidence layer such as RoleRise should reference existing candidate and application identifiers, process the approved job requirements and return a human-readable finding with source context. The ATS should remain the system of record for job stages, communications and decisions. Avoid inventing a parallel global candidate status that conflicts with the ATS.

When a reviewer corrects an extracted skill or employment date, keep the correction and its provenance. Do not silently overwrite every application with the new interpretation. The same fact may be reusable, but its significance changes with the role.

Three records and two invariants for every ATS integration

Represent the data at three levels: person_id for identity and permitted contact details; application_id + job_id for stage, status, reason and decision history; evidence_id + source_application_id + brief_version for the assessment and its provenance. Evidence may be considered in another application only after an authorized reviewer checks relevance, freshness and access.

These are implementation design rules, not claims about a specific vendor’s schema. Workable and Lever document role-specific candidacies/opportunities. Greenhouse distinguishes adding an application from moving an existing one.

Four synthetic tests to run before release

1. Reject isolation: Create one synthetic person with applications A and B. Reject A and assert B remains unchanged, with no accidental notification for B.
2. Evidence isolation: Give A a role-specific interview note visible only to Team A. Open B as Team B and confirm the restricted note is not disclosed.
3. Merge safety: Simulate two distinct people with a shared email alias, and one person with changed contact details. Neither case should merge automatically without a reliable identity review.
4. Count correctness: Eight synthetic people, twelve applications, three interviews: person count = 8, application count = 12, and job-level funnel denominators use applications.

Run these checks on test data, not live candidate records. Preserve an audit log of the actor, before/after values and external integration events. In Greenhouse’s merge documentation, candidate IDs can change after merging, which is a concrete reason to test downstream integrations.

The merge approval gate: prevent an irreversible mistake

Before combining profiles, require a human reviewer to inspect identity signals, conflicting employment histories, active job applications, confidentiality flags, permission scope and linked external IDs. Matching name alone is weak evidence; matching email alone can also fail with shared inboxes or recycled addresses. The goal is to prevent false merges, not to collect unnecessary personal identifiers.

Some systems do not support unmerging. That makes a cautious review and a recovery plan more valuable than an aggressive auto-merge rate. Document retention and deletion per person and per application without overriding lawful requirements.

FAQ

Does a rejection mean a person should never be considered again?

No. A job-specific rejection is not necessarily a global exclusion. Any broader restriction needs its own policy, scope and lawful basis.

Should the same resume be scored once for all jobs?

Extracting factual content once may be efficient. Evaluating suitability must still use the requirements and evidence standard of each job.

Can a duplicate merge be safely automated?

Only with a well-tested identity policy and a clear recovery path. Where merging is difficult to reverse, manual review is often the safer default.

Keep the person connected and the decisions separate

The goal is not to create more records for their own sake. It is to preserve one coherent person history while allowing each role to have an accurate, reviewable decision. That is the foundation of useful cross-role matching.

Research basis and implementation notes

Selected primary guidance, regulator material and implementation documentation are linked below. Vendor documentation describes product behavior; it is not independent evidence of hiring effectiveness. The full research register and source classifications accompany this file.

• Workable: How to see multiple-role candidacies — Each job can have a separate candidate profile/evaluation despite one person..
• Lever: Lever glossary: candidate and opportunity — A candidate may have several opportunities with their own stages and job context..
• Greenhouse: Add candidate to another job — Adding to another job creates a separate application while retaining the original..
• Greenhouse: Auto-merge — Different-job merges preserve application-specific data; rules vary by status..
• Greenhouse: Merge duplicate candidate profiles — Merges may change candidate IDs and affect downstream integrations..
• Greenhouse: Can candidate profiles be unmerged? — Some systems cannot reverse an incorrect merge..
• Greenhouse: Reject a candidate — Some rejection flows offer an all-jobs option; it is not the same as a job-level rejection..
• Lever: Anonymizing candidate data — Anonymization can depend on whether other opportunities remain..