HR activity arrives as email. Workday needs a row.

The situation

Two shapes, and a person in between.

An HR operations team receives 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, and a phone photo of a printed page the month after. Sometimes the figures are in the body and there is no attachment. Often the message is a forward of a forward, and the person the record belongs to is four quote levels down.

Workday, or whatever system of record sits downstream, wants a row: person, assignment, period, quantity, state. Today a person closes the gap between the inbox and that row by reading mail and retyping it. 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 makes two mistakes, reliably, that a system of record cannot absorb. On a forwarded chain it assigns the record to whoever forwarded it, not to the person it belongs to. And when the attachment is a poor image, it produces a plausible figure instead of declining to answer.

Both failures are silent. A wrong row in Workday looks exactly like a right one: same fields, same types, same confidence. Nobody catches 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 that binds addresses to people and their active assignments. A person may write from three addresses, and all three are bound to them. An unbound address produces no record. The message is refused and held. A person maps the address once, and mail from it files without asking after that. The model is never allowed to decide whose record this is.

2. 02

   Extraction inside a resolved context

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

3. 03

   Every figure carries its source

   Every value links back to the message, the attachment, and the span it was read from. That is what makes the output safe to push downstream. When the HRIS disagrees with a record, the evidence settles it.

4. 04

   Absence is a first-class event

   A system built around inbound mail sees only what arrives. The expensive failure in HR operations is the record that never came, discovered on filing day. This system tracks what is expected as well as what is received. It knows which assignments owe a record for which period, and it raises the gap before the deadline.

5. 05

   The queue is exceptions only

   What reaches a person is the unbound sender, the missing period, and the figure that contradicts the assignment. Everything else files itself, confirms back to the sender by email, and appears in the aggregate view. The reviewer opens a short list of real 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, so 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
• Document, spreadsheet, and photographed-page attachments all reduce to one record shape
• A forwarded chain from an unrecognized external domain is refused and held, not guessed at
• Confirmation goes back to the sender 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 structured capture matters because of what comes after it. Once a record exists as a validated row with its source attached, pushing it into Workday, or into another HR or payroll system, is an ordinary integration against ordinary data. The API was never the hard part. The hard part was arriving at a row worth sending.

The order matters. Teams usually try this in reverse. They build the integration first, discover the upstream data is email, and then staff a person to sit between the two for good. Capturing the record correctly is what takes that person out of the loop, and it is the only part that has to be 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. The question of whose record this is comes down to a lookup, and lookups do not hallucinate. Handing it to a fixed sender map cost a small amount of setup: one mapping per address, once. It removed the whole class of silent misattribution.

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