CRM Data Sync: How to Keep Records Consistent Across Tools

A rep fixes a phone number in the CRM on Monday. The support tool still has the old one, so a renewal call goes to a dead line. Marketing keeps emailing an address the contact updated three weeks ago. Finance pulls a report off a CSV export that was stale the moment it downloaded. None of these is a real failure on its own. Together they are the slow tax of records that live in five tools and never agree.

CRM data sync is the work of keeping those records consistent as they change, so the same contact, deal, or company reads the same way everywhere it matters. Done well, an update in one place lands everywhere it should within seconds and nobody re-keys anything. Done badly, you get duplicate contacts, silent overwrites, and a sync that stops one night without telling anyone for a week.

Getting there is not luck. It comes down to a handful of decisions made before you open a single tool, and the sync that survives real volume is the one that gets them right up front. We build these as Integrations work at bottta, so the framing here is what holds up in production, not what demos well.

Decide which direction the sync runs, and name the source of truth

Before you open any tool, answer one question. When the same field disagrees in two systems, which one wins? That answer is your source of truth, and it can differ field by field. Contact email might be owned by the CRM, subscription status by the billing tool, support tier by the helpdesk.

There are two shapes, and the gap between them is where most trouble lives:

• One-way sync. One system is the master and the other mirrors it. A change flows in a single direction only. This covers most real needs and is far safer.
• Two-way sync. Both systems can edit a record and each change propagates to the other. Useful, and the source of most sync disasters, because now two people can edit the same field in two tools inside the same minute.

If you can make it one-way, make it one-way. Reach for two-way only when both teams genuinely edit the same records in their own tool and neither team will switch. Even then, resolve the source of truth per field, never "the whole record wins." A record-level rule is how a billing update quietly stomps a support note.

Map the fields and pick a match key that won't create duplicates

The match key is how the sync decides that a record over here is the same person as a record over there. Get it wrong and every run creates duplicates instead of updating what already exists.

Email is the usual key for contacts, but people change emails and share inboxes like info@. Where you have a stable identifier, use it. Both HubSpot and Salesforce let you store an external ID field, so you can hold the CRM's own record ID on the other system and match on that instead of a value a human can edit. For companies, match on domain, not company name. "Acme, Inc." and "Acme Inc" are the same account, and a name match will treat them as two.

Then map the fields themselves. List every field, its type on each side, and its direction:

| Field | System A | System B | Direction | Watch for | |---|---|---|---|---| | Email | text | text | A to B | shared inboxes, changes over time | | Company | domain | domain | two-way | match on domain, not name | | Deal stage | picklist | picklist | A to B | values must map one to one | | Phone | text | text | two-way | normalize format and country code |

Picklists and dropdowns are the quiet killer. A value that exists on one side but not the other will either fail the write or store garbage. Normalize before you sync: phone formats, country codes, and any stage or status name that does not line up cleanly. This is the same discipline that keeps a data-entry pipeline honest, covered in how to automate data entry without corrupting your records, and whether your records are even ready to sync in the first place is worth checking before you wire anything.

Choose where the sync actually runs

The tool you pick sets the ceiling on what the sync can handle. There are three DIY routes and one we would recommend for anything load-bearing.

Zapier is the fastest to stand up and the wrong tool for true two-way sync. Zapier's own documentation states that Zaps are one-way automations and that it does not support two-way syncing between apps, per its Zap limits help doc. You can fake two-way with two Zaps pointing at each other, which is also exactly how you build an infinite update loop. It is fine for a simple one-directional job like a new lead landing in the CRM.

Make can model both directions in one scenario and gives you branching, filters, and lookups. It prices by operations. The Free plan includes 1,000 operations a month and the Core plan starts at $9 a month billed annually for 10,000 operations, and every module that touches data spends at least one operation, per Make's pricing page. A chatty two-way sync with lookups and transforms burns through operations faster than the trigger count suggests, so cost creeps up quietly.

n8n gives you the most control, self-hosted or on cloud, and prices by execution regardless of how many steps run inside it. Cloud Starter is 2,500 executions a month and Pro starts at 10,000, per n8n's pricing page. It is the DIY pick when you need custom conflict logic and a queue. For a wider look at these platforms, see the best workflow automation tools for lean teams.

For a sync that has to hold at volume, the kind where an overwrite means a rep calls the wrong number or finance invoices the wrong entity, this is what we build as Integrations work at bottta. We map the fields, choose the match keys, put the conflict rules and rate-limit handling in one place we own, and wire in monitoring so a silent failure pages us instead of surprising you a week later. Most CRM syncs land as a fixed-scope $4K project, integrations included, with 30-day post-launch support. If your tools and records keep shifting and you want someone watching the sync as they change, the $3K/month retainer covers ongoing monitoring and fixes across up to three active workflows. If you are also weighing a first-party engineer or another vendor, build vs buy vs hire walks the real costs of each.

Respect the API rate limits before they throttle you

Every sync is really a stream of API calls, and both major CRMs cap them. Plan for the ceiling before your first backfill slams into it.

• HubSpot. A public app is limited to 190 requests per 10 seconds, with a daily cap of 625,000 requests on Professional and 1,000,000 on Enterprise, per HubSpot's API usage guidelines. A one-time import of 200,000 contacts at one call each hits the 10-second window long before it nears the daily cap.
• Salesforce. Salesforce caps synchronous API requests at 2,500 per minute, and the standard daily allocation is 100,000 plus 1,000 calls per Salesforce license on Enterprise, per Salesforce's app limits cheat sheet. A Developer Edition org gets a flat 15,000 calls per 24 hours, which is easy to exhaust during testing alone.

Three habits keep you under the line:

1. Batch. Both CRMs expose batch endpoints that read or write many records in a single call. Use them for backfills instead of looping one record at a time.
2. Sync deltas, not everything. Push only records changed since the last run, keyed on a last-modified timestamp. Re-syncing the whole database every hour is how you burn a daily allocation by lunch.
3. Back off on 429s. When the API returns "too many requests," queue and retry with a delay instead of hammering. A sync that ignores rate-limit responses gets slower under load, not faster.

Handle conflicts and failures, or the sync quietly corrupts data

A sync that only works when everything is clean is a sync that will corrupt data. The cases that matter are the messy ones, and DIY setups almost always skip them.

Both sides changed. The same contact was edited in both tools since the last run. Your conflict rule decides the winner. Last-write-wins by timestamp is simple and sometimes wrong. Source-of-truth-by-field is more work and usually right.

A record was deleted on one side. Deleting the mirror is dangerous and often unrecoverable. Prefer a soft flag, like marking the record archived, over a hard delete you cannot undo.

A write failed halfway. Half the fields updated, then a rate limit hit. You need idempotent writes, where running the same update twice is safe, and a retry queue that picks up where it stopped.

Loops. A two-way sync can echo itself: A updates B, B's change fires an update back to A, and around it goes. Break the loop with a source marker on each write, or by suppressing changes the sync itself originated.

Monitor the sync so a silent failure doesn't cost you a week

The worst sync failure is the one nobody notices. Build the watching in from the start.

Log every run with the counts that matter: records seen, updated, skipped, and failed. Alert on failure, and alert on silence too, because a sync that processed zero records all day is usually broken, not quiet. Then reconcile on a schedule: count records on each side and diff them, so drift surfaces as a number instead of a customer complaint. A dedicated data reconciliation tool is worth it once the record counts climb into the tens of thousands, and reconciling across more than two systems is its own discipline, covered in multi-system reconciliation.

Common mistakes that break CRM syncs

• Matching on name or email alone. Both change and both collide. Store and match on a stable external ID.
• Two Zaps pretending to be two-way. Infinite loops and doubled task usage, with no conflict handling underneath.
• No backfill plan. The sync handles new changes but never fixes the history, so old records stay wrong forever.
• Ignoring picklist mismatches. Dropdown values that do not map one to one write silent garbage nobody catches until a report looks off.
• Nobody owns it. The person who built it leaves, the sync rots on their laptop, and the first sign of trouble is a wrong invoice.

When to build it yourself vs bring in bottta

If the sync is one-way, low volume, and connects a single pair of tools, a DIY setup in Make or a plain Zap is a reasonable place to start. You will feel the ceiling soon enough, but there is no shame in starting small.

The moment it turns two-way, or the moment real money and customer contact ride on the records being right, treat it as an integration to build properly rather than a Zap to babysit. That is the line where working with bottta pays for itself: we own the match keys, the conflict rules, the rate-limit handling, and the monitoring, so the sync is something you can trust instead of something you hope is still running. If you are syncing two CRMs specifically, our HubSpot Salesforce integration setup guide goes deeper on that exact pair.

Frequently asked questions

Can Zapier do two-way CRM sync? Not as a real two-way sync. Zapier's own documentation says Zaps are one-way automations and that it does not support two-way syncing between apps, per its Zap limits doc. People approximate it with two Zaps in opposite directions, but that has no conflict handling and can loop. For genuine bidirectional sync, use Make, n8n, or a custom build with proper loop protection.

One-way or two-way, which do I need? Start by asking whether both teams actually edit the same records in their own tool. If only one system is ever the place a field gets changed, one-way is simpler, cheaper, and far safer. Choose two-way only when both sides truly edit the same data and you have decided the source of truth for each field.

How do I stop the sync from creating duplicate records? Match on a stable identifier rather than a value a human can change. Store the CRM's record ID as an external ID on the other system and match on that. For companies, match on domain instead of company name. Email works as a fallback but breaks when people change addresses or share an inbox.

How much does it cost to build a CRM sync? The platform is the small number. Make's Free plan covers 1,000 operations a month and Core starts at $9 a month annually, per its pricing page, while n8n cloud starts at 2,500 executions a month, per its pricing. The real cost is the design and the maintenance. A done-for-you sync from bottta is typically a $4K fixed-scope project, or the $3K/month retainer if you want it monitored and adjusted over time.

How often should a CRM sync run? If both CRMs support webhooks, run it on change so updates propagate in near real time. If not, a scheduled delta sync every few minutes is usually enough. Avoid full re-syncs on a tight schedule, because they burn API allocations fast against the HubSpot and Salesforce limits above.

Scope the direction, the match key, and the conflict rules first. The tool is the last decision, not the first. A sync you can trust is one a team owns and monitors, not a Zap nobody watches, and that ownership is what you get building it with bottta.