Connecting marketing automation to your CRM without creating a second source of truth
Bidirectional sync is the default setting in most integrations and it is the wrong default for most fields. Two systems both permitted to write the same value will eventually disagree, and the loser is whichever process ran last, which is usually the scheduled one rather than the person who typed the correct answer that morning. Integration decisions are made field by field, not system by system, and the teams that skip that step spend the following year diagnosing data that changes on its own.
Why does field-level ownership matter more than the integration itself?
Because every serious sync problem is a disagreement about one field rather than a failure of the connection. The connection almost always works. What goes wrong is that a salesperson updates a job title in the CRM, an overnight sync overwrites it with the value from a form the contact filled in two years ago, and nobody can explain why the record keeps reverting.
Assigning ownership means deciding, for each field that matters, which system holds the truth and which merely reflects it. The reflecting system should have that field set read-only where the platform allows it, because a rule that exists only in a document will be broken by whoever builds the next integration.
This is a short exercise. Most integrations need agreement on a handful of fields: email, name, company, job title, lifecycle stage, owner, consent state, and whatever your scoring reads. Everything else can sync in one direction without anyone caring.
| Field | Should be owned by | Sync direction | Reason |
|---|---|---|---|
| Email address | Whichever system is your identity key | One way, out of the owner | Two identity keys create duplicates that regenerate after every clean-up |
| Consent and subscription state | The sending platform, usually | One way, out of the owner | Disagreement here has legal consequences, not cosmetic ones |
| Lifecycle stage | The CRM | One way, into the platform | Sales knows about deals and purchases; the platform only sees behaviour |
| Record owner | The CRM | One way, into the platform | Routing and suppression rules depend on knowing who is working the account |
| Lead score | The platform | One way, into the CRM | Sales needs to read it, and nothing good comes from sales editing it |
| Job title and company size | The CRM if sales verifies them, otherwise enrichment | One way, out of the owner | Self-reported form values are frequently older than what sales confirmed |
What causes sync loops and API exhaustion?
A field written in both directions, where each write is seen by the other system as a change worth propagating. System A updates the record, System B receives the update and writes it, System A sees a modification and syncs again. The loop can run for as long as the API quota lasts, and the usual first symptom is that other integrations stop working because the quota is gone.
Timestamp-based syncs make it worse. If the integration selects records modified since the last run, and its own writes update the modified date, every run selects everything it touched last time. This is why a sync that worked for months suddenly slows as the record count grows.
The fixes are unglamorous and effective: one-way for anything contested, filters that ignore changes made by the integration's own user account, and a genuine look at the API call volume in the platform's usage log before adding another tool to the same connection.
How should forms and field capture apps feed the system?
Through one system, never two. Teams commonly run a mobile form app for site visits, inspections or trade stand capture, and the tempting configuration is to write each submission into both the CRM and the marketing platform so that nothing is missed. That arrangement creates two records for one human, with different creation times and different field sets, and the deduplication problem that follows is permanent.
The arrangement that holds is a single entry point. Submissions post to whichever system owns identity, that system creates or matches the record, and the sync propagates it. If the form tool can only post by webhook, point the webhook at one destination and let the existing integration do the rest.
Field capture adds a specific complication: offline mode. An app that queues submissions while out of signal will replay them on reconnection, sometimes more than once, and sometimes with timestamps from the moment of upload rather than the moment of capture. Ask for a submission identifier that the receiving system can use to reject a repeat, and store the captured time as its own field rather than trusting the created date.
What should trigger a handover to sales?
An event, delivered promptly, not a nightly batch. The value of a handover decays quickly, so a sync that runs once a day converts an urgent enquiry into a stale one. Where the platform supports it, push the important transitions immediately and let the bulk field updates run on a schedule.
Handover should also carry context in a form a salesperson can read in seconds. A score with no explanation invites the response most sales teams already give it. The last few actions in plain language, the source, and the form answers, placed where the salesperson already works, are what make the flag usable.
Then make rejection possible. A field where sales can send a lead back with a reason is the only reliable feedback loop between the two systems, and reading those reasons monthly corrects more scoring problems than any amount of model tuning.
How do you handle deletions and merges?
Deliberately, because the defaults are usually dangerous. If a record is deleted in one system, the question of whether the sync deletes it in the other has no universally right answer, but it does have a right answer for you, and discovering it accidentally is expensive. Most teams should not propagate deletions at all, and should instead mark records inactive.
Merges are the harder case. When two CRM records merge, one identifier disappears, and any integration mapping records by that identifier now points at nothing. Check whether your integration follows merges or silently orphans the mapping, because an orphaned record continues to receive mail while appearing, in the CRM, to no longer exist.
The suppression list is the one thing that must survive everything. Opt-outs, bounces and complaints should live where a merge, a deletion or a re-import cannot resurrect an address, because re-mailing someone who unsubscribed two years ago is a failure people remember.
What should you check before turning a sync on?
Run it against a sandbox or a small segment first, then reconcile by hand. Take twenty records, write down what each system holds for the fields that matter, run the sync, and compare. Twenty records take an hour and reveal every mapping error you are about to apply to a hundred thousand.
Check the field-by-field ownership table exists and is agreed by both the sales and marketing owners, in writing. This is the artefact that survives staff changes, and its absence is why so many integrations are understood by nobody after the person who configured them leaves.
Finally, confirm what happens when the sync fails. Silent failure is common, and a connection that has been broken for three weeks is usually discovered by a salesperson wondering why no leads arrived, which is the most expensive possible way to find out. An alert on zero records synced costs almost nothing to add.
Common questions
- Should a CRM and marketing automation sync be bidirectional?
- Per field, rarely per system. Bidirectional sync on a contested field means both systems can write it, so the value that survives is whichever process ran last, usually a scheduled job rather than the person who typed the correct answer. Decide ownership for the handful of fields that matter, set them read-only on the reflecting side, and leave everything else one way.
- What causes a sync loop between two systems?
- A field written in both directions, where each system treats the other's write as a change worth propagating. The loop continues until the API quota is exhausted, and the first symptom is usually that other integrations stop working. Timestamp-based syncs make it worse, because the integration's own writes update the modified date and cause every run to reselect the same records.
- How should a mobile form or field capture app feed marketing automation?
- Through a single entry point. Writing each submission into both the CRM and the marketing platform creates two records for one person, with different creation times and field sets, and the resulting duplicates regenerate after every clean-up. Post submissions to whichever system owns identity and let the existing sync propagate them, even if that means pointing a webhook at one destination only.
- What goes wrong with offline form capture?
- Queued submissions replay on reconnection, sometimes more than once, and often carry the upload time rather than the capture time. That produces duplicate records and misleading timestamps in any sequence triggered by the submission date. Ask the capture tool for a stable submission identifier the receiving system can use to reject repeats, and store the captured time in its own field.
- Should deleting a record in one system delete it in the other?
- Usually not. Most teams are better served by marking records inactive and never propagating deletions, because an accidental deletion then costs nothing. Merges need separate attention: when two CRM records merge, one identifier disappears and any integration mapping on that identifier can be orphaned, leaving a record that still receives mail while appearing in the CRM to no longer exist.
- How do you test an integration before switching it on?
- Take twenty records, write down what each system holds for the fields that matter, run the sync against a sandbox or a small segment, and reconcile by hand. That takes about an hour and surfaces every mapping error before it is applied to the whole database. Add an alert for a sync that returns zero records, since silent failure is common and is otherwise discovered weeks later.
