Skip to main content
Four ideas explain almost everything Synclify does. Understanding them up front saves you from most of the surprises later.

​
Connections

A connection binds exactly one source resource — an Airtable table — to exactly one Webflow CMS collection. A connection carries:
  • a field mapping (which source column feeds which Webflow field)
  • an identity field (how records are matched)
  • a sync direction (who is allowed to write)
  • a cadence (when syncs run)
  • policies for publishing and deletion
A Webflow collection can back only one live connection at a time. Two connections writing into the same collection would fight each other, so Synclify refuses to create the second one.

​
The identity field

Synclify has to answer one question on every sync: is this Airtable row the same thing as that Webflow item? The identity field — labelled ID field or Use as ID field in the mapping step — is the mapped pair used to answer it. Synclify matches records by comparing the value of the source column against the value of the destination field.
A connection cannot be created without an identity field. If none is set you’ll see: “Identity strategy is required — Map at least one matching field, such as slug or name, before creating the connection.”
Choose a column that is unique and stable: Bad choices are anything duplicated (Category, Author) or anything people rewrite casually. If you change an identity value in the source, Synclify sees a brand-new record — it will not recognize the old Webflow item, and depending on your delete policy it may create a duplicate. Synclify preselects slug, name, or title when it finds one. Identity-mapped fields cannot have their direction changed.

​
Sync direction

Set per connection, in the Settings step.
Source updates Webflow.Airtable is the source of truth. Every sync pushes source values into Webflow. Anything a person types into the Webflow Designer on a mapped field gets overwritten on the next sync.Use this when content is authored outside Webflow and Webflow only renders it.

​
The direction you actually get

Mode is a permission, not a description. A two-way connection where every field is set to Webflow owns is still writing in one direction only — Webflow to the source. So Synclify reports the direction it derives from your field ownership, not the mode you picked. On the connection page you see two provider names and an arrow:
Nothing syncs is the one to act on. The connection looks healthy and runs on schedule, but every mapped field is configured so that nothing can be written. Check field ownership in the mapping — see Field mapping.

​
Per-field ownership

On a two-way connection, each mapped field carries its own direction. Click the direction toggle next to a field to cycle it:
Only the source can change this field. Webflow edits to it are discarded on the next sync. This is one-way behavior, scoped to a single field.
Only Webflow can change this field. The source column is read but never applied. Useful for fields designers own — hero images, layout flags, SEO overrides.
Either side can change it. Simultaneous edits raise a conflict.
Two fields are locked and cannot be changed:
  • The slug field is always Airtable owns. Webflow generates and validates slugs; letting both sides write them produces broken URLs.
  • The identity field cannot have its direction changed, because a record that renames itself on both sides can no longer be matched.
The most common production setup is a two-way connection where most fields are Airtable owns and a handful of visual fields are Webflow owns. You get one-way discipline on copy without locking designers out of the site.

​
Syncs

A sync is one run of a connection. Three things trigger one: Every run moves through the same five phases:
1

Fetch source

Read the current state of the source table.
2

Diff records

Compare against the last known state and against Webflow. Decide what to create, update, delete, or skip.
3

Write to Webflow

Apply the changes to CMS items.
4

Publish

If auto-publish is on, push the items live. Otherwise they stay as staged changes.
5

Done

Record counts and any failures in the run history.

​
Connection states

The ones you will actually see:
Pausing is not how you edit a connection. Paused connections reject edits. To change a live connection, create an editable draft — see Editing a connection.

​
Where health lives

Once connections are live, two pages tell you whether they are working:

Workspace health

Everything needing attention across every connection and connected account, worst first.

Realtime health

Whether webhooks are delivering, and what repairs itself without you.