Inter-authority transfer in ESR: why staff lose system access when they move Trusts

An experienced theatre nurse moves to a neighbouring Trust. She is fully trained, in date for every statutory and mandatory subject, and has used the same EPR product for years. On her first morning she can't log in to it.

The access request is stuck because the new Trust's records show her information governance training as missing. Her manager raises a ticket, learning and development ask her to redo the course, and she spends part of her first shift on e-learning she completed months ago.

Nobody in that chain made a mistake. The ESR inter-authority transfer did what it was designed to do. It just hadn't finished yet, and every system downstream assumed it had.

An inter-authority transfer (IAT) copies information held in ESR from a person's previous NHS employer to their new one, so the new organisation doesn't have to key it in again. It needs the person's consent, and it matches them on their National Insurance number, name and date of birth.

In practice it runs in stages. In the process NHSBSA's HR shared services describe, a pre-hire IAT runs at offer stage to confirm previous service and pay, and a hire IAT runs after the person has started, copying the Portable Data Set: NHS service history and, for training, the competencies aligned to the Core Skills Training Framework. (The Portable Data Set is unrelated to PDS, despite the shared initials.)

That sequence is sensible for HR. For integration, the important detail is the timing. The record that downstream systems read exists from the start date. The competencies that make it compliant arrive later.

1. The transfer is treated as a new starter. Provisioning sees a new assignment, creates new accounts and applies new starter rules: no compliance, no access until training is done. Nothing in the flow knows this person is mid-transfer.
2. Competencies arrive after the start date. Systems that gate access on compliance, such as access that depends on information governance training, read the new record during the gap and find it empty.
3. Identity is matched on the wrong key. Employee numbers belong to an organisation, so a transfer gets a new one. Any integration that matches people on employee number sees two different people, and anything held against the old record doesn't follow.
4. National and local identities are handled as one. Some identities belong to the person and are designed to move with them. Local accounts belong to the organisation and are designed to end with the assignment. When a leaver event at the old Trust and a starter event at the new one are processed without that distinction, the person can lose access they were meant to keep.

The Trusts that handle transfers well tend to share the same design.

Recognise the transfer as a mover event. When ESR shows a new hire with IAT consent and previous NHS service, the integration flags the person as transferring, not as new. Downstream rules can then behave differently.

Give the gap a known state. Between the start date and the hire IAT, the person is "transfer pending", not "non-compliant". Systems that gate on compliance can apply a short, defined rule during that window, agreed with the IG Lead, rather than defaulting to no access.

Key on stable identity. Match people across organisations on the identifiers the IAT itself uses, not on local employee numbers, and keep the link between old and new records.

Reconcile when the hire IAT completes. When competencies land, the integration rechecks every gated system for that person and lifts the pending state. If the hire IAT hasn't run within a set time of the start date, it alerts the workforce team, because a stalled IAT is the root cause of the next access ticket.

**Log every change at field level.** When access is granted on a pending rule, the record shows which rule, who agreed it and when it was cleared. That is what makes the pending state defensible in an IG review.

List every system whose access is driven by ESR data, and for each one, note what it reads to decide whether to grant access: a competency, an assignment, a position, or nothing at all.

Then take the last few staff who joined on transfer and trace what each of those systems did for them in their first week. The gaps you find will match the four reasons above, and the pattern of those gaps tells you which hand-off to fix first. If it helps to see that flow built and tested end to end, it is the kind of mover logic the ESR processors in WeHub Studio are designed around.