Assign ownership to the information

For every important field, identify its authoritative source. A customer address may belong to one system while a delivery status belongs to another. Avoid assuming that one application must own every part of a shared record.

Decide what happens when both systems allow edits. If the answer is “the newest value wins,” explain how recency is determined and whether that rule is acceptable for the workflow. Some conflicts require a person to review the competing changes.

Define the event that matters

Describe when information should cross the boundary. A draft order being saved is different from an order being approved. Sending changes too early can make the receiving system act on work that is not ready.

Specify identifiers, required fields, and what each status means. Include an example record and an example that should be rejected. Field names alone are not enough to establish that both teams interpret the data the same way.

Plan the disagreement path

Decide who investigates missing or inconsistent records and what evidence they can inspect. Preserve source identifiers and useful processing references so a support person can trace an item across both systems.

Agree how corrections propagate. If an imported record was wrong, is it replaced, amended, or cancelled? Make the recovery procedure part of the integration rather than a future manual task.

Start testing with a small set of representative records, including an update and a withdrawal. A successful first transfer proves connectivity; a successful correction proves that the teams have begun to define an operable relationship between the systems.

Illustrative scenario

A practical example.

Suppose an order system sends approved orders to a warehouse. Decide which system owns the customer address, when an order becomes eligible to send, and whether a later edit is an update or a separate request. Those decisions matter more than the first successful API call.

Write a small contract with example records and expected acknowledgments. Include a warehouse outage, a rejected address, and an order cancelled while delivery is pending. The sending system should expose which state it has actually confirmed. “Sent” may only mean that a message left the application, not that the warehouse accepted the order. Agree who investigates mismatches and how the two teams reconcile them.

Put it into practice.

  • Name the owner of each field and lifecycle decision.
  • Distinguish attempted delivery, accepted delivery, and completed business work.
  • Define recovery and reconciliation before increasing the volume of traffic.

Working through a similar decision?

Tell us about your project