Written for the CIO and digital leader rather than the interface engineer: the framing throughout is time-to-ready, clinical capacity and IG exposure, with just enough mechanism (the validation gate, the exception queue, reconciliation) to make the fix concrete and fundable. Deliberately operational rather than promotional, and kept distinct from solution-page copy by centring the failure modes and the movers-and-leavers half of the problem. Pairs with the deeper ESR integration guide for the reader who wants the full pipeline.
A newly recruited nurse arrives for a first shift. The ESR record exists, HR did their part weeks ago, and yet: no network account, no smartcard access sorted, no roster entry, a badge that opens nothing. A ward manager spends the first morning of a scarce clinician's employment on the phone to three different helpdesks.
Ask around and this story exists in every Trust, usually told as bad luck or someone's oversight. It's neither. It's the predictable output of an onboarding flow made of manual hand-offs between systems that never agreed to talk to each other, and it fails structurally, not occasionally.
In brief
Workforce onboarding is really a chain of data hand-offs: a record created in ESR must propagate, in different shapes and on different timetables, to rostering, identity and access, occupational health, training and more. In most Trusts those hand-offs are manual rekeying or fragile point-to-point feeds, so they break on timing, on partial data, and in silence. The reliable pattern is a single automated flow: ingest the ESR data, validate every record against a schema before anything downstream sees it, transform per target, and post to each system, with failures routed to an owned exception queue and starters reconciled against systems provisioned. The same flow, run with effective dates, is also how movers and leavers stop being an IG risk.
The hand-offs hiding inside "onboarding"
"Onboarding" sounds like one event. Operationally it's a fan-out. From a single new-starter record, some subset of the following needs to happen: a rostering profile with the right ward, band and working pattern; a network identity and email account; access provisioning appropriate to role; an occupational health workflow; statutory and mandatory training assignment; and payroll details confirmed in time for the first run. Each destination wants different fields, in a different shape, at a different moment, and each is owned by a different team.
That's the part leadership rarely sees. The visible metric is "time to hire". The hidden one is time-to-ready: the gap between a person's first paid day and the day every system actually lets them work. Every day inside that gap is paid, rostered, clinical time the Trust can't fully use.
Where the flow actually breaks
The failure points are consistent enough to list.
- Timing. ESR data moves on batch cycles; a starter's first shift doesn't. A record confirmed on Friday that propagates over the weekend is fine. One confirmed the afternoon before a Monday start is a morning of phone calls.
- Partial data. An assignment not yet fully confirmed, a missing start date, an unmapped cost centre: downstream systems don't negotiate, they reject. And they usually reject silently, into a log nobody owns.
- Rekeying. Where no feed exists, an administrator re-types ESR data into the rostering system or an access request form. Every re-type is a chance for the variance that later surfaces as a payroll query or an access mismatch.
- No feedback loop. HR's job ends when the ESR record is right. Nothing tells them the record failed validation in a downstream system, so the person best placed to fix the data never learns it needs fixing.
Notice that none of these is anybody's negligence. They're the seams between teams, which is exactly where unowned work goes to die.
The automated pattern: ingest, validate, transform, post
The fix is a single visible flow doing what the manual chain pretends to do.
Ingest the ESR starter data as it arrives on its feed. Validate every record against a schema before anything downstream sees it: mandatory fields present, dates coherent, identifiers well-formed. This gate is the heart of the design, because it catches the record that would have failed in rostering while there's still time to fix it, and routes the failure to a named owner with a notification rather than a log entry. Transform the validated record into each target's expected shape: one mapping for the rostering platform, another for the identity request, another for training. Post to each system over its own interface, capturing every response.
Around that spine sit two habits that make it trustworthy. Exceptions land in a queue a human is accountable for working, on an agreed timescale with HR. And a reconciliation step compares starters expected against starters actually provisioned in each target, so "did onboarding work this week?" has a number rather than a feeling. In WeHub Studio this is a configured workflow built on the ESR processors rather than a development project, which matters mostly because onboarding rules change often, and a flow you can see is a flow you can change safely.
Movers and leavers: the half nobody automates
Trusts that automate starters often stop there, and the second half is arguably more important. Movers change wards, bands, cost centres and managers; when those changes don't propagate, rostering drifts from reality and costs land in the wrong ledger. Leavers are the sharp end: a leaving date in ESR should reliably trigger deprovisioning everywhere access was granted, because an account that outlives its owner's employment isn't an admin untidiness, it's an information governance exposure with a name and a date attached.
The good news is that this isn't a second project. The same ingest-validate-transform-post flow, driven by effective-dated changes rather than new records, covers all three populations. Starters get you the business case; leavers are why the IG lead will thank you.
What to fix first
Resist the urge to automate everything at once. Pick the single hand-off that generates the most day-one failures, which in most Trusts is ESR to rostering, and build the full pattern for that one flow: the validation gate, the exception queue with a named owner, the weekly reconciliation count. Then measure time-to-ready for one month of starters, before and after.
That number does two jobs. It proves the approach to the people who fund the next flow, and it reframes onboarding for the board: not an HR admin topic, but clinical capacity being handed back, one reliable hand-off at a time.
