Cross-Org Sync for Salesforce: How Delivery Hub Keeps Two Orgs in Lock-Step

You have two Salesforce orgs. A client org and a vendor org. Or a hub org and three satellite orgs. Work items need to exist in both places. Comments need to flow both directions. Files and time entries need to stay in sync. And none of this can create infinite loops. Here is how Delivery Hub solves it.

The Multi-Org Problem

Salesforce is built around a single-org model. When your business spans multiple orgs — because you work with external vendors, manage multiple business units, or operate a client-hub model — you hit friction fast:

• Work items created in the client org need to appear in the vendor org
• Status changes in the vendor org need to reflect back to the client
• Comments posted on either side need to show up on both
• Time entries logged in the vendor org need to flow to the client for invoicing
• Files attached anywhere need to be accessible everywhere

Most teams solve this with CSV exports, email updates, or third-party middleware (MuleSoft, Workato, Informatica). Those approaches are expensive, fragile, and introduce lag. You end up with two systems that are “mostly” in sync, and “mostly” is not good enough for billing.

How the Sync Engine Works

Delivery Hub's sync engine is built into the managed package. When you connect two orgs, each one gets a Network Entity record that points to the other's REST endpoint. From there, sync happens automatically:

Push Flow (Real-Time)

1. A trigger fires when a Work Item, Comment, File, or Work Log changes
2. The Sync Engine evaluates routing — which connected orgs need this change?
3. It creates a SyncItem record (status: Queued) with the change payload
4. A Queueable job processes the SyncItem, makes an HTTP callout to the target org
5. The target org's Ingestor resolves the local record, applies the change, and suppresses the echo
6. SyncItem status updates to Synced (or Failed with retry)

Pull Flow (Backup)

Every 15 minutes, a scheduled job polls each connected org for any staged changes that might have been missed (network blips, callout limits, etc.). This is a safety net — push handles 99% of syncs in real time.

The Echo Suppression Problem

Here is the hard part. When Org A sends a change to Org B, Org B's trigger fires. That trigger tries to sync the change back to Org A. Which fires Org A's trigger. Which syncs back to Org B. Infinite loop.

Delivery Hub solves this with three layers of echo suppression:

1. Gateway-level. Every outbound request includes an X-Global-Source-Id header identifying the originating org. The receiving org checks: “Did this change originate from me?” If yes, skip.
2. In-memory origin blocking. The Sync Engine maintains a blockedOrigins set during the transaction. Any record whose origin matches a blocked ID is excluded from outbound sync.
3. Kill switch. Before creating any outbound SyncItem, the engine compares the target entity against the record's GlobalSourceId. If they match, the sync is suppressed.

Three independent checks. If any one of them fails (bug, race condition, edge case), the other two catch it. In practice, we have never seen an echo slip through all three.

Self-Healing Reconciliation

Even with reliable sync, drift happens. A callout fails and exhausts its retries. A sandbox refresh resets data. Someone imports records directly. Delivery Hub includes a Reconciler that runs daily (or on-demand) and detects drift:

• Compares record counts and checksums between connected orgs
• Identifies missing or stale records
• Creates repair SyncItems to bring orgs back into alignment
• Logs everything to the SyncItem audit ledger for visibility

What Syncs and What Does Not

Setting Up Cross-Org Sync

1. Install Delivery Hub in both orgs
2. In the hub org, create a Network Entity for the vendor/satellite (type: Vendor)
3. In the vendor org, create a Network Entity for the hub (type: Client)
4. Exchange API keys and endpoint URLs between the two entities
5. Toggle “Enable Vendor Push” on the hub's entity to start real-time sync
6. The scheduled poller starts automatically for pull-based backup

The Sync Engine documentation covers advanced topologies: multi-vendor fan-out, hub-and-spoke, and bidirectional peer sync.