Cleared Field Won't Sync: Why Blank Means Two Things

A cleared field does not sync because a blank value means two different things: "I have no information about this field" and "someone deliberately erased this field." Almost every sync tool treats every blank as the first meaning and skips it, which is the right call for protecting data and the wrong call for propagating a clear. The durable fix is not a setting. It is a comparison: if a field held a value at the last sync and is empty now, it was cleared, and the sync sends the receiving system's explicit clear value. Every other blank gets skipped.

Why the sync ignores the field you just cleared

Picture the ordinary case. A rep removes a wrong mobile number from a contact in HubSpot. The nightly sync runs, the field arrives at the other system empty, and the other system keeps the wrong number. Nobody gets an error. The run is green.

That behavior is deliberate, and it is documented in most of the tools people use. Salesforce's Bulk API 2.0 guide says it in one line: "Empty field values are ignored when you update records." Make's developer documentation says that almost every input parameter of a module is ignored if there is no value. Zapier's help center puts it from the other side: Zapier only transfers data that is entered or mapped, and a mapped field that held no data when the Zap ran transfers nothing.

Each of those rules protects you from the opposite disaster, the one covered in why a two-way sync overwrites your data: an empty value from a half-filled record wiping a populated field somewhere else. Skip-blanks is the correct default. The problem is that a deliberate clear looks exactly like a half-filled record when it arrives, so the same rule that saves your good data also swallows every intentional erase.

This is the field-level version of a problem we wrote about for whole records. A deleted record does not sync because a delete is an absence, and an absence does not show up as a change. A cleared field is the same thing, one level down.

Every system spells "clear this field" differently

Once you decide a clear should propagate, you hit the second problem: there is no shared way to say it. Each receiver has its own clear value, and the value that clears one system is ignored or rejected by the next.

System	What an empty or missing value does on update	How to actually clear the field
HubSpot CRM API	An empty string clears the property	Send "" for the property, per HubSpot's properties guide
Airtable (PATCH)	Fields you leave out stay as they were	Include the field with an empty value; PUT clears everything you omit
Salesforce Bulk API 2.0 (CSV)	Empty cells are ignored on update	Put #N/A in the cell to set the field to null
Notion API	Omitted properties are unchanged	null for number, url, email, phone, select, and date; [] for title, rich text, people, relation, multi-select, and files; false for a checkbox
Make (update modules)	Empty inputs are ignored	Map the erase keyword into the field
Zapier (app actions)	A mapped field with no data transfers nothing	Depends on the app integration; a custom request step to the vendor API always works

Two rows in that table deserve a closer look, because they fail in ways the others do not.

Airtable's read side hides the difference entirely. Its API reference states that returned records do not include any fields with empty values, for example "", [], or false. An unchecked checkbox and a checkbox your integration has never heard of arrive the same way: absent. A sync reading from Airtable cannot tell "the box was unchecked" from "this field is not in the payload" unless it checks the table schema and knows that, for a checkbox, absent means false. Plenty of syncs skip that step, and an unchecked box in Airtable becomes a clear that never arrives anywhere.

Notion's status property does not clear at all. Its page property reference says that sending null for a status resets it to the default option, if one is set. So a sync that correctly propagates a cleared status into Notion writes "Not started," and on a two-way setup the next pass carries "Not started" back into the source system, which now shows a value the user removed.

The opposite failure: a clear that wipes fields nobody touched

Teams that notice clears are not syncing often fix it the fast way. They swap the connector's update action for a raw HTTP request and send every mapped field on every run, empty or not. Now clears propagate. So does everything else that happens to be blank.

The pattern is easy to build by accident. A code or HTTP step builds the request body from the full field map, and any field the source did not return goes out as an empty string. Against HubSpot, that empty string is the documented clear value. A source that omits empty fields, which is exactly what Airtable does, turns into a source that erases the receiver's copy of every field it happened not to return. The same thing happens with Airtable as the receiver if the step uses PUT instead of PATCH: Airtable's update reference says a PUT request will perform a destructive update and clear all unspecified cell values.

So there are two defaults on the market, and both are wrong for a sync that has to carry real edits:

• Skip every blank, and deliberate clears never arrive.
• Send every blank, and missing data erases good data in the receiver.

Neither rule can be right, because neither one knows what the field looked like before.

The fix: compare against what the field held at the last sync

The sync already has the information it needs, or it should. Keep a snapshot of each synced field's value as of the last successful run. A two-way sync needs this anyway for conflict detection, and it is a small table: record key, field, last value, last synced at. With it, every blank sorts into one of three cases.

Source now	Snapshot from last sync	What happened	What to send
Empty or absent	Empty	Nothing happened	Nothing. Skip the field
Empty or absent	Populated	Someone cleared it	The receiver's explicit clear value from the table above
Populated	Anything	A normal edit, or no change	The value, if it differs from the snapshot

That one comparison replaces both broken defaults. A blank that was always blank is skipped, so incomplete source records never wipe the receiver. A blank that used to be a value is a clear, so it is sent, in the dialect the receiver understands. Before comparing, collapse the empty states into one: trim whitespace and treat "", null, an empty array, and an absent key as the same empty value, the same normalization that keeps blank merge fields out of customer emails. For an Airtable checkbox, read absent as false first, because that is what it means.

Then add a policy column to your field map, because not every field should be clearable by a sync:

• Clearable fields follow the rule above. Most contact and deal fields belong here: phone, title, secondary email, next step.
• Fill-only fields accept values but never accept a clear from the sync. Enrichment data and anything another team owns go here, so a source that never had the value cannot erase it.
• Alert-on-clear fields never clear automatically. Consent, billing status, and contract state go here. A clear on one of these usually means a mistake or a process change, and a human should look before it moves.

Log every clear the sync sends, with the field, the old value, and the source record. A clear is the one write where the old value exists nowhere else afterward. We treat it as part of the standard run record described in what to log in every automation, because the first time someone asks where a phone number went, that log line is the whole answer.

How to check your own sync in ten minutes

Pick one test record in the source system and run three edits, one sync apart.

First, populate a text field, a checkbox, and a dropdown, and let the sync run. All three should arrive. Second, clear all three and let the sync run again. Check the receiver: if the old values are still there, your sync is skip-blanks and clears are being lost. Third, on a different record that has a populated field in the receiver and an empty one in the source, change some unrelated field and sync. If the receiver's populated field goes blank, your sync is send-blanks and it is erasing data.

A healthy sync passes all three: values arrive, clears arrive, and untouched blanks stay put. The syncs we review usually fail the second step or the third, and the fix is the same snapshot comparison in both cases. If your stack spans more than two systems and you would rather not hand-build clear values for each one, that field map is the kind of plumbing we build as part of our workflow automation systems, or tell us what you are syncing and we can point at where the blanks are getting lost.