A long-standing client opens three urgent support tickets in one week about invoices that won’t export. The help desk knows. The CRM doesn’t, because the help desk connection only syncs names and email addresses. On Thursday the client’s main contact gets an automated email asking them to leave a review and refer a colleague. Both systems were working. They just weren’t sharing the one fact that mattered that week.
That is what most integration problems look like from the inside. The connection exists and the sync log is green, yet a specific field, event or record type never makes the trip, or makes it in a shape the CRM can’t use. Automation built on top of that data then behaves exactly as designed, with the wrong inputs.
We treat integration as part of the customer system. Before anything is connected, we work out what each system is responsible for, which events should change a customer’s state in the CRM, and what should happen when a sync fails at two in the morning.
What does CRM integration involve?
CRM integration is the work of deciding how data moves between your CRM and the other tools you run, then building and monitoring those connections. The build is usually the smaller part. The bigger part is agreeing which system is the source of truth for each field, how records are matched, how often data moves, and in which direction.
In practice a project might be one connection, such as a billing platform feeding subscription status into HubSpot, or a full map of every system that touches a customer record. Either way the method is the same: understand the business process, trace the data it needs, then choose the simplest connection that does the job reliably.
Where integrations usually break
Data ownership comes first
Every field that more than one system can write needs a single owner. Billing should own plan, subscription status and payment dates. The CRM usually owns lifecycle stage, lead status and record owner. The store owns order history. Support owns ticket status. When ownership isn’t set, the last system to write wins, and that changes from day to day.
Ownership also decides sync direction. Some fields should flow one way only. Others need two-way sync with a rule for conflicts, for example “the most recent edit wins” or “the CRM wins unless the value is blank”. We write these decisions down in a field-level map, because they are the first thing anyone needs when a sync misbehaves later. Our CRM data dictionary template shows the format.
How we design a sync
Field mapping
We map each source field to its CRM property, including type, allowed values and transformation rules. A “State” free-text field feeding a CRM dropdown needs a translation table. A full name field feeding separate first and last name properties needs a split rule and a plan for names that don’t split neatly.
Matching and duplicate prevention
Before a record is created, the integration should look for an existing one. Email is the obvious key for contacts, but it isn’t enough on its own when people use work and personal addresses, or when a system lets email be blank. We define the match order (for example external customer ID, then email, then a normalized phone number) and what happens when two possible matches come back. Platforms differ here: HubSpot deduplicates contacts by email and companies by domain, while many marketing and ecommerce tools key profiles differently, so the rule has to account for both sides.
Trigger and timing
Some data needs to arrive in seconds, like a demo request that should be routed while the prospect is still on the site. Some can wait for a nightly batch, like product usage totals. Matching the timing to the business need keeps costs and API usage sensible.
Events as well as records
A record sync tells the CRM who someone is. Events tell it what just happened: trial started, order placed, ticket escalated, invoice overdue. Those events are what move customers between states and trigger automation, so we decide which ones the CRM needs and how they’ll be stored.
Not sure what your integrations are actually sending?
We'll trace a handful of real records through each connection and show you which fields and events arrive, which don't, and which get overwritten.
Native integrations, workflow tools or the API?
The right connection depends on the job, and we often use more than one in the same setup.
Native integrations come first when they move the objects and fields you need. They’re maintained by the vendors and cost less to keep running. They fall short when they only sync some objects, can’t apply your rules, or overwrite fields you need to protect.
Workflow tools add logic between systems. Zapier suits straightforward app-to-app work with lookups before creates. Make handles branching, iterators and heavier data transformation. n8n fits teams that want code steps, complex API calls or self-hosting. Our comparison of Zapier, Make and n8n goes into the trade-offs.
Direct API and webhook work makes sense for high volumes, near-real-time needs, or logic too involved to maintain in a visual builder. Webhooks push events the moment they happen, which beats polling, but the receiving side has to cope with retries, duplicate deliveries and events arriving out of order. When none of the standard options fit, we scope a custom integration.
Error handling you can see
An integration without error handling isn’t finished. For every connection we build, we decide:
- what counts as a failure, including partial ones like a record created without its required fields;
- whether the step retries, and how many times, before it stops;
- where failed records go so they can be replayed rather than lost;
- who gets alerted, through which channel, and with enough detail to act.
Each platform has its own tools for this. Make scenarios can attach error handler routes to individual modules. n8n supports a dedicated error workflow. Zapier has autoreplay for some failures and sends error notifications. Custom code needs logging and alerting built in. We use what the platform offers and add a simple monitoring check where it doesn’t cover the risk, such as a daily comparison of order counts in the store against orders recorded in the CRM.
How a project runs
Map the current landscape
We list every system connected to the CRM, what each one sends and receives, and who set it up. Hidden Zaps and forgotten API keys usually surface here.
Agree ownership and requirements
Together we decide the source of truth for each shared field, the events the CRM needs, and the timing each one requires.
Design the field map and sync rules
Mapping, matching logic, conflict rules, transformations and error handling are written down before anything is built.
Build and test with real scenarios
We test with realistic cases: a returning customer, a record with a missing email, a canceled order, an event that arrives twice.
Monitor and document
Alerts go live, the field map becomes reference documentation, and your team knows what to check when something looks off.
Integration work often follows a CRM audit, which tends to uncover the broken connections, or sits inside a larger CRM implementation. If you’re changing platforms, it becomes part of CRM migration. Pricing is quoted per project after scoping, since the number of systems and the volume of custom logic vary widely. Starting prices for related services are on the pricing page.
Which systems can you connect to a CRM?
Most tools that offer an API, webhooks or a workflow-tool connector: ecommerce platforms, billing and subscription tools, support desks, form builders, scheduling, webinar platforms, product databases and data warehouses. Our deepest platform work is in HubSpot and Klaviyo, and we also connect the other systems listed on our platforms page.
Should we use Zapier or build directly against the API?
Use Zapier when the logic is simple, volume is moderate and someone on your team should be able to read the automation. Move to Make, n8n or direct API work when you need complex branching, high volumes, tight timing or careful control over retries. Many setups mix both.
How do you stop integrations creating duplicate records?
By searching before creating, using a defined match order, and normalizing the keys first, such as lowercasing emails and formatting phone numbers consistently. Existing duplicates are a separate job, usually handled through CRM data cleanup before the new integration goes live.
Can you fix integrations someone else built?
Yes. We start by documenting what the existing connection does, including the side effects no one expected, then decide whether to repair, rebuild or replace it.
What happens when an integration fails after you’ve built it?
It should tell someone. Every connection we build has an agreed alert route and a way to replay failed records. If you’d like us to keep watching it, integration monitoring can be part of ongoing CRM optimization.
Do you need access to our systems?
Yes, usually admin or integration-level access to the CRM and the connected tools so we can review settings and create API credentials scoped to the job. Our security page explains how we handle credentials and data.