HR Tech · Anonymous delivery

One candidate, many data sources

The platform brought together candidates, applications and data from external ATS platforms across multiple business accounts. We implemented deterministic identity reconciliation and controlled state updates between systems.

Verified delivery outcome

Consistent candidate mapping, controlled persistence of ATS applications, and safe paths for repairing historical data and protecting telemetry.

System view

Recruiters saw one profile. The system had to reconcile many records.

Email addresses, phone numbers, applications and data from several sources had to be joined within the correct business account before they reached a recruiter's daily workflow.

Illustrative recruiter dashboard connected to several ATS platforms through a candidate-identity and application-reconciliation layer — Illustrative reconstruction based on the delivered workflow. Client branding, interface, data and ATS providers have been replaced.

Context

Candidate identity did not end with one email address

In a mature HR platform, a candidate can return through another ATS, use a different phone number or apply for another role. The system must recognise the same person without joining records that belong to a different business account.

Client context: A modern multi-tenant HR Tech platform supporting recruitment, candidates, applications, communication and many external integrations.
CODEVENOM role: Subcontracting delivery within a broader engagement. The company identity, ATS providers and original interface remain confidential.

Problem

The same candidate could enter the platform through several paths

The risk sat at the boundary between external ATS platforms and the internal data model. A record that was valid in isolation could become a duplicate or conflict only when its application was mapped.

One person could appear under several email addresses and phone numbers.
An external ATS application had to be linked to an existing candidate, talent record and recruitment process.
Several external applications could resolve to the same internal record and trigger a uniqueness conflict.
Historical attachments and records needed a repair path without an unsafe all-or-nothing migration.

Illustrative map showing three records for the same person with different email addresses, phone numbers and ATS applications before reconciliation — The reconstruction shows a class of problem verified in delivery. People, data, ATS names and interface are fictional.

Scope

The scope covered identity, application state and safe operational boundaries

The work focused on the places where different representations of the same person crossed from integrations into the platform's internal workflows.

Candidate matching across multiple email addresses and phone numbers
Persistent storage, mapping and updates for applications received from ATS platforms
Event-based coordination and protection against record collisions
Controlled data repair, telemetry protection and limits for AI-service usage

Approach

Establish identity before synchronising state

Instead of adding more exceptions to individual importers, matching and conflict-resolution rules were brought into one controlled, tested flow.

01
Collect every available identifier instead of relying on a single field.
02
Match records only within the correct business-account boundary.
03
Prefer the newest external data using explicit timestamps.
04
Update applications idempotently, coordinate through events and test conflict scenarios directly.

Five-step flow from collecting identifiers through tenant-boundary checks and candidate matching to conflict resolution and a controlled application update — Method overview: identifiers → tenant boundary → match → resolve → controlled persistence.

Delivered changes

Rules no longer depended on one importer

The solution was a set of mechanisms that reconciled data as it entered the platform and left a safe route for repairing the existing state.

Central candidate reconciliation across multiple emails and phone numbers with explicit conflict resolution
An external-application model, mapping to internal records and controlled upserts
Guards against assigning several applications to the same record or violating uniqueness constraints
Dry-run mode and historical attachment repair without forcing a one-off migration

Result

The platform gained controlled data-reconciliation points

The delivered work moved candidate and application matching into explicit, testable rules. The available evidence supports these system mechanisms; it does not include measured recruitment time, process cost or a percentage reduction in errors.

Before-and-after comparison of scattered candidate and application records with a shared identity, ATS mapping, controlled repair and data-protection model — Illustrative before and after. Results are stated at system level without unsupported operational metrics.

Related service

When every ATS integration creates its own version of a candidate

We take over existing systems, map data flows between integrations and stabilise identity rules and critical operations before proposing a larger rebuild.

Explore takeover & stabilisation

Start with the data flow

Does the same candidate exist in three systems?

Show us the integrations, candidate model and point where applications begin to diverge. We will help separate the source problem from the error visible in the team's daily work.

Start a project