← Back to the field guide
Connect business data and workflows

Connected does not mean synchronized.

APIs exchange information. Integration design defines ownership, updates and recovery.

November 7, 2026 · Source-backed explainer · Synthetic example

Dash-Squared editorial · Last reviewed November 7, 2026

Look inside the idea

Connected does not mean synchronized.

Business integration / decide who owns the record and how failures recover.

Connected does not mean synchronized.Business integration / decide who owns the record and how failures recover. Name the source of truth, the record ID and the exception owner.DASH-SQUARED / THE VISUAL FIELD GUIDEConnected does not mean synchronized.Business integration / decide who owns the record and how failures recover.Source recordStable source IDIntegrationValidate + map fieldsCheck repeated eventsTarget recordAPI / eventException ownerReview + reconcileA retry is not automatically safe.Repeated events should not create duplicate actions.Use stable IDs, suitable retries and reconciliation.Name the source of truth, the record ID and the exception owner.Illustrative model · Read the explanation, limits and sources alongside it.
A source record identified by a stable ID feeds an integration that validates fields, maps data and handles repeated events before updating a target record. Failed work goes to an exception owner for reconciliation. Open full graphic ↗

Follow the idea

  1. Identify the source record and the fields it owns.
  2. Validate, map and handle repeats before changing the target.
  3. Send failed or conflicting work to an owner for reconciliation.

Keep the limit visible

Conceptual design, not a universal exactly-once guarantee. Interfaces, transaction semantics, ordering and retry behavior differ. Each target operation needs an explicit recovery design.

What if the same event arrives twice?

Use stable event/record identity and an operation-specific strategy so a repeat does not create an unintended duplicate. Some interfaces require reconciliation rather than a blind retry.

A common assumption

“Connecting two systems means their records will stay consistent.”

Ownership, mappings, duplicate handling and recovery need a deliberate design.

Source for this graphic: learn.microsoft.com ↗ www.twilio.com ↗ · Checked November 7, 2026 · Illustrative example.

In this explanation01Separate the interface from the event02A concrete example03Design the awkward path

Separate the interface from the event

An API defines how software can request or change information. A webhook notifies another system about an event. A connector or integration platform can implement part of the exchange; it does not decide who owns the underlying record.

A concrete example

Synthetic example: a customer update triggers a notification to an integration. The integration validates the record, maps fields and updates a target system. If a notification is repeated, the design must avoid applying an unintended duplicate action.

Design the awkward path

Choose an authoritative source for each field, stable record identifiers and a reconciliation process. Account for missing fields, interruptions, conflicts and failed updates. Retry behavior must suit the interface and operation; blindly repeating a write can make matters worse.

The next useful question

If two systems disagree—or an event arrives twice—what restores the intended state?

Primary sources · checked November 7, 2026learn.microsoft.com · source ↗www.twilio.com · source ↗

Independent, unsponsored education. This is an explanation of a tool and a possible approach, not a claim of delivery experience, certification, endorsement or partnership. Verify the actual product, plan and configuration.

Published .