Two-way sync is a connection between two systems in which changes made in either one are copied to the other, so both hold the same, current information. A one-way sync only pushes data in one direction; a two-way sync lets both sides edit and keeps them in agreement.
How two-way sync works
Take a common pairing: a CRM used by sales and an email platform used by marketing. With two-way sync, a salesperson updating a contact’s job title in the CRM changes it in the email platform too, and a customer unsubscribing in the email platform has that status written back to the CRM.
To do this, the sync needs four things:
- A matching key. Each record must be linked to its partner in the other system, usually by email address or a unique ID stored in both. Without it, the sync creates duplicates.
- Field mapping. “Company” in one system must be paired with “Organisation” in the other, with compatible formats. This is field mapping, and mismatched drop-down values are a classic source of errors.
- Change detection. The sync notices edits either instantly, often through a webhook, or by checking on a schedule, every few minutes or every hour.
- Conflict rules. If the same field changed in both places before a sync ran, something has to decide which value wins. Common rules are “most recent edit wins” or “this system always wins for this field”.
Many platforms offer native two-way integrations, such as HubSpot with various email and ecommerce tools, or Shopify with stock and accounting systems. Where none exists, middleware tools can build one, though a properly two-way setup in those tools needs more care than a simple one-way automation.
Why it matters
When two systems hold different versions of the truth, people stop trusting both. Sales chase leads marketing already knows are customers; marketing emails people sales have marked as “do not contact”; reports disagree because each tool counts differently.
The highest-stakes field in the UK is marketing permission. If someone unsubscribes in your email platform but the CRM still marks them as subscribed, and a colleague later adds them to a campaign from the CRM, you have sent marketing to someone who objected. Under PECR and UK GDPR that is a complaint waiting to happen, and the ICO regularly takes action over unwanted marketing. Opt-outs and suppression lists must travel both ways, every time.
Two-way sync also saves real time: no more exporting, cleaning and importing spreadsheets each week, and no more manual re-keying with its typos.
Common mistakes
- Syncing everything. Only fields both teams actually use should sync; the rest just multiply conflicts.
- No field ownership. When both systems can edit a field and no rule decides the winner, values flip back and forth.
- Starting with dirty data. Syncing two lists full of duplicates spreads the mess to both. Run deduplication first.
- Sync loops. A change in A updates B, which registers as a change and updates A, and so on, burning through task limits and sometimes overwriting good data.
- Forgetting deletions. Decide whether deleting a record in one system deletes it in the other, archives it, or does nothing. Erasure requests under UK GDPR need to reach both.
How to act on it
Before connecting anything, write a short table: each field you want to sync, which system owns it (or which wins in a conflict), and its format in each tool. Mark consent and unsubscribe status as fields that must always sync towards suppression, never towards re-subscribing someone.
Clean and deduplicate both databases, test the sync on a small segment, and deliberately create a conflict to see what happens. After launch, check a sample of records weekly for the first month. Deciding which systems should talk to each other, and in which direction, is a question I cover in digital marketing strategy and consulting.