Data sync that catches what gets deleted, too

Systems drift out of sync quietly. A record updates in one place and never makes it to the other. A row gets deleted and, because there is nothing left to poll, no downstream system ever finds out. This happens continuously, not once, so a sync has to run on a short interval and know what changed since last time.

Most sync tooling handles inserts and updates well and treats deletes as an afterthought, exactly the class of bug that shows up as a customer complaint three weeks later, not a failed test.

Data sync in Neblex Integration Fabric is change data capture (CDC) for operational systems. A Poll for changes trigger checks the source on the interval you set, from every minute upward, and passes on only what changed. You choose how it recognizes a change:

• Cursor field. The trigger remembers the highest value of a field such as updated_at and passes on records newer than last time. It reads only new and changed rows, so it is the lightest option, but a deleted row leaves nothing for it to see.
• Change detection key. The trigger reads the watched set on each poll and keeps a fingerprint per key. Each record arrives marked as an insert, an update, or a delete, so deletes are caught even in SaaS APIs that have no change log. Only the fingerprints are stored, not your data.
• Native log capture. For databases, the trigger reads the change log directly: PostgreSQL logical replication is generally available, and SQL Server Change Data Capture, MySQL and MariaDB binlog, and other sources are available as Experimental. Each emits inserts, updates, and true deletes in commit order.

Schema-drift detection watches the shape of your data: when columns appear or disappear at the source, the flow shows a banner and a Health entry, so you can adjust the mapping before it silently misses data. A renamed column shows up as one removed and one added column.

Data assertions watch the values. An Assert Data Quality step checks each batch before it is written: row-count bounds, required fields, numeric ranges, and conditions you write. If the batch fails a check, the step stops the run and names the first violations, or, with On error set to Route, hands one error record to a branch that alerts or opens a review task. Either way, a sync that would blank out or remove an unexpected share of the target does not go through unnoticed.

For a one-time migration or the first full load, that is bulk data processing. Data sync is the version that keeps running afterward to keep the two systems in agreement.

When a flow runs in each direction, the question is what happens when a record changed on both sides between runs. You resolve it in the sync flow, not with one global switch. Sort the two versions by their modified time and a Merge by key step combines them field by field, with the later version winning; a branch can hand the conflict to a person through a Wait for form task; or you map a given field in one direction only so one system is its source of truth. The choice is made per field, because a mapping only ever writes the destination fields you choose.

The same data quality steps that a batch load uses work on changes too. A Remove duplicates step on the destination key removes duplicates within a batch, and writing with an upsert on the destination key keeps a repeated change from creating a second record across runs. See bulk data processing for the full data-quality toolset.

Flows are built three ways, and you can move between them on the same flow:

• Natural language. Describe the flow to Matt, the Neblex AI Assistant built into the builder. Matt drafts the canvas, maps fields, and explains steps. It runs on the platform's builder model by default, or on a model you connect for the building experience only. That setting never supplies a model or credential to deployed agents, their tools, knowledge search, apps, or flows.
• Native builder. Assemble steps, branches, and connectors on the visual canvas.
• MCP. Create, change, publish, and run flows programmatically, so an external client or agent can build on Neblex directly, with consent scopes for operating, authoring, and publishing.

Agents, forms, apps, data tables, and connections have their own builders and the same MCP surface.

• Change data capture with cursor checkpoints: only new and changed rows, no full table re-scan
• Delete detection with a change detection key, for the deletes most polling-based sync misses
• Native log capture: PostgreSQL generally available, SQL Server, MySQL, MariaDB, and more as Experimental
• Schema-drift detection that flags added and removed columns before they break a downstream mapping
• Data assertions on each batch: row-count bounds, required fields, numeric ranges, and conditions that stop the run or route an error record before a bad or destructive change is written
• Runs on the schedule you set, from every minute upward
• Two-way alignment by running a flow in each direction, not just one-way replication into a warehouse
• Conflict handling for two-way alignment: newest version wins, route to a person, or a per-field source of truth
• Every sync run recorded step by step; a failed run can be replayed from the step that broke
• Runs on On-Prem Workers when the source database cannot leave your network

A real sync teams run every few minutes, with the actual step-level detail.

Salesforce and NetSuite customers kept aligned, deletes included

Account changes in Salesforce flow to NetSuite every 5 minutes. A deleted or merged account in Salesforce is detected and deactivated in NetSuite, instead of lingering as a stale record.

1. 1
   Trigger: every 5 minutes a Poll for changes trigger reads the watched Salesforce Accounts, with a change detection key on Id.
2. 2
   Classify: each account arrives marked as an insert, an update, or a delete, compared with the fingerprints from the last poll.
3. 3
   Upsert: inserted and updated accounts are upserted into NetSuite, keyed on the Salesforce ID stored as an external ID.
4. 4
   Deactivate: for deleted or merged accounts, the matching customers are set to inactive in NetSuite, never hard-deleted, with a note linking the Salesforce record.
5. 5
   Check: an Assert Data Quality step stops the run if more than a set share of customers would be deactivated at once, so a filter change cannot wipe the target.
6. 6
   Flag drift: if the Salesforce fields change shape, the flow shows the added and removed fields so you can adjust the mapping.