Agree which system owns each field before connecting them.

Start with the information that changes

Before discussing connectors, list the small set of fields the workflow actually needs. A record may contain an account owner, billing address, delivery address and order status. These are different business facts, even when they appear together on one screen.

For each field, identify where an authorised change should begin. Avoid declaring a whole application the source of truth when different teams legitimately own different parts of the record. A delivery address for one order may need to differ from the customer’s usual address.

Write the rules in business language

Create a short agreement that the people running the process can understand and the implementation team can test. Start with the fields where a mistake would affect a customer commitment or cause repeated manual correction.

• Authority: which system holds the approved value for this purpose?
• Editing: who may change it, and through which screen or process?
• Direction: which systems receive the update, and how quickly must they receive it?
• Conflict: what happens if two people make different changes?
• Exception: who sees a rejected update, and what should they do next?

Keep identity separate from a familiar label

Ask how the connection identifies the same customer or order in each system. A trading name or email address can change or be shared, so agree a reliable record identifier and the rule for linking existing records. Include what happens when the match is uncertain.

In the hypothetical address example, agree whether the change affects future orders only or also an open order. That is a business decision for the responsible team. It should not be left to whichever behaviour the connector happens to provide.

Prove the awkward cases

Use synthetic records in an agreed test environment. Change a value in its authorised location, try a conflicting edit elsewhere, and test a missing or ambiguous record match. Ask the supplier or delivery team to demonstrate the expected result and the exception route.

Include an interrupted update and its retry. The team should be able to tell whether the work completed, failed or still needs attention. Define how it avoids applying the same business action twice. An error hidden in a technical log is not a workable support process unless someone is responsible for monitoring it.

Make the agreement part of the handover

Save the field rules alongside the integration specification and give them a business owner. Review them when a process, system or responsibility changes. Use the same rules to investigate recurring support requests instead of repeatedly correcting the visible symptom.

Rethink’s technology second opinion can help expose these unanswered questions in a proposal before you commit to delivery.