Customer data integration: How to connect the systems your business uses

Data consolidation brings information into a shared destination

Consolidation extracts records from several sources, maps them to a compatible structure, and loads them into a single destination. A one-time migration, such as importing a spreadsheet into a CRM, is consolidation that runs once. An ongoing integration keeps running. Fivetran's sync documentation describes a first "historical sync" that pulls all existing data, after which it moves only added or changed rows.

Copying records does not resolve identity. Two records for one customer stay two until a matching rule merges them, and conflicting values for one field still need a rule about which wins.

Data propagation sends changes between operational systems

Propagation moves a change from one working application to another. It can run one way, such as a form submission creating a CRM contact, or two ways, where either system can update the other. Updates can be event-triggered, where the source announces a change as it happens, or scheduled, where the integration polls the source. Zapier's trigger documentation describes both: instant triggers use webhooks, while polling triggers check every 15 minutes on the free plan and as often as every minute on paid plans.

Two-way synchronization requires rules for determining which update takes precedence when both sides change the same field. It rarely means everything moves both ways. Fields, attachments, and deletions are handled separately, and a connector can sync contacts both ways while sending tickets one way.

Data federation lets you query information across systems

Federation, also called data virtualization, leaves records in their source systems and provides a shared query layer that reads from several of them at once. Denodo's overview calls this a "logical interface" that allows "the underlying data to remain with the systems that own it."

If a source is slow, offline, or denies permission, the answer is slow or incomplete. Federation is not always live, either. Denodo's cache module can store retrieved data in an external database to spare slow sources. Federation reduces copying. It does not abolish it.

Data warehousing brings customer history together for analysis

A warehouse is built for analysis over years of records, not for the daily work of calling a customer or sending an invoice. ETL, or extract, transform, load, reshapes data before it lands. ELT, or extract, load, transform, lands raw data first and transforms it inside the warehouse. Fivetran's core concepts page describes its model as ELT: "extract and load the raw data into the destination, then transform it post-load."

Loading records into a warehouse does not update the CRM or the support tool. Sending a result back, such as a customer's total spend, needs a separate supported process, which Segment calls reverse ETL: querying the warehouse and syncing the result to destinations.

The four approaches differ in whether information is copied to a new place or read where it already lives.

Choose integration tools according to the work they must perform

The right tool depends on the approach you need, so I describe categories by what they do rather than ranking products. Categories overlap, and products within one rarely match.

Native application connectors are built into a product for specific other products. They are the simplest to set up and the least flexible, because the vendor decides which records and directions move.

Integration platforms such as Workato, Zapier, and Zoho Flow coordinate supported triggers and actions across many applications. Pricing is usually per task. Zapier and Zoho Flow each cap their free plans at 100 tasks a month, while Workato prices by quote.

Data pipeline tools such as Fivetran move data from applications and databases into analytical destinations. Fivetran's connectors run one way, from source to destination, and its pricing counts monthly active rows.

Customer data platforms such as Segment collect customer event and profile data from sources and send it to destinations; identity matching and activation depend on the product and plan. Federation platforms such as Denodo provide query access to distributed sources without copying them, primarily for large organizations. Custom API connections are code written to interface with each application's API. They do exactly what you need, and someone must maintain them when an API changes or a credential expires.

Whatever the category, compare: supported objects and directions, update frequency and whether it is polling or events, historical import, API limits, monitoring and retry behavior, the pricing unit, and the skills needed to keep the connection running.

A customer data platform still needs connections to its sources and destinations.

Customer data platform integration means connecting the CDP to where customer data originates and where it must go. Segment's connections documentation defines a source as "a website, server library, mobile SDK, or cloud application which can send data into Segment," and a destination as a business tool that receives data from it. A warehouse is a destination loaded in bulk: once a day on the free plan, up to 24 times a day on the Business plan. In between sits identity matching, which Segment calls identity resolution and offers on its Business plan and as an add-on, not on Free or Team.

A CDP is not a CRM, where staff works on individual records, nor a warehouse, nor an integration platform, which moves data without holding profiles, though the lines blur.

A unified profile does not guarantee correct matching. Anonymous website activity, a shared device, a household email address, or a customer who changes employers each need explicit rules. Segment's identity resolution settings make administrators set limits per identifier, a priority order, and blocked placeholder values so that "null" does not merge strangers. My view is that most small businesses can stop well short of a CDP: a few supported connections between the applications you already use are often enough.

Start with one customer-data connection and verify it before expanding

A small business usually keeps customer information in a form tool or website, an email account, a billing product, a help desk, and a CRM. Do not sync everything both ways from day one. Pick one connection, make it work, verify it, then expand.

• Identify the action the connection should support. "A new form submission should appear as a contact for the person who follows up" is a connection. "Sync forms with the CRM" is not.
• Inventory the information the action needs and omit fields with no defined purpose, because every copied field can go stale or cause conflicts.
• Choose reliable identifiers and keep the source system's record ID. An email address is not a dependable unique identifier, because people share, change, and mistype addresses. Keep the form entry ID, billing customer ID, and ticket ID on the CRM record.
• Map fields, types, dates, currencies, required values, and relationships, because a type mismatch or a missing required value can stop or corrupt a transfer.
• Decide which system can change each field, how conflicts are handled, and what a blank or deleted value means.
• Choose an update frequency based on operational needs. Scheduled polling is fine for invoice status. Event-triggered delivery suits a new inquiry someone should call back.
• Test with a small, authorized set of existing records. Check creation, an edit that updates rather than duplicates, the same event delivered twice, an invalid value, an expired credential, and a deletion on each side.
• Reconcile the initial import against the source by count and spot-check, then reconcile ongoing updates after a week. Assign one person to receive failure notifications and act on them.

Treat each connection as its own operation. Email synchronization links messages to a contact. A form submission creates or updates a record. An invoice update changes a status on an existing customer. A support-ticket lookup shows information that lives elsewhere. They need different mappings, frequencies, and tests.

Choose which system can update each field

For each field, there should be a single system from which changes originate. When the billing tool owns the billing address and the CRM owns the contact's phone number, a two-way sync has nothing to fight about. Where both sides must edit, you need a precedence rule, such as most recent write wins or one named system wins. Connectors often expose this as a skip, an overwrite, or a copy when a match exists.

A blank value is the hardest case. Does an empty field in the source mean "clear the destination" or "I have nothing to add"? Many connectors treat a blank as no change, and some overwrite. Deletion is the same question with higher stakes. Decide, test it, and write down the answer.

A small business connection plan links forms, email, billing, and support to a CRM, marking copied fields and linked records separately.

A connection can run successfully and still move the wrong data.

A dashboard full of green checkmarks says that transfers completed, not that the right information reached the right record.

Records get matched to the wrong customer when the identifier is weak. Two people who share an email address become one record, or one person with two addresses becomes two, under a rule nobody chose.

Repeated events create duplicates. Webhooks get resent, and polls overlap, so processing the same event twice should not create two records. Workato's trigger documentation says it keeps "a record of all seen events."

Two systems can overwrite each other in a loop. If a workflow writes to the same object its trigger watches, the write can retrigger it, which Zapier warns creates "an infinite loop that rapidly consumes tasks."

Required fields, renamed fields, or incompatible formats cause incomplete transfers. A renamed field silently stops mapping, a record missing a required value is skipped, and the run still reports success.

Permissions, expired credentials, rate limits, or connector changes interrupt updates. Segment's destinations documentation says it retries failed calls for four hours; after that, a failing event is gone unless someone replays it.

A historical import can succeed while ongoing updates fail. A deletion or a changed communication preference can fail to reach a destination, so someone who unsubscribed in one system keeps hearing from another. And a ticket or invoice can be visible through an integration without being copied or editable in the receiving system.

Five checks catch most of this: unmatched records, failed transfers, the delay between a change and its arrival, a reconciled record count on each side, and the time of the last successful synchronization. I would not trust anyone's benchmark for these; the right thresholds depend on what the connection is for.

Each copy of a customer's information is one more place it can be read and must be removed on request. Give the integration tool only the permissions it needs, and know how a deletion or opt-out reaches every destination. Integration moves data. Whether you handle it lawfully is a separate question.

Use Bigin to connect the customer information your team needs next.

Bigin is an operational CRM for small teams, where contacts, companies, and deals are worked on. It is not a warehouse, a master data platform, a CDP, or a federation engine. It offers supported connections, listed on the integrations page, for the sources above.

Zoho Forms pushes form entries into Bigin one way: into contacts, companies, deals, products, tasks, or events, with an option to update an existing record when a unique field matches. Zoho Books keeps contacts, companies, and products in sync with Bigin. Bigin's help lists that integration for the Express, Premier, and Bigin 360 editions, and Zoho Books' help says records sync every two hours after the initial sync. Zoho Desk syncs contacts and companies both ways by default or one way, and lets you view and create tickets from a Bigin record while the tickets stay in Desk. Bigin's help lists it for all editions, and Zoho Desk's help says a paid Bigin plan is required, so confirm your edition first. Zoho Flow and Zapier add triggers and actions for other apps, each with its own subscription.

These are separate products with their own plans, and a capability in one of them is not a Bigin feature. The next step is to take one connection from your plan, open its help page, and check its supported fields and direction against the owning system you chose for each field.