System of Record Map Template
Every field's owner checked against who really last wrote the record, with the sync rules read as set and the cycle drawn.
Free download · No account needed
One rep edit on a field the policy assigns to the CRM. Eight syncs, three of them a loop.
Nine hours and fifty-one minutes. Every hop was approved separately and every one is defensible. Sixty edits a week take this route, which is 780 a quarter, and the two events never share a working hour.
Every system of record template is the same table: field, system, owner. Fill it in, circulate it, done. That table is a statement of intent, and intent does not decide the value in the field. A sync rule does, and the rules were set during an implementation years ago by somebody who has left. Of fourteen fields audited at Meridian Freight, seven had a declared owner the modification history contradicts. Four were already correct.
Six of the fourteen sit on a two-way rule, which is not a system of record but the absence of one. The documented behaviour is that the most recent value overwrites whatever is there, so the authoritative system is whichever job ran last. That makes the answer a cadence, and a cadence is invisible in the settings screen. A near-real-time sync loses to a nightly batch every night, so the slowest hop in a loop is usually the one deciding the value.
On Industry, an integration user is the last writer on 2,732 of 3,140 accounts, 87.0%, against a policy assigning the field to sales. The cause is a loop: a six-hourly extract into the warehouse, a nightly enrichment reverse ETL into the marketing platform, and a two-way mapping back. A rep's edit at 16:12 is reversed by 02:03. Sixty edits a week, 780 a quarter, and it pairs with a two-system reconciliation and a field dictionary. A blank propagates too, which emptied one field on 337 contacts in both systems.
What the pack does that a field-owner table does not
Counts the write paths before naming an owner
A person typing, an internal automation, an inbound integration, a form, a scheduled import, a reverse ETL, an enrichment provider, and the API key somebody issued three years ago. Six of the fourteen fields here turned out to have three or more.
Checks the declaration against who really wrote the record
Last-modified-by aggregated across the whole object rather than sampled on three records. An integration user winning 87% of a field the policy assigns to a person is a different problem from one winning 4%, and only the count tells them apart.
Treats two-way as the absence of an owner
The most recent value wins, so the authoritative system is whichever job ran last. That is a cadence rather than a policy, and it is why a near-real-time sync loses to a nightly batch every night without anybody noticing.
Records what a blank does, per mechanism
On a per-field CRM mapping, clearing a value in the owning system clears it in the other. On the generic sync path, a blank in the winning app changes nothing. Same vendor, opposite behaviour, and neither screen mentions the other.
Draws the cycle three defensible syncs compose into
A read-only extract, a nightly reverse ETL, and a two-way mapping. Each was approved on its own merits. Together they route a field back into the system that owns it, and the diagram is what ends the argument in the meeting.
Sequences the fix so it does not lose data
Snapshot, then rule change, then a deliberate one-way backfill. A new mapping does not repair existing records, and the first sync on a record with no history for that field can overwrite the newer value with the older one.
How the pack runs
- 1
Send the configuration
Field exports from each system, the integration and field-mapping settings including the per-field rules, and anything showing who last modified a record.
- 2
Count and read
Every write path into every field, then every sync rule as it is actually set today, with its cadence and its blank behaviour recorded alongside.
- 3
Test against the data
Last-writer shares aggregated across each object, plus a direct divergence count per field, so the declared owner either holds up or does not.
- 4
Draw it and sequence it
The flow diagram with the cycles marked and timed, the policy field by field, and a change plan ordered by blast radius rather than by annoyance.
Frequently asked questions
Is this not just a table of fields and owners?
That table is where it starts and it is the part everybody already has. The difference is the last two columns: who actually last wrote each record across the whole object, and whether that agrees. Seven of fourteen fields here did not, and the counts are what settle it.
What is actually wrong with a two-way sync?
It has no concept of authority in it. The documented behaviour is that the most recent value overwrites whatever is there, so the winner is whichever integration ran last. That turns your system of record into a schedule, and a nightly batch beats a real-time sync every night.
We set a field to don't sync to stop a loop. Is that safe?
It stops the loop and gives you two systems of record instead of none. Nothing errors and nothing surfaces, so the two values simply drift. On the worked example 1,148 contacts ended up at different funnel positions, and the fix was deleting the concept from one side, once the stages themselves were defined.
Will fixing the mapping fix the records already there?
No, and this is where a cleanup becomes an incident. Existing values in a new mapping do not retroactively sync, and the first sync on a record with no prior history for that field baselines on the target's current value. That can overwrite newer data with older.
Can we set a per-field owner on every integration?
No, and the map records which mechanism carries each field for that reason. A generic data sync resolves conflicts with one default app for the whole integration, and leaves the other side alone where that app has no value. A per-field policy cannot be expressed there.
What if we cannot get last-modified data out?
The map still gets built from the configuration and still finds the cycles, which is genuinely useful. It just cannot prove the declared owner is the real one. Worth saying plainly rather than shipping a configuration diagram and calling it evidence.
How often does the map need redoing?
It is invalidated by events rather than by a calendar: any mapping change, any integration upgrade, any new tool granted write access. Upgrades that silently reset field mappings are real, so the trigger is named in the policy. It pairs with merge survivorship rules, a naming standard the classification rules read, and a change request and impact assessment for whatever field the redo touches.
Find out which system actually wins each field
Send your field exports, the integration and mapping settings, and anything showing who last modified a record, and get the map back with the counts.
Get the template