HR activity arrives as email. Workday needs a row.

The situation

Two shapes, and a person in between.

An HR operations function receives the raw material of its records the way it has for twenty years: as email. Someone writes three lines, attaches a file, and sends it. The attachment is a PDF one month, a spreadsheet the next, a phone photograph of a printed page the month after. Sometimes the figures are in the body and there is no attachment at all. Often the message is a forward of a forward, with the person the record actually belongs to buried four quote levels down.

Workday — or whatever sits downstream as the system of record — wants none of that. It wants a row: person, assignment, period, quantity, state. The distance between an inbox and that row is currently closed by a person reading mail and retyping. That person is the integration.

The failure mode

Why pointing a model at the inbox does not work.

A language model reads most of these messages correctly. It also does two things, reliably, that you cannot put into a system of record. On a forwarded chain it attributes the record to whoever forwarded it rather than to whoever it belongs to. And when the attachment is a low-quality image, it produces a plausible figure rather than declining to answer.

Both failures are silent. A wrong row in Workday is shaped exactly like a right one — same fields, same types, same confidence. Nobody finds it at ingest. It is found at audit, or at payroll, or not at all.

Architecture

Identity is resolved by rule. Only extraction goes to a model.

1. 01

   Sender binding, not sender inference

   Every inbound address is matched against a map binding addresses to people and their active assignments. A person legitimately writes from three addresses; all three are bound to them. An unbound address produces no record at all — the message is refused and held. A human maps it once, and mail from it files without asking after that. The model is never permitted to answer the question of whose record this is.

2. 02

   Extraction inside a resolved context

   Once the sender resolves to a person and an assignment, the extraction problem collapses. The model is not asked what the message is about. It is asked to find known values in a document whose expected shape is already implied by the assignment. Format stops mattering: PDF, spreadsheet, and image attachments all reduce to the same structured assertion.

3. 03

   Every figure carries its provenance

   No value exists in the system without a link back to the message, the attachment, and the span it was read from. Full receipts on every number is what makes the output safe to push downstream — when the HRIS disagrees with the record, the disagreement is settled by evidence rather than by argument.

4. 04

   Absence is a first-class event

   A system built around inbound mail only sees what arrives. The expensive failure in HR operations is the record that never came, discovered on filing day. This system holds the expectation rather than only the receipt: it knows which assignments owe a record for which period, and it raises the gap before the deadline rather than after it.

5. 05

   The queue is exceptions only

   What reaches a person is the unbound sender, the missing period, the figure that contradicts the assignment. Everything else files itself, confirms back to the sender over email, and appears in the aggregate view. The reviewer opens a short list of genuine decisions, not an inbox.

6. 06

   Read-only against the mailbox

   The agent reads and files. It does not delete, move, or rewrite the source message. The mailbox stays intact as the evidence layer, which means the system can be re-run, re-checked, or removed without loss.

In operation

What it looks like running.

• Records land structured per person, per customer, per period, with expected against received visible across a rolling window
• Heterogeneous attachments — document, spreadsheet, and photographed page — reduce to one record shape
• A forwarded chain from an unrecognised external domain is refused and held rather than guessed at
• Confirmation goes back to the sender automatically the moment a record files
• A period with nothing in it raises itself before filing day, with the choice to chase or to record why it is empty
• Every figure on every screen opens to the message and attachment span it came from

On screen

The system, as the operator sees it.

Downstream

The output is a row, not an inbox.

The point of the structured capture is what happens after it. Once an activity record exists as a validated row with provenance attached, pushing it into Workday, or into an adjacent HR or payroll system, is an ordinary integration against ordinary data. The hard part was never the API. The hard part was arriving at a row that is worth sending.

That ordering matters. Teams usually attempt this in reverse — they build the integration first, then discover the upstream data is email, then staff a person to sit between the two permanently. Capturing the record correctly is what removes that person from the loop, and it is the only part that has to be got right.

What transfers

The reliability did not come from the prompt.

It came from refusing to let the model answer the question that mattered most. Whose record is this is a lookup, and lookups do not hallucinate. Handing it to a deterministic sender map cost a small amount of setup — one mapping per address, once — and removed the entire class of silent misattribution.

What was left for the model is the part it is genuinely good at: pulling known values out of an unpredictable document. Narrow the question enough and the model stops being the risk in the system.