Customer Data
Part of Marketing technology integration design
Defining a source of truth for customer attributes
Assign authority for each customer attribute and decide how corrections, conflicts and stale copies are handled.
Define a source of truth for each customer attribute rather than naming one system as authority for the whole customer record. Decide which event or person establishes a value, which systems may copy it, and what happens when copies disagree. A CRM may own a sales-stage field while a transaction system owns a purchase event.
Write an authority rule for each value
Start with attributes that affect an action: contact details, sales stage, purchase date, campaign source and marketing opt-out. Record the meaning of each value and the event that makes it current. A blank email address is not an opt-out, and a purchase date is not the date a file arrived.
| Attribute | Authority to name | Conflict or correction question |
|---|---|---|
| Contact detail | Agreed customer update route | How is a correction verified and passed to copies? |
| Sales stage | Sales process owner | Can another system overwrite sales work? |
| Purchase event | Transaction source | How are refunds or reversals represented? |
| Marketing opt-out | Approved preference route | How is an older positive value prevented from restoring eligibility? |
These are example questions, not assignments for any organisation. Add the actual system or role, allowed recipients and rule for each field before configuring a write.
Resolve competing writes
Ask what happens when two systems edit the same field close together. Last-write-wins does not determine which edit is correct. HubSpot's Salesforce mapping documentation says updates can sync between mapped fields, depending on the sync settings. Review the specific sync rule for each proposed mapping before enabling it.
If two teams appear to edit the same concept, check whether they mean different facts. A sales colleague may update a working phone number while a customer submits a new number through an account form.
Agree how the correction is checked and when the working view changes. Hold unresolved write-back instead of letting a convenient timestamp decide.
Keep source and freshness visible
A system may display an attribute without being authorised to correct it. For a value that affects an action, retain enough context to identify its source, effective time and last update to the copy.
Set a maximum acceptable delay for that action. A stale preference before a send carries a different consequence from a delayed management report.
Correcting a downstream display may be temporary if its source resends the old value. Name the team that changes the authoritative record, how recipients get the correction and how a failed update is found.
For entities covered by the Australian Privacy Principles, APP 10 addresses information quality and APP 13 addresses correction. The required steps depend on the entity, information and purpose; an authority register is a working tool, not a legal determination.
Check the rule against contrary cases
Before enabling a write-back, propose safe sample cases: a change in the owning system, a conflicting change in a recipient, and a deletion or correction. Write the expected value in every system first. Include a record that predates the mapping.
Review the rule when a system, business process or permitted use changes.
