One Register, Field by Field: Deciding Which System Gets the Last Word
When two systems hold the same customer, teams often ask which one is the master. For a business website or app that is usually the wrong question. One tool is better at phone numbers because customers type them in directly. Another is better at language preference because staff maintain it. Choosing one master for the whole record means one of those fields is wrong most of the time.
This article proposes a field-level system-of-record register. It is a design method, and the answers will depend on your own tools and people.
Building the register
List each field that exists in both systems. For every field, answer five questions:
- Who or what enters the value first, and where?
- Which system validates it?
- Which system is changed soonest when the value changes?
- What goes wrong if the value is stale?
- Can the two copies legitimately differ?
Then assign one of three outcomes.
| Outcome | Use when |
|---|---|
| Single owner | One system is entered first, validated, and updated soonest |
| Stage split | Ownership changes at a clear point in the process |
| No owner, keep separate | The copies mean different things and should not be merged |
The register is only useful if each row also names the direction of copying and the action when the non-owner copy differs: overwrite it, flag it, or ignore it.
Worked hypothetical
Two invented systems, a booking tool and a customer list, share five fields.
| Field | Owner | Reasoning |
|---|---|---|
| Display name | Customer list | Staff maintain it and fix spelling there |
| Preferred language | Customer list | Set by staff after conversation |
| Phone number | Booking tool | Typed by the customer at the time of booking |
| Delivery address | Stage split | Booking tool before confirmation, customer list afterwards |
| Notes | No owner | Booking notes and staff notes mean different things |
Totals: 5 fields, 3 single owner, 1 stage split, 1 kept separate. If your own count of rows by outcome does not equal your field count, a row is unclassified.
Now trace a conflict. The booking tool shows a phone number ending in a different digit from the customer list. The register says the booking tool owns the field, so the customer list copy is overwritten with the booking value on the next sync, and the change is logged. For the delivery address, a difference after confirmation is flagged instead, because the stage split says the customer list is now responsible.
Choosing under uncertainty
If you cannot answer question 3, do not guess. Mark the field provisional, flag differences instead of overwriting, and review after a few sync runs. A flag costs a person a minute; a wrong overwrite can destroy the only correct value.
Stop conditions
Do not automate copying for a field when:
- Both systems accept manual edits and nobody can say who has priority.
- A field's format differs enough that conversion could change its meaning.
- The consequence of a wrong value is serious and no review step exists.
In these cases keep the field read only in one system and revisit the register.
Proposed acceptance tests
These are proposals for a test setup, and none has been run.
- Change the phone number in the non-owner system. Expect it to be overwritten from the owner and the overwrite logged.
- Change the delivery address before and after the stage point. Expect overwrite in one case and a flag in the other.
- Edit notes in both systems. Expect no copying either way.
- Remove a value in the owner system. Expect a review flag, not automatic blanking in the other.
- Ask a colleague to read one register row and say, without help, what happens when the copies differ.
Maintaining it
Put a review date on the register. Fields change meaning when a form or a tool changes, and an old register can be more misleading than none. Keep the register in a place where both the people and whoever maintains the sync can see it, and record who agreed each row.