Review changes from Airtable
When you edit a record in Airtable, SKU.io does not touch your catalog straight away. Whitelisted edits land in the Inbound review queue so you can see the exact before-and-after and approve them on your terms. This guide walks you through reviewing, approving, and rejecting those changes.
Before you begin
- Connect your Airtable account to SKU.io. See Connect Airtable.
- Set up at least one inbound sync mapping (direction Airtable → SKU.io) for Products, Sales Orders, or Suppliers — the only three datasets that can write back into SKU.io. See Sync your data to Airtable and the Sync-mapping settings reference.
- Understand which fields are ever writable from Airtable. Inbound never touches inventory, costs, pricing, or order/fulfillment status. See Inbound safety and the field whitelist.
Whether a matched change waits for you or is written immediately depends on the mapping's apply mode. Under Review before applying (the default) changes queue as Pending for your per-record approval. Under Apply automatically they are written the moment they are detected and recorded as Applied, so there is nothing to approve. You choose this when you create the mapping — see step 8 of Sync your data to Airtable.
For how a change travels from Airtable into the queue — webhook diffs versus the fallback scan, and when an unmatched row is auto-created — see How Airtable sync works and Inbound safety and the field whitelist.
Steps
- Go to Apps & Integrations → Airtable and open the Inbound tab. The queue lists every detected edit, newest first, with four columns: Record, Change, Status, and Detected.
- Read the Change column to see the proposed edit. Each changed field shows its old value struck through, an arrow, and the new value in green.
- Click the reference in the Record column to open the matched SKU.io record (product, sales order, or supplier) in a new detail page and confirm the edit in context. Hover the link to see a tooltip with the record's type and ID. A row whose Airtable key matched no SKU.io record shows the raw Airtable Record ID as plain text instead, with no link.
- Narrow the queue if it is long. Use Search to find a row by its Airtable Record ID, or use the Status filter to show only Pending, Applied, Rejected, Failed, or Unmatched rows.
- Select the rows you want to act on with the row checkboxes. A bulk action bar appears showing how many rows are selected.
- Choose the scope with the toggle in the bulk bar. Selected acts on only the rows you checked; All (total) acts on every record in the queue, not only the checked ones.
- To accept the changes, click Approve. SKU.io dispatches the Apply Airtable Changes background job — a toast confirms it started and progress appears in the job tray. Each write goes through the entity's normal repository, so it is audited in that record's usual activity log. The queue refreshes automatically when the job finishes, flipping approved rows to Applied.
- To discard the changes, click Reject instead. Rejection runs immediately (no background job), writes nothing to SKU.io, and marks the rows Rejected. A toast confirms the count rejected.
What the statuses mean
Every queued change carries a lifecycle status, shown as a colored chip in the Status column.
| Status | Chip color | Meaning |
|---|---|---|
| Pending | Warning (amber) | Detected and waiting for you to approve or reject. |
| Applied | Success (green) | Written to SKU.io — either you approved it, or the mapping auto-applied it. |
| Rejected | Grey | You discarded it; nothing was written. |
| Failed | Error (red) | Approval was attempted but the write could not complete (for example, the SKU.io record was deleted after the change was queued). The row shows an information icon; hover it to read the error text. |
| Unmatched | Purple | The Airtable key resolved to no SKU.io record and the dataset did not auto-create one, so there is nothing to update yet. Reconcile these by hand, or turn on auto-create for Products. See Inbound safety and the field whitelist. |
Not every Airtable record produces a queued change: a record with a blank key field is skipped entirely, and a record that matches a SKU.io entity but has no whitelisted changes is counted as unchanged and never queued. Inbound safety and the field whitelist covers these skip-and-match rules and the Products-only auto-create behavior in full.
When the queue is empty
If there are no edits to review, the Inbound tab shows a No inbound changes message explaining that edits made in Airtable will show up there for review before they update your SKU.io catalog. Any status filter still applies, so clear it back to All if you expected rows and see none.
Next steps
- Inbound safety and the field whitelist — exactly which fields each dataset can write back, and what is permanently off-limits.
- How Airtable sync works — the full record lifecycle across both sync directions.
- Sync-mapping settings reference — set apply mode, auto-create, and the key field on a mapping.
- Monitor syncs and connection health — track apply jobs and catch sync problems early.
Video transcript
When you edit a whitelisted field in Airtable, the change lands here in the Inbound tab for review before it updates your catalog. Each row shows the record it affects, the proposed change from its old value to the new one, and a status. Pending changes wait for your approval, while Unmatched rows have no SKU.io record yet. Select the changes you want, then choose Approve. SKU.io applies them to your catalog through a tracked job — so only fields you allow, and only edits you approve, ever write back. Rejected changes are dismissed, and approved changes update the linked record in your catalog.