Integration and Data Movement
Dette innholdet er ikke tilgjengelig på ditt språk.
Also in 19 languages
Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · 简体中文 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Українська · Español (México) · Français (Canada) · Deutsch (Schweiz)
Chapter 9 of Data Architect, Part 2: Architecting at Scale. Previous: Query and Retrieval Architecture.
Most data quality problems in a connected org arrive through an integration. Duplicates from a missing key. Stale values from a batch that quietly stopped running. Fields overwritten by a system that was never supposed to write them. The data architect doesn’t have to build the integration. But the data architect decides what it’s allowed to do to the data.
Image generated with AI.
So this chapter is a sampler plate: a taste of integration for the data architect, with the full meal in the Integration Architect course. It starts where chapter 4 left off: every arrow on the landscape needs a mechanism. Now every arrow needs meaning.
The ideas in this chapter
Section titled “The ideas in this chapter”- Zoom out, then zoom in. Start with the whole landscape, then take one arrow at a time and ask what it means to the data.
- Know what the integration architect is planning, even when someone else builds it. The shape of the traffic changes the data design.
- Who starts the conversation isn’t which way the data flows, and only the client sees the whole round trip.
- Freshness is a requirement, not a default. And a database stores; a process calls: polling needs a process, and polling for nothing is waste.
- Singles, sets or bulk: respect the zeros. Integration volume becomes data volume.
- One key per record, one-to-one, in an External ID field marked unique. When one customer has several external records, add records, not fields: a hierarchy, peers or a child object (chapter 6), never a key field per system.
- A key isn’t authority. Integrations write the fields their system owns, not “the Account.” Two-way movement still has one owner per field.
- Proof of delivery: the client owns the conversation; whoever knows what should arrive proves that it did. Log every call, restart gracefully, retry safely, and send increments, not the universe.
- Platform events are the backbone; outbound messaging is legacy, supported but not where new designs start.
- Every important arrow gets a contract, written before the mechanism is chosen, and it outlives the technology.
The integration data contract
Section titled “The integration data contract”Every important arrow gets one, eleven lines:
| Line | The decision |
|---|---|
| Initiator | Who starts the conversation? |
| Data direction | Which way does the business data move? |
| Freshness | How current must the data be, in a number? |
| Volume and shape | How much, and as singles, sets or bulk? |
| Key | How do we identify the same record across systems? |
| Write authority | Which system owns, and may write, which fields? |
| Pattern | Request and reply, fire and forget, batch, or events? |
| Mechanism | What implements it? |
| Proof of delivery | Who proves it arrived, and owns recovery? |
| Sensitivity and travel | How sensitive is the data, and where does it pass through? |
| Change | How does the contract change without breaking the other side? |
The path through this chapter
Section titled “The path through this chapter”Four modules, each standing on its own.
- Before the Arrow. Steve Trucking’s landscape, then one arrow: who starts it and which way the data moves, how current, polling or listening, singles, sets and bulk, and what happens when it fails.
- Keys and Write Ownership. One key per record, upsert and safe retries, add records not fields, field-level authority, and loops.
- Proof of Delivery. Who proves it arrived, the integration log, restarts and retries, the return receipt, the four shapes and monitoring.
- The Integration Data Contract. Nine contracts on the landscape, one line by line; requirement, then pattern, then mechanism; the standard API or your own; where the data travels; and when the contract says don’t move it.
Not moving data at all (Salesforce Connect, mashups, zero copy) is chapter 14, Virtualization, Federation, and Zero-Copy (coming soon).
What an architect decides here
Section titled “What an architect decides here”- What each arrow means: initiator, direction, freshness, volume.
- How records stay matched across systems, and who may change which fields.
- Who proves completeness and owns recovery for each movement.
- Whether the data should move at all.
Beyond the exam: every agent read and write path is an integration arrow. An agent that “updates the customer” needs a key, a narrow write contract, safe retries and observability, because a probabilistic caller is invoking deterministic enterprise operations. Each module ends with what AI changes.
Explore
Section titled “Explore”- Salesforce Architects, Data Integration with Salesforce (opens in a new tab) (decision guide), checked 2026-11-01.
- Salesforce Architects, Integration Patterns (opens in a new tab), checked 2026-11-01.
- Salesforce, Best Practices for Deployments with Large Data Volumes (opens in a new tab), Winter ‘27, checked 2026-11-01.