Enterprise sync bridge — technical guide

What this demonstrates: how Enterprise Synchronization Fabrix's optional sync bridge propagates a change from one Connected System to every other datasource that shares the same resourceType — without a second integration engine, a target list, or new mapping logic. The business problem it solves: once two or more systems hold the same enterprise record (for example, two CRMs both modeling customer), a write to one no longer waits on a separate point-to-point integration project to reach the others.

Read Enterprise Synchronization Fabrix first for the business case and activation model. Read Configure sync bridge for the manifest keys, prerequisites, and CLI steps to turn it on. This page explains what happens after activation — how the platform resolves participants, coalesces triggers, propagates writes, and prevents loops — useful when you need to reason about why a propagation happened, not just how to enable it.

Purpose

Integrators often ask: “We already have sync, field mappings, and CIP — why isn’t point-to-point sync enough?”

Because Enterprise Synchronization Fabrix does not add a parallel sync engine. It adds a participation flag (syncBridge) on datasources that share a resourceType, then reuses:

• CIP get to read authoritative vendor state
• Normalized storage upsert into Enterprise Knowledge
• CIP update, create, and delete where the manifest and trigger type require them
• Existing authentication, trust gates, audit, and certification

Webhooks (optional) are triggers only — they never replace CIP for business data.

Core rule

Webhook / schedule / manual trigger  →  change signal
CIP get + fieldMappings              →  business data (always)
syncBridge participants              →  propagation by resourceType (never point-to-point lists)

Vendor webhook payloads are not mapped field-by-field. The platform extracts a safe subset (event type, object id, timestamp, delivery id), creates a sync intent, coalesces work, then runs the same CIP get path used for governed capabilities.

Activation is a Track B concern

Sync bridge activation is the syncBridge mode on the datasource root, the optional webhook block, and the syncExecution / webhookInbound authentication slots. Manifest keys, JSON examples, prerequisites, and CLI commands live on Configure sync bridge and Configure webhook change signals — this page does not repeat them.

One rule those pages state per-field rather than per-mode:

Conflict policy: prefer one sync master per resourceType when multiple datasources participate, unless enterprise policy explicitly allows multiple sync masters. Preferred write/list ownership is a separate product concern — Write and list authority across systems (configure: Configure write and list authority).

Inbound sync (bulk/incremental jobs) is separate from sync bridge — you can run sync.enabled without sync bridge, or enable sync bridge with or without webhooks.

Capabilities the platform reuses (not a new API)

Enterprise sync bridge reuses the default Business Entity capability set — standard names list, get, create, update, delete on the manifest and in CIP execution.cip.operations — not a parallel sync API.

Cross-datasource propagation centers on get → normalize → upsert → update. When a participant has no linked vendor row, the coordinator may use create. delete applies to local Enterprise Knowledge state on delete signals — not vendor-side delete fan-out.

CIP owns retries, rate limits, idempotency, loop fingerprints, and execution audit — the same paths as governed capability execution. Integrators do not configure sync-bridge idempotency keys; the platform applies them internally. Do not add parallel httpx or custom sync pipelines in application code.

Detail: CIP execution.

Runtime flow (end to end)

Trigger (webhook | schedule | manual | API)
  → validate webhook auth (if webhook)
  → extract object id (idPath)
  → create SyncIntent (coalesced — do not sync inline in request thread)
  → SyncCoordinator:
       lock (resourceType + enterpriseRecordId)
       → CIP get on source datasource
       → normalize + upsert local Enterprise Knowledge record
       → resolve syncBridge participants by resourceType
       → build canonical enterprise record
       → write changed fields only to each participant (CIP update / create as needed)
       → propagation log + loop suppression
       → release lock; limited dirty retry; finding if still dirty

Platform runtime defaults (not manifest fields — applied inside the dataplane coordinator):

These are platform constants, not integrator JSON and not datasource configuration[]. Operators do not set them in env.template for a Connected System.

Participant resolution (resourceType only)

Sync bridge finds every published Business Entity with the same resourceType and syncBridge != disabled. It does not use point-to-point target lists, subscriptionFilter, or per-record dimension rules to skip participants in the current model.

subscriptionFilter on a datasource scopes Role Assistant / subscription generation, not sync-bridge participant selection. Enterprise MCP composed datasources use an explicit datasource selector at read time when multiple children exist — a different layer from sync-bridge writes.

Loop prevention

1. Origin chain — suppress self-originated webhook echo
2. Change fingerprint — hash of resource type, enterprise record id, target, normalized patch
3. No-op detection — skip write when target already matches
4. Max passes — stop and raise finding when still dirty

Operator and UI surfaces

Configuration is manifest-first — authored with Builder CLI or Builder API, then published to the dataplane.

Bulk job history stays on Sync; per-record CIP work appears on Logs.

Certification and trust gates

Sync bridge propagation runs through the same operational trust stack as Role Assistant capabilities:

• Continuous trust and lifecycle certification evidence
• TRUST_PUBLISH_GATE_ENABLED — blocks publish when metadata trust fails
• TRUST_RUNTIME_GATE_ENABLED — blocks CIP execution and generation inputs when runtime trust fails

Uncertified or draft datasources do not participate in production-like propagation. See Operational trust gates.

Design boundaries

The platform intentionally does not:

• Map webhook payload fields into storage (always use CIP get)
• Accept per-datasource sync target lists (resolution is by resourceType only)
• Run a separate webhook ingestion engine or point-to-point sync engine
• Invoke vendor delete APIs when processing delete webhooks (local inactive/soft-delete only)

Common mistakes

Activation-time mistakes (auth slots, CIP get prerequisites, webhook body mapping) are covered on Configure sync bridge and Configure webhook change signals.

Example (two Connected Systems, one Customer resource)

CRM A webhook fires → platform validates webhookInbound auth → sync intent → CIP get on CRM A → upsert enterprise customer → CIP update on CRM B for changed mapped fields only → audit + propagation log.

Limits

• Sync bridge applies to recordStorage Business Entities. Document storage, vector stores, and static entities use ingestion sync patterns instead.
• Real-time behavior depends on vendor APIs, webhook coverage, and certification scope.
• Writable propagation requires invertible field mappings and certified update (and create when new rows are needed on a participant).
• Propagation does not filter participants by country, dimension, or subscriptionFilter — architect separate resourceType or system scope when regional fan-out must be excluded.

Related reading

• Configure sync bridge — Track B How to set
• Configure webhook change signals
• Enterprise Synchronization Fabrix — architecture and business case
• Enterprise webhooks
• Data sync and freshness
• Configure sync
• Configure data flow (CIP)
• Operational trust gates