Hire to Retire Runs on One Event

Hire, transfer, leave, return, termination: each one is a decision somebody with authority has already made and already recorded. What follows it is not new information. It is the same fact being carried by hand to an account, a badge, a desk, a licence, a piece of hardware, because no channel exists to carry it.

So the effort scales with the number of destinations rather than the number of hires. Add a system and you have not added a system; you have added a re-entry, and it lands on the recruiter, the HR business partner and the hiring manager, none of whom appear in the business case that added it.

What actually happened

Polymath’s founder led workforce planning, transformation and the PMO in a private CPG business of roughly $2–3 billion in revenue that had gone public on the TSX, with people across more than twenty offices. The mandate was a hybrid one, sitting across HR, finance and technology at once, which is the reason this particular problem was addressable at all: it did not live inside any of the three.

A hire was recorded once, properly, by the recruiter. Then it was recorded again. Once in a ticket to IT so that an account could exist. Once by email to facilities so that a desk and a badge existed. Once more so the new starter could reach SAP, and again for a product development engineer who needed hardware and Planisware access before the work could begin. Every one of those was a person retyping a name, a start date, a manager, a location and a cost centre that the HR system already held and had already validated.

Termination ran the same way and carried more weight. An account still live after somebody’s last day is not an inconvenience; it is an access exposure with a date on it, and under that design it depended on someone remembering to raise a ticket in the week they were least likely to.

What the team built was deliberately narrow. Workday held employment status, so Workday was made the author of it, and an outbound integration carried that status to Azure Active Directory. A hire activated the account. A termination deactivated it, and every application authenticating against that directory inherited the change without being told separately. One link, and the exposure was settled by design rather than by diligence.

The second link is the one the organization felt. The same employment event opened the ServiceNow tickets IT already used — for SAP access, and for the hardware and Planisware provisioning a product development hire needs — carrying the Workday fields into the ticket instead of asking a person to retype them into a form.

IT kept its own workflow exactly as it was. Nothing changed about how a ticket was triaged, queued, approved or closed; the difference was that it arrived already populated, on the day the employment event happened, from the system that owned the fact. That is the part worth carrying into any client: the receiving function does not have to be reorganized for the sending function to stop re-entering.

Onboarding ran off the same trigger. The Workday business process collected what facilities, HR and the hiring manager each had to supply — the things no system can know — and routed each request once, to the person who held the answer, at the point the answer was needed.

Recruiters, HR business partners and managers stopped re-entering. None of them gave up a decision; they gave up the typing. The outbound integration sent what the record already held, and the hours came back to the people who had been acting as the transport layer between two systems.

Polymath builds that spine for clients in the same order — the event first, the platforms after — because the order is what decides whether the receiving teams have to change anything at all.

Why it happens

Employment events are authored in HR and consumed almost entirely outside it. The HR platform is bought, scoped and justified on HR outcomes, and the downstream consumers — identity, application access, facilities, procurement, engineering tooling — appear nowhere in that business case, so nobody costs the channel between them.

HR owns the event. IT owns the destinations. The link between the two is the one asset neither function has a budget line for, and it is the only asset that makes either of their systems work as intended.

Re-entry is also genuinely cheap per instance. Three minutes, one form, no ticket, no approval. It becomes material only in aggregate, and nothing aggregates it: the cost is spread thinly across hundreds of people, in a unit nobody reports. At implementation time the manual path is the low-friction choice, and it is chosen for a sound reason. An integration requires two functions to agree which of them authors each field and what happens when their records disagree. A form requires only a form. The decision that gets deferred is a decision-rights one, and it is deferred into a queue.

The two ends of the lifecycle are also asymmetric. A hire has an eager owner: the new starter chases their own laptop. A termination has none, because the person who would have noticed has left, and the manager who would have raised it is covering the gap.

Then each new application repeats the same decision locally, and by the tenth the pattern is invisible, because no single person has seen all ten. What looks like ten small conveniences is one design running ten times.

The strongest objection

The strongest case against this: identity belongs to IT, and an automated deactivation firing on a wrong date locks out somebody who is still employed. Handing HR a switch into production systems is not a trade most CIOs should make.

Concede it, because it is right, and it is the argument for building an event channel rather than a shared process. The integration gives IT no new master and HR no new authority. It gives IT an earlier, machine-readable statement of employment status, and IT keeps triage, approval, timing and the ability to hold. Where the founder’s team built this, IT’s own workflow was the thing most carefully left alone.

The data-quality objection is the fair one. An integration publishes every wrong record you hold, immediately, to an audience outside HR, and the first month of one is unflattering. That is true — and those records were already wrong. Re-entry was absorbing the error quietly, one correction at a time, by people who had stopped reporting it. Surfacing it is the point, and the first month is the cheapest month to have it.

The better objection is that the platforms already ship the connectors, so this is configuration rather than redesign. Partly true. What does not ship is the answer to who authors each field, and what the correct behaviour is for a rehire, an internal transfer between legal entities, a leave of absence and its return, a contractor converting to employee, and a start date that moves twice. Those are the cases a connector cannot settle, because they are decisions rather than settings.

The method

We run six steps, in this order. The first two are what make the remaining four hold.

1. We trace one hire and one termination end to end before we design anything. We follow a single real event to every system, form, spreadsheet and inbox it reaches, sitting with the people who touch it. The trade-off we accept: a week before any build is scoped. Skip it and you integrate the process as documented rather than the one being run, and the difference between the two arrives as exceptions after go-live.
2. We name one author for each field, and say so in writing. Employment status, start and end dates, manager, location, legal entity, cost centre: each gets exactly one system that may originate it and everyone else a copy. The trade-off we accept: this is a decision-rights negotiation between HR and IT and it takes longer than any plan allows for it. Skip it and two systems both believe they are authoritative, and your integration resolves the disagreement by timestamp.
3. We make the event the trigger rather than the calendar. The link fires when the employment event is recorded, not on tonight’s batch, because on a termination a nightly cycle is a day of live access and on a hire it is a day of a new starter waiting. The trade-off we accept: event-driven links need retry and failure handling that a batch does not, and that is real engineering. Skip it and the control argument that funds the work disappears with it.
4. We deliver into the receiving team’s existing workflow, untouched. The ticket, queue or form IT and facilities already use stays exactly as it is; it simply arrives populated from the record. The trade-off we accept: we inherit their process, including the parts we would have designed differently. Skip it and an integration becomes a change programme inside a function that never asked for one, which is where most of these stop.
5. We design the exceptions before the standard path is signed off. Rehire, internal transfer across entities, leave and return, contractor conversion, a start date that moves, a termination entered after the fact. The trade-off we accept: the exception set is usually larger than the standard path and it lengthens design visibly. Skip it and each case returns as a manual workaround, and enough workarounds reconstitute the re-entry you just removed.
6. We switch the old path off, by name. The superseded form is retired, the tracking spreadsheet is archived, and the specific people who used to perform the step are told it is gone and what they get back. The trade-off we accept: some teams keep a shadow copy for a cycle, and we let them keep it. Skip it and both paths run in parallel, which costs more than either one did alone.

Three of those steps belong to HR, two to IT and one to the process owners in the business, and no platform programme convenes all three, so we convene them. That is why we run this as Process Redesign rather than as an integration project. The question that decides the outcome is not which connector to switch on; it is which function may author a fact and who is entitled to inherit it, and that runs the length of Hire-to-Retire and straight into identity and access. Redesign the event flow and the ticket volume falls without ever being targeted. Target the ticket volume first and the re-entry simply moves into email.

Evidence and measures

One employment event, and what it carried. Every row replaced something a person used to type:

Five measures worth tracking over ninety days. None of them requires a new system:

— Elapsed time from an employment event being recorded to the account being active or inactive, counted in hours.

— The number of systems into which one hire’s name, start date, manager and cost centre are typed by a person.

— Accounts still active more than twenty-four hours after a recorded last day, counted every month.

— The share of onboarding and provisioning tickets that arrive populated rather than composed by hand.

— Hours a month that recruiters, HR business partners and managers spend on provisioning administration, asked of them directly rather than inferred from a system. If those move, the event is carrying the work. If ticket volume fell while the same people report the same hours, the re-entry moved into a channel you are not measuring.

How Polymath solves this

We start with one hire and one termination of yours, and we follow each to every place the same fact is entered again. In the first weeks we produce the event map: which system authors each field, which systems consume it, where a human is currently the connection, and what each of those humans is doing that is judgment rather than transport. We run it as Process Redesign applied to Hire-to-Retire, with identity and access treated as part of the process rather than as a separate programme alongside it.

Then we build it, alongside your HR, IT and business teams rather than in place of them. The employment event becomes the trigger, the record becomes the author, and the downstream requests arrive in the queues your teams already work in, populated. Your receiving functions keep their workflows; what changes is what they are told and when. We hand back the event map, the field ownership register and the exception set to the people who will run them next quarter.

What compounds is that register. Once the authorship of each employment fact is written down and the spine is carrying it, the eleventh system costs a fraction of the first: it subscribes to an event that already exists rather than earning its own integration project. Your access position becomes evidenceable on the day rather than at audit, and the processes that still need a human turn out to be the ones that genuinely required judgment all along. That is also the precondition for anything agentic: an agent can act on an event, and it has nothing to act on while the event lives in somebody’s inbox.

What it costs to do nothing

The first cost has a date on it. Access that outlives employment is the one item on this list that is examined by somebody outside the company, and it is found in testing rather than declared. Remediation then runs on the auditor’s calendar rather than yours.

The second lands on the people you hired for judgment. Recruiters, HR business partners and managers spend their week as a transport layer between systems that could speak to each other, and that cost rises with headcount and again with every platform added. It never appears as a line, because it is denominated in attention.

The third is the first week of every new employee. A new starter who cannot reach the systems their job requires forms a view of the company in days five through ten that takes a year to revise, and the manager closing that gap manually is the same manager you are asking to get them productive.

The fourth compounds quietly. Every new platform inherits the manual pattern, so the eleventh integration is scoped and priced as though it were the first. Build the spine and it is nearly free; leave it and you buy the same connection eleven times.

The event already happened, and it was already recorded correctly, by someone with the authority to record it. Everything after that is a question of who is allowed to hear it.