Data Sync Bridge
Keep records synchronized between two or more systems. Handles create/update/delete propagation with conflict resolution. Essential for multi-system environments.
On this page
Visual Flow
Rendering diagram…
When to Use This Pattern
Use a data sync bridge when:
- The same data exists in two or more systems (CRM + ERP, HR system + AD, etc.)
- Changes in one system must be reflected in the other(s)
- You can't replace either system with a single source of truth
- Manual data entry across systems causes errors and delays
Bidirectional sync is significantly more complex than one-way sync. Start with one-way unless you truly need changes flowing both directions.
How It Works
One-Way Sync (Simpler)
Source System → Detect Change → Transform → Target System
(Salesforce) (trigger/poll) (map fields) (SharePoint)
Bidirectional Sync (Complex)
System A ←→ Change Detection ←→ Conflict Resolution ←→ System B
(both directions) (who wins?)
Implementation Guide
Step 1: Map the Data Model
| Source Field (Salesforce) | Target Field (SharePoint) | Transform |
|---|---|---|
| Account.Name | Company Title | Direct copy |
| Account.Phone | Phone Number | Format: +1 (xxx) xxx-xxxx |
| Account.Industry | Industry Dropdown | Map picklist values |
| Account.AnnualRevenue | Revenue | Convert USD string to number |
| Account.LastModifiedDate | Last Synced | Store for conflict detection |
Step 2: Choose a Change Detection Strategy
| Strategy | Pros | Cons |
|---|---|---|
| Event-driven (webhooks, triggers) | Real-time, efficient | Requires webhook support |
| Polling (check every N minutes) | Works with any system | Delay, more API calls |
| Change log (query audit logs) | Catches all changes | Not all systems expose logs |
| Timestamp comparison (last modified > last sync) | Simple to implement | Clock skew issues |
Step 3: Handle Create / Update / Delete
For each detected change:
| Change Type | Action in Target |
|---|---|
| New record | Create record with mapped fields |
| Updated record | Find matching record by sync ID, update changed fields only |
| Deleted record | Soft-delete (flag as inactive) or hard-delete based on policy |
| No match found | Log orphan warning, create new if appropriate |
Step 4: Resolve Conflicts (Bidirectional Only)
When both systems change the same record:
| Strategy | Rule | Best For |
|---|---|---|
| Last write wins | Most recent timestamp wins | Non-critical data |
| Source of truth | Designated system always wins | One system is authoritative |
| Field-level merge | Take each field from its most recent update | Complex but accurate |
| Human review | Flag conflict for manual resolution | Critical data |
Step 5: Maintain a Sync Log
Track every sync operation:
| Field | Purpose |
|---|---|
| Sync ID | Unique identifier for the sync pair |
| Source record ID | ID in source system |
| Target record ID | ID in target system |
| Last sync timestamp | When the records were last synced |
| Sync status | Success, failed, conflict |
| Error details | If failed, what went wrong |
Tips & Best Practices
The #1 cause of sync failures is infinite loops: System A changes → syncs to B → B's change triggers sync back to A → repeat. Always mark synced changes so they're ignored on the return trip.
- Use a sync marker field. Add a "SyncedBy" or "LastSyncSource" field to both systems. When your workflow updates a record, set this field to "workflow". When detecting changes, ignore records where SyncedBy = "workflow".
- Start with one-way. Get one-way sync working reliably before attempting bidirectional.
- Batch your syncs. Instead of syncing one record at a time, collect changes and sync in batches every 5-15 minutes. This is more efficient and easier to monitor.
- Plan for backfill. You'll need an initial sync to populate the target system with all existing source records. Build this as a separate, one-time workflow.
Related patterns
API Polling with Change Detection
Periodically check an external system for changes and trigger workflows when new or updated records are detected. The reliable alternative when webhooks aren't available.
Change Data Capture Stream
Stream row-level changes out of a database in near real-time using the transaction log. No polling, no app changes — downstream systems get inserts, updates, and deletes as they happen.
Reverse ETL
Push modelled data from your warehouse back into the SaaS tools that business teams use every day — CRM, marketing, support — so they can act on analytics without a BI detour.