Polling is not real-time, and here is what that costs

SchemaStack updates the grid the moment a row changes. Someone edits a cell in another browser and you watch it happen, because there is an open connection pushing events.

The Zapier integration does not work that way. It polls. Nobody advertises that, so here is what it means.

Two clocks

The grid holds a server-sent events stream. A change is pushed the instant it lands, which is why collaborative editing works at all.

A Zapier trigger is a poll. Zapier calls the integration on a schedule it owns — the interval depends on your Zapier plan, not on anything we control — asks "anything new?", and acts on what comes back. The same change therefore reaches your screen immediately and your Zap some minutes later.

Neither is broken. They are different mechanisms with different guarantees, and the mistake is assuming the second behaves like the first.

What a poll actually reads

Each poll asks for the 25 newest rows. That number is a real limit, not a formality: change more than 25 rows between two polls and the oldest of them are never seen. They aren't queued and they aren't retried — the poll window simply moved past them.

Which makes a bulk edit exactly the wrong thing to hang a Zap on. Fill a column for 500 rows and a New Row trigger sees the last 25. If you need every row of a batch to reach somewhere, use an outbound webhook and push, rather than asking a poller to keep up.

"Newest" is not obvious

To return the newest rows you have to know what newest means, and that depends on the key.

An auto-increment integer key sorts descending — the highest number is the most recent. A UUID key tells you nothing about order, so the integration sorts by a timestamp column instead. Pick wrong and there is no error, just a trigger returning rows in a plausible order that isn't chronological.

An honest correction: when this post was written, that sort strategy existed in the integration's source and not in reality. The triggers spelled the sort in a syntax the API didn't recognise and silently dropped, so the polls actually returned rows in primary-key ascending order — the exact plausible-but-wrong ordering the previous paragraph warns about, published here as if it worked. It was caught on 2026-08-27, the day the API started refusing unknown sort fields instead of ignoring them, and fixed in integration version 1.5.2 the same evening. The lesson stands with sharper teeth: this failure mode produces no error anywhere, including in the verification pass of the person writing about it.

Updated Row is harder still. It needs an updated_at column configured to change on update — without one there is nothing to sort by and nothing to compare. And because Zapier de-duplicates on a field called id, an updated row would be seen once and never again; so the trigger hands Zapier a composite identity built from the row and its update timestamp, making each change look like a new thing. That is a deliberate lie to a de-duplicator, and it's the only way the trigger can fire twice for one row.

There's a related edge worth knowing: a freshly inserted row has updated_at equal to created_at, so it would fire Updated Row as well as New Row. Those rows are filtered out — which means a genuine update within the same second as the insert is indistinguishable from the insert, and is dropped.

So what should you use

What it doesn't do (yet)

• We don't control the poll interval. It is a property of your Zapier plan. If it needs to be faster, that is a Zapier subscription question, not a SchemaStack setting.
• The 25-row page size isn't configurable. Raising it would reduce the bulk-edit problem without solving it; the real answer for volume is push.
• No delete trigger, so a removed row starts nothing.
• No replay. Rows missed because they fell outside a poll window are not recoverable through the trigger — you'd find them with a Find Row search or the API.
• The composite update id is opaque. It reads as <row id>__<timestamp> in Zapier, which is correct but not pretty, and any Zap step referencing it should use the underlying field instead.
• Nothing measures this for you. There is no dashboard showing how far behind your triggers are.

None of the above is unusual for a polled integration. It is unusual to write it down, and the reason to is that "real-time" appears in enough marketing copy that assuming it is reasonable — right up to the moment a workflow depends on it.