Practical working guide
Map the source of truth for CRM data across your apps
Choose an authoritative source for each shared data field, not one application for every kind of truth. Record ownership, stable identifiers, permitted edits and conflict handling. Two systems showing the same customer name does not prove they refer to the same organisation or agree on commercial status.
Use a field-level authority map
| Data | Details |
|---|---|
| Relationship owner | Authority example: CRM record Other app handling: Display the CRM owner; do not overwrite from email |
| Payment outcome | Authority example: Confirmed payment system record Other app handling: Use verified reference, not a manually ticked box |
| Project delivery status | Authority example: Project record Other app handling: Show linked status and observation time |
Work a conflict without losing evidence
Fictional example: the CRM lists “North Workshop”, while an invoice uses a longer legal name. Keep the relevant stable identifiers and map the display-name field separately from billing details. Do not merge accounts just because a name looks similar. If both systems can edit a field, decide whether one wins, changes require review or values are deliberately different. “Latest update wins” can overwrite a correct value with a stale synchronisation.
Document failures as well as normal flow
For each mapping, add direction, update trigger, expected delay, failure owner and reconciliation check. Mark unavailable or stale values instead of quietly treating them as current. Keep a manual correction record when automation is absent. This map defines an integration requirement; it does not claim that any listed connector already exists in Client Craft.