Start here.
Choose one complete handoff, identify the source and destination records, and define which system owns each field. Then design the normal path and its failure cases together: missing input, repeated requests, stale updates, and an uncertain delivery result. A connection is useful when the next person can complete their job from the resulting record.
- A successful request does not prove that the destination record is usable.
- A retry needs the identity of the original job, not a new job every time.
- Keep source evidence and delivery state separate from the work’s business status.
Start with the next person’s job.
Consider an illustrative inquiry form that feeds a customer relationship tool. The form collects a contact address, project question, and source link. The destination needs a record assigned to a person who can decide the next step. Copying the message alone may leave that job unfinished.
Write down the acceptance condition before choosing the connection: one inquiry produces one usable record, with its original message, a responsible owner, and an explicit state for missing information. If assignment cannot be determined, route it to a visible review queue rather than silently choosing someone.
This is a planning example, not a CRM implementation we have delivered for a client. Actual feasibility depends on the tools, available interfaces, permissions, and the records they expose.
Decide which system owns each field.
Two-way syncing sounds convenient until both sides change the same value. Prefer an explicit rule for each field. A form can supply the original message while the customer tool owns assignment and follow-up status. A correction in the customer tool should not disappear when the old form payload is delivered again.
The following mapping describes the illustrative inquiry handoff. It separates business information from the integration’s own delivery record.
| Field | Owner | Check before delivery |
|---|---|---|
| Inquiry ID | Source form | Stable across retries; retained at the destination |
| Original message | Source form | Preserved with a link to its origin |
| Contact address | Source input, with reviewed corrections | Missing or invalid values enter review |
| Assigned person | Customer tool or agreed routing rule | A valid owner, or an explicit unassigned queue |
| Follow-up status | Customer tool | A source replay cannot overwrite later work |
| Delivery state | Integration | Pending, confirmed, or uncertain; separate from follow-up status |
Check meaning as well as format.
An integration can accept a valid date and still misunderstand it. Is that the inquiry date, a promised deadline, or the time a record was edited? Is an amount expressed in cents or dollars, and in which currency? Does an empty field mean unknown, deliberately cleared, or unchanged?
Map those meanings explicitly. Preserve the original value when a conversion matters. Define what happens to incomplete records, including whether a usable partial record is allowed. A held item should have a reason and a person who can resolve it.
Our Clef story shows a related boundary in our own product: a parser can read a statement while rejecting individual rows. The preview response retains those reasons. That is useful evidence for review; it is not a substitute for checking whether the resulting workflow exposes them clearly.
Design for a request whose result is uncertain.
Suppose the destination creates the inquiry record, but the connection times out before receiving confirmation. A retry that creates a fresh inquiry ID can produce a duplicate. Reusing the original ID gives the system a way to check whether that job already exists.
The exact recovery mechanism depends on the destination. It may support a repeat-safe request key, or a lookup by your source ID. If neither is available, automatic retries may need to pause for a person to inspect the result. A promise that every write happens exactly once would need stronger evidence than a successful demo.
In Clef’s committed web-import source, retrying an already committed preview returns the existing transaction. That is one concrete implementation of recognising completed work. The same outcome has to be designed and verified for the actual systems in your project.
Keep freshness and recovery visible.
A record can be delivered correctly and become stale later. Decide whether updates are event-driven, scheduled, or manually refreshed, and what users can see when the last update fails. Track the last successful delivery separately from the last attempted refresh.
Also decide how missed updates are discovered. For example, a periodic comparison might find source inquiries that lack a confirmed destination record. It should report gaps and uncertain results before creating more records. Logs help investigation; someone still needs responsibility for the recovery queue.
Our MusicList story explores a related issue: sourced information, publication state, and owner verification carry different meanings. Carrying a source link and freshness information across a handoff helps the next person judge the record.
Verify the handoff, then choose the next connection.
Test normal input, missing fields, a repeated event, a timeout after a write, a later destination edit, and a stale source update. Check the destination record and the next person’s task, not only the request response. Use disposable examples while proving the write and recovery paths.
Before expanding, look at completed handoffs, unresolved items, duplicate records, and the time people spend correcting them. The measurement guide shows how to include that effort. If the connection needs constant repair, another integration may increase the burden before this one is useful.
Bring one handoff to the discussion.
Real examples expose the rules that an integration diagram tends to hide.
- An ordinary example
- The original input, its destination record, and the next action someone takes.
- A failed example
- A duplicate, missing detail, stale update, or handoff someone had to repair.
- Field ownership
- The person or system allowed to change each important value.
- A recovery decision
- Who checks an uncertain result, and what evidence tells them it is safe to retry?
A couple of common questions.
Do we need to replace our existing tools?
That depends on the job and what the tools allow. First check whether the required records, permissions, and update paths are available. A small connection may be enough; a blocked interface or unclear ownership may call for a different approach.
Does the connection need AI?
Field mapping, identifiers, retries, and delivery checks usually need explicit rules. AI may help interpret unstructured input, but any proposed interpretation still needs a checkable result and a path for uncertainty.