How the Data Actually Moves

Every join is implemented one of four ways, and each fails differently.

Scheduled file transfer

A file produced nightly and collected by the other system.

Old, reliable, and still the commonest arrangement in payroll.

Fails by: the file not being produced, being produced empty, being produced twice, or arriving in a changed format after an upgrade.

Needs: a check that the file arrived and that its record count is plausible. Most implementations have neither.

API calls

One system asks another, or pushes to it, on an event.

Timely, and the failure mode is a silent error code that a retry loop swallows.

Needs: a delivery log that can be queried, retry with backoff, and a way to replay a failed period.

Ask whether the vendor offers replay, because without it a failed hour is reconstructed by hand.

Webhooks

The source notifies the destination when something changes.

Better when they work; they fail invisibly. A missed delivery is a gap nobody notices.

Which is why the reliable arrangement is webhooks for timeliness plus a nightly reconciliation for correctness — inelegant and much easier to verify.

Manual export

Someone downloads a file and uploads it elsewhere.

Common, and honest if it is documented.

Fails by: the person being on leave, the wrong period exported, a file edited in a spreadsheet on the way through.

Where a join is manual, name the person and the deputy, because the deputy is the actual control.

Idempotency

The property that matters more than the mechanism.

Sending the same data twice should not create duplicates.

Without it, every retry and every replay is dangerous, and a failed transfer becomes a decision rather than a rerun.

Ask about it explicitly. Vendors rarely volunteer that their import is not idempotent, and it is the difference between a five-minute fix and a day of cleanup.

What to require regardless of mechanism

A record that the transfer happened, with counts.

An alert when it did not.

A replay path.

And a reconciliation that does not depend on the transfer's own reporting, because a broken join reporting success is the failure this whole subject is about.

Ask about idempotency by name

The property that decides how every future failure is handled.

Sending the same data twice should not create duplicates.

Vendors rarely volunteer that their import is not idempotent.

Without it, a failed transfer becomes a decision and a cleanup; with it, a rerun.

Ask in writing and attach the answer to the contract.

Connect policy and data

The choices in this note can be compared with view supported connections. Keep the written purpose in control and enable only the information needed at this boundary.

Independent reference

For a thematic point of reference, see Postman. Use this established source as an outside check before turning the principle into a system rule.