Choose a source of truth before connecting two business apps

Give each field an owner

PostgreSQL's transaction documentation explains how related database changes can be grouped into one all-or-nothing operation. That guarantee does not automatically extend across two separate business services. When connecting a new service app to an existing customer system, start by deciding which system owns contact details, job status and payment status. Ownership may differ by field.

Imagine a customer changes their address in the new app while a staff member edits it in the older system. Decide which change should win, or whether a person must review the conflict. A connection that simply overwrites the latest value can conceal a meaningful business disagreement.

• PostgreSQL: transactions ↗

Map the direction of each update

Draw a short mapping in plain language. The customer system supplies the customer identifier and contact details. The service app supplies the repair request and its progress. The payment service supplies the confirmed payment result. Avoid copying ownership merely because a field exists in both places.

Define whether each exchange is immediate, scheduled or manually initiated. Explain how the receiving system shows that information may be delayed. A customer-facing promise should reflect the actual update process, especially when staff rely on one system to decide what to do next.

Plan for duplicates and conflicts

Choose a stable identifier for matching records. Names alone are a weak operating convention because different people can share them and one person can change theirs. Decide what staff should do when a match is uncertain, and preserve the information needed to resolve it.

Test the difficult sequence: a record is created, the connection fails, someone edits the record and the transfer is retried. The correct result depends on your ownership rules. Record which values should arrive and which older values must not overwrite newer work.

Give staff a reconciliation view

Create a way to see records awaiting transfer or review. Include enough context to identify the business item and the last attempted action without exposing unnecessary private data. Assign a person to resolve conflicts, because a queue that no one owns becomes another disconnected system.

Before releasing the connection, reconcile a small sample and the relevant totals in both apps. Keep the field-ownership map with the operating instructions. Clear ownership makes later changes easier to assess and gives the business an answer when two screens show different versions of the same fact.