Sync-mapping settings reference

Every dataset mapping carries its own sync settings, set on the Sync options step of the mapping editor. This reference defines each setting, its accepted values, and the guardrails that block an invalid mapping at save time.

To open the editor, go to Apps & Integrations → Airtable, open the Datasets tab, then add or edit a mapping. For how a saved mapping actually pushes records, see How Airtable sync works.

Sync schedule

The Schedule dropdown controls how often the scheduler auto-sweeps an outbound mapping and dispatches a sync job. A manual mapping is never swept automatically — it syncs only when you press Sync now on the Datasets tab, or when Real-time sync pushes an individual change.

Menu label	Stored value	What it does
Every 15 minutes	fifteen_minutes	Swept on the 15-minute cadence tick.
Hourly	hourly	Swept once an hour. Default for new and provisioned mappings.
Daily	daily	Swept once a day.
Manual only	manual	Never auto-swept — on-demand or real-time push only.

Notes:

• The sweep dispatches a sync job only for mappings that are both Enabled and outbound and whose schedule matches the cadence tick that is running. A disabled mapping is skipped entirely.
• Schedule governs the outbound push cadence. Inbound mappings do not push on this schedule; they pull edits into the review queue through Airtable webhooks plus an every-3-hours fallback scan, regardless of the schedule value. That fallback scan runs on its own fixed every-3-hours cadence — the Schedule setting only controls outbound sweeps and never changes how often inbound edits are pulled. See Inbound safety and the field whitelist.
• Pressing Sync now always runs a sync immediately, whatever the schedule is set to.

Delete mode (On delete in SKU.io)

The On delete in SKU.io dropdown controls how a SKU.io-side archive or delete is reflected on the matching Airtable row.

Menu label	Stored value	What happens on the Airtable row
Flag the Airtable row	flag	Ticks the row's Archived checkbox. Non-destructive. Default.
Delete the Airtable row	delete	Removes the Airtable row.
Ignore (leave it)	ignore	Leaves the row untouched.

Notes:

• Flag relies on the dataset having an Archived checkbox field. Archived entities are picked up inline during a normal sync (the archive flows through as a changed record); hard-deleted entities are caught by a separate daily deletion-reconciliation sweep that applies the mapping's delete mode to the now-orphaned Airtable rows.
• Hard-delete datasets coerce flag to delete. The Inventory Levels, Sales Order Lines, and PO Lines datasets have no Archived field, so flag could never mark a removed row and it would linger active in Airtable forever. When you choose Flag the Airtable row for one of these datasets, SKU.io saves delete instead — on both create and update. The one-click Ops Hub base defaults these three datasets to Delete for the same reason; every other dataset defaults to Flag.

Mapping filters and the rolling date window

A mapping's filters narrow which SKU.io records the outbound delta considers. The order and PO datasets ship with a rolling date window so a first backfill does not dump your entire history into Airtable.

Supported filter keys and the datasets they apply to:

Filter key	Applies to	Effect
date_from	Sales Orders, Purchase Orders, Sales Order Lines, PO Lines	Include only records on or after this date. Order-line datasets window on their parent order's date, since lines carry no date of their own.
date_to	Sales Orders, Purchase Orders, Sales Order Lines, PO Lines	Include only records up to this date (the whole end day is included).
order_status	Sales Orders, Purchase Orders	Include only orders whose status is in the given list.
warehouse_id	Inventory Levels	Include only levels for the given warehouse(s).

The rolling window default:

• When you provision the one-click Ops Hub base, the Order window (days) field seeds date_from on all four order/PO-line datasets as today minus N days (default 90). Only orders from the last N days are backfilled. Products, Inventory Levels, and Suppliers get no default date filter.
• Changing a mapping's filters resets its delta cursor. The cursor is an updated_at watermark that tracks how far the last sync got. Editing the filters — like a changed field map or a changed key field — clears the cursor to null, so the next run re-evaluates every matching record for a full re-pass. A per-record hash guard still limits the actual re-push to rows whose projected output changed, so a widened window does not needlessly rewrite unchanged rows.

Mapping creation guardrails

Before a mapping is saved, SKU.io validates it and blocks the save with a specific message if any rule fails. These guardrails protect the merge key, enforce the published field catalog, and prevent two mappings from fighting over the same Airtable field.

Guardrail	When it triggers	Message
Duplicate dataset → table binding	The same dataset is already mapped to that table in the same direction on this connection.	This dataset is already mapped to that Airtable table.
Non-exportable source field	A mapped source is not an advertised exportable field for the dataset (a crafted field that would read an arbitrary model attribute past the catalog's PII controls).	"<source>" is not an exportable field for this dataset.
Inbound on an unsupported dataset	Direction is inbound for any dataset other than Products, Sales Orders, or Suppliers.	Inbound sync is only supported for the Products, Sales Orders, and Suppliers datasets.
Duplicate Airtable target	Two mapped fields point at the same Airtable field.	Each Airtable field can be mapped only once.
Data field collides with the SKU.io ID key	A data field targets the Airtable field chosen as the key field. The synthetic key entry (sku_io_id) may legitimately target the key field; any other field pointed there would hijack the upsert merge key.	A mapped field collides with the SKU.io ID key field. Choose a different Airtable field.
Opposite-direction field overlap	On a table that has both an outbound and an inbound mapping, the same Airtable field is touched by both. The shared merge key is the one allowed overlap — but only when both mappings key on the same field; differing keys still reject.	A field on this table is already synced in the opposite direction. Remove the overlap first.

Two more save-time checks come from the mapping form itself:

Rule	Message
A key field must be chosen	Choose the Airtable field that stores the SKU.io ID — it is the merge key for syncing.
At least one field must be mapped	Map at least one field before saving.

For the full list of exportable source fields per dataset, and which are inbound-writable, see the Dataset field reference.

Related settings

A few other options sit on the same Sync options step but are not mapping-behavior settings in the sense above:

• Direction — outbound or inbound. Fixed once the mapping is created, and offered as inbound only for datasets that support it.
• Real-time sync — pushes each change to Airtable as it happens, independent of the schedule.
• Create missing products / Apply inbound changes — inbound-only controls you set on the mapping wizard's inbound step; see Sync your data to Airtable. Apply inbound changes accepts two values: Review before applying (the default), which queues each edit for your approval, or Apply automatically, which writes matched edits straight through. For how the review queue and safeguards work, see Review changes from Airtable and Inbound safety and the field whitelist.
• Enabled — turns a mapping on or off without deleting it. A disabled mapping is skipped by every scheduled sweep.