Skip to main content

Sync Modes

A sync mode describes how Propexo Connect reads data from your source and writes it to your destination. Connect uses an incremental, windowed model: after the first run establishes a recent baseline, each run reads only what changed and folds those updates into what's already stored.

How Connect reads​

Every recurring sync pulls the records created or updated since the last successful sync. The first run covers an initial window of recent data (typically the last 30 days), and each run after that picks up exactly where the previous one stopped, with no gaps, and no re-pulling data you already have. Historical data older than the first run's window is filled in separately by backsyncs.

The full window and backfill model, including how windows tile, what happens when a run fails, and how backsync chunks work, is covered in How Syncs Work.

How Connect writes​

Incoming records are merged into the destination rather than replacing it wholesale. New records are added, and changed records update the rows already stored, so your destination accumulates a complete, current picture without being rebuilt on every run.

You can tune sync behavior per stream within a connection, so different datasets in the same pipeline can follow different rules when that makes sense for your team.

Why this model​

  • Light on source systems: Each run requests only a bounded window of changes, which respects vendor API rate limits and keeps syncs fast even on large datasets.
  • Friendly to frequent syncs: Because runs are cheap, you can sync as often as your data freshness needs require without re-reading history every time.
  • Complete by construction: Recurring windows tile forward with no gaps while backsyncs fill in history behind them, so the destination converges on the full timeline your source exposes.

Things to keep in mind​

  • Change detection depends on the source: Incremental reads need a reliable signal for what's new or updated (modified-date filtering, timestamps, or similar). Sources with precise filtering support tight windows; sources with weaker filtering need broader windows to guarantee completeness. We configure this per connection during onboarding.
  • Deletes: Records hard-deleted in the source may need a deliberate reconciliation strategy, since a delete doesn't always surface as a "changed record." Your Propexo team can advise on the right approach for your source.

Exact behavior may vary by connector. If you need something specific for a go-live, your Propexo team can walk you through the details for your stack.