Four settings decide when a connection runs and what it’s allowed to do. They’re set in the wizard’s final step, and changed later through an editable draft.
One-way (source_of_truth) — Airtable updates Webflow. Webflow edits to mapped fields are overwritten on the next sync.Two-way (constrained_two_way) — shared fields can update both sides, and each field gets its own direction.
Two options, shown in the connection settings as Fallback scan: “Keep manual syncs only or add a polling backup for missed webhooks.”
Manual
Polling
Syncs run only when you click Sync now, or when realtime detects a source change.
Adds a scheduled scan every N minutes, hours, or days, on top of realtime.This is a backup, not the primary mechanism. Webhooks already deliver changes within seconds. Polling catches what they miss — a webhook that failed to deliver, a change made while your source account was degraded.
Minimum poll interval: 5 minutes.“Minimum poll interval is 5 minutes to avoid rate-limit issues.”Polling harder does not make syncs faster. It burns Airtable and Webflow API quota, which makes every sync — including the realtime ones — slower and more likely to fail. If you want sub-minute latency, you already have it: realtime is included on every plan.
A sensible polling interval is measured in hours, not minutes. It exists to catch the rare miss, not to carry the load.
publish_on_create. Items written by a sync are published to the live site.Right when the source table is the editorial system of record and content is ready when it lands there.
manual_only. Items are written to Webflow but left as staged changes. Someone publishes the site to make them live.Right when you want a human to review before content goes public, or when publishing is batched with design changes.
Default: off. New connections are delete-safe until you deliberately change that.The setting is Delete counterpart records — “Propagate deletion to the mapped record in the other provider.”
Off
On
A deleted record’s counterpart stays. Synclify stops managing it.Safe. Costs you stale items that need occasional manual cleanup.
Deleting a mapped record in one provider deletes its counterpart in the other.
Switching it on is a two-step action. An amber Destructive delete propagation block appears — “Deleting a mapped record in either provider can delete its mapped counterpart in the other provider.” — with a checkbox you must tick:
I understand that counterpart records can be deleted.
Saving stays disabled until you do. One misplaced click cannot arm this.
Turning this on makes deletions propagate across providers.Two ways it bites people who didn’t expect it:
Someone deletes an Airtable row to “clean up” — the published page disappears.
Someone renames an identity value. Synclify sees the old record as gone and the new one as new. The old Webflow item is deleted; a fresh one is created. Any Webflow-owned fields on the old item are lost, and the URL changes.
Leave it off unless deleting a source row genuinely means unpublish this from the site.
Switching it on adds a Deleted records tab to the connection, where a deleted record stays recoverable for a retention window — see Deleted records.
The stored policy is in a shape this version of Synclify cannot interpret. Rather than guess at something destructive, it fails closed and blocks saving. Contact support.
Delete policy cannot be saved
Something else blocks the change; the blocker’s own reason is shown beneath the heading.
Not a setting — it’s on for every connection on every plan, with nothing to configure.“Realtime sync included — When a change is detected in the source, a sync runs immediately.”Its health shows on the connection detail page as a Realtime stat. Broken webhooks are repaired automatically; the full state table and the repair flow live on Realtime health.
If you see Realtime degraded with no polling fallback, add a polling schedule as a safety net while you investigate. Even a daily scan beats silent staleness.
