The order in which updates arrive isn't necessarily the order in which they happened. An integration that applies writes as they come in, with nothing to check their order, can let an older value replace a newer one. Every write succeeds, and the record can end up wrong.
Nothing unusual has to happen for this to occur. It's a normal property of systems that talk to each other over a network, and there are four common ways to handle it. They don't all solve the same problem, which is the first thing to get clear.
Three ordinary situations are enough:
Some systems say this outright. Stripe's documentation states that it doesn't guarantee the delivery of events in the order that they're generated, and tells integrations not to depend on receiving them in a specific order. The more systems write to the same records, and the more often they write, the more chances there are for writes to overlap. System count and update frequency are two of the five factors InAir tracks as Integration Load.
When an older value lands last and overwrites a newer one, the result is a stale overwrite, one of the three failure modes covered in write collisions.
Late and repeated deliveries cause two separate problems, and the mechanisms below address them differently.
Two rows are often misunderstood. Idempotency keys recognize an operation that's been seen before, but they don't compare it against newer changes. And a queue applies writes in the order they reach it, so a write that reaches the queue late is still applied late.
How it works: reject any write older than the last change already applied to the record, by comparing the stored timestamp of that change to the incoming one.
What it needs: each incoming write carries the sender's timestamp for the change, and you add a field to each Airtable record that stores that sender timestamp for the last write applied to it. That stored value is the one to compare against. Airtable's own Last modified time field won't work for this comparison: it records when Airtable applied a write, not when the change happened in the sending system. It suits a different check: whether a record has changed since a job read it.
Where it fits: integrations where the sender can attach a last-modified timestamp to each change. The case to watch for is two writes carrying the same timestamp. Stripe notes that its snapshot events record their creation time in seconds, so distinct events can share a timestamp, and it advises against using that timestamp to determine event order or whether an event has already been processed. Where two changes to the same record can happen closer together than the sender's timestamp precision, a timestamp can't tell them apart, and a sequence number can.
How it works: each write carries an incrementing number, and the receiver rejects anything lower than what it's already applied.
What it needs: both systems keep track of the counter. The sender increments it with each change. The receiver stores the last number it applied and sends that back, so the sender knows which version has landed.
Where it fits: integrations where the sender can keep a version per record, and anywhere timestamps can collide.
One caveat for both timestamps and versions: the check and the write are two separate steps. If two runs for the same record execute at the same moment, both can read the same stored value and both apply their write. Where that can happen, process writes for a given record one at a time.
How it works: each operation carries a unique identifier, and a retry sends the same identifier again. Stripe's implementation shows the pattern: it saves the result of the first request made with a given key, whether that request succeeded or failed, and a later request with the same key returns that saved result instead of running again. Stripe can remove keys once they're at least 24 hours old, and a key reused after it's been removed runs as a new request.
What it needs: the receiver keeps a record of the keys it has processed. When the receiver is your own logic in Airtable, such as a script that processes incoming webhooks, that means adding a table of processed keys that the script checks before applying anything, and writes to only after the operation succeeds. Four details decide whether it works:
Stripe gives the same advice for its own webhooks: log the event IDs you've processed and skip any that are already logged. InAir's guide to Webhook Payload Optimization covers the opposite direction: generating the key in an Airtable script, sending it in the payload, and a Double-Fire Test for checking whether the receiving system handles it.
Where it fits: retries and reruns, and anything that isn't safe to repeat, like creating a record. A partially failed automation that's rerun would otherwise resend the steps that already succeeded. Why a failed run leaves those steps committed in the first place, and the commit status field that records which steps finished, is covered in the partial commit problem.
What it doesn't do: order different operations. If a request's first attempt never reached the receiver, its retry is the first time that key has been seen, so it's applied, even if a newer update has landed in the meantime. For writes that can arrive late, pair idempotency keys with a timestamp or version check.
How it works: writes are placed in a queue and applied in a defined sequence rather than in arrival order at Airtable.
What it needs: a first-in, first-out queue between the senders and Airtable, set up so that writes to the same record are processed one at a time. In AWS, that means an SQS FIFO queue with the record ID as the message group; a standard SQS queue doesn't guarantee order. AWS describes FIFO queues as designed to enhance messaging between applications when the order of operations and events is critical, or where duplicates can't be tolerated. InAir's guide to asynchronous task queuing uses the same building block, a queue in the middleware layer such as AWS SQS or a Make.com serialized queue, to process work in the background.
A queue keeps writes in the order they reach it. A retry or a batch job that reaches the queue late is still processed late, so for those, pair the queue with a timestamp or version check.
Where it fits: records that several systems write often, where writes need to be processed one at a time rather than rejected. It's the most infrastructure of the four to maintain.
The mechanisms aren't exclusive. A common combination is a version number together with an idempotency key: the version number handles late updates, and the key handles repeats a version can't catch, such as creating a record or sending an email.
InAir's guide to running Airtable inside complex system landscapes makes the point that ordering protection doesn't appear because the code is well written or because the integration has run without incident. It exists because someone added it, and each mechanism leaves a visible trace:
If you can't find any of these, assume the integration has no ordering protection until a test shows otherwise. In a sandbox, send a write, then send an older write for the same record, and check that the older one is rejected. Then send the same operation twice with the same key, and check that it's applied only once. Repeat the second test with a create, and run both tests once with the two writes sent at the same moment, checking that the record ends with the newer value and the operation applied only once.
If you want to know which of your integrations would survive a late retry, and add the right protection where they wouldn't, Schedule a Discovery Call with InAir and we'll test them with you.