CRM integration: what to connect, and what to leave alone

What does CRM integration actually mean?

CRM integration is more than moving data from one system to another. Vendors, and the people evaluating them, use one word for three arrangements with very different consequences. All three need the same decisions made first: which system owns each field, which direction data moves, how identity is matched, which conflict rules apply, what deletion does on each side, and who operates the connection. Without those decisions, a “two-way sync” produces duplicates and silent inconsistency.

Arrangement	What actually happens	What can go wrong
Import	Data is copied once, by hand or on a schedule.	It is stale the moment it lands, and re-running it creates duplicates.
One-way sync	One system owns the data; the other keeps a current copy it does not edit.	Little, if the ownership is honest. This is the arrangement to prefer.
Two-way sync	Both systems may change the same record and the change propagates.	Conflicts, loops, and a field that flips back and forth while two people argue with each other through software.

Two-way sync sounds like the generous option and is the one to spend the most skepticism on. It is right for a mailbox, where both the mail client and the CRM legitimately act on the same message. It is rarely right for a customer’s billing address, where somebody should own it and everybody else should read it.

Four ways the pipe itself gets built

The three arrangements say what the data does. How the connection is built is a separate question, and it decides who gets the call when it stops. Name which of the four you are buying before you sign, not after the first outage.

• A native connector. One of the two vendors builds and ships it. It fails on an expired authorization token or a provider’s API version change, and an administrator fixes it by reconnecting. Upkeep is close to nothing, until the vendor retires it on a schedule you do not control.
• An integration platform. A third-party service sits in the middle and holds the mapping. It fails at the seams: a field renamed on either side, or a monthly task ceiling reached in a busy quarter. Upkeep is a subscription plus one person who can read its error queue.
• A direct API build. Your developer or an agency writes against both APIs. It fails when either side ships a breaking change and nobody was watching the release notes. The build is the small cost. The upkeep is a permanent slice of somebody’s job, and that person eventually moves on.
• A scheduled file exchange. A file lands somewhere nightly and is loaded. Unfashionable, and often the most durable. It fails visibly, on an encoding, a reordered column or a file that never arrived, and visible failure is a virtue. Latency is a day, which for invoice status is usually fine.

Most stacks run two or three of these at once and none is wrong on its own. The combination to avoid is a hand-built API job doing what a native connector already does, kept alive by one person’s goodwill. If you are still working out which of your tools has a claim on the record at all, the CRM features a sales team touches daily are a better starting list than any vendor’s integrations directory.

Which integrations should you connect first?

Email and calendar are the first CRM integrations worth making. If you connect nothing else, connect these. A CRM that cannot see the mailbox is a CRM someone has to retype into, and retyping is where the record starts drifting from reality. Once mail syncs, the history attaches itself: the thread lands on the contact, the contact belongs to the account, and the deal has its own correspondence without anyone forwarding anything.

Three questions are worth answering before you switch it on for the whole team, because all three are awkward to change afterward:

• Which messages sync? Everything in the mailbox, or only the folders and the date range that matter to selling. Narrow is usually the right default, and the kinder one.
• Who can see them? Personal correspondence lands in a shared system. Agree on the visibility rule before the first message arrives, not after someone finds one.
• What happens when a person leaves? The record should keep the history; the mailbox connection should end with the account. Those are two separate acts and both should be deliberate.

Whether the mailbox is Gmail, Outlook or IMAP/SMTP, decide which users, folders and messages can be logged, and keep private mail private. Test the calendar side as carefully as the mail: a canceled meeting, attendees in different time zones and a recurring series are where calendar sync usually goes wrong.

In Senitix CRM, each rep connects Gmail, Microsoft Outlook or any other mailbox over IMAP and SMTP, plus Google Calendar or Microsoft Calendar. Every connected mailbox has its own settings for how far back to sync, which folders to include and whether the synced mail is shared with the team or kept private. How many mailboxes a rep can connect depends on the plan, and the current limits are on plans and pricing. How the inbox works day to day is described under email and inbox in the feature catalog. Whichever vendor you evaluate, confirm its connectors in the product itself before you sign, not on a marketing page.

What should sync, and who wins a conflict?

Run every candidate field through four questions. It takes an afternoon for a whole stack, and it prevents the class of problem that is expensive to unwind later.

The most common good answer is: pull it into the CRM, one way, nightly, read-only. The most common bad answer is: sync everything both ways because we might as well.

The first time two systems disagree

The plan holds until a rep corrects a phone number in the CRM on the same afternoon finance corrects it in the ledger. Two writes, one field, and whichever lands last wins by accident. The cheapest time to settle that is before anything is connected.

Write one line per synced field: which system wins a conflict, and what happens to the value that loses. There are three defensible rules. Owner wins, where the system of record overwrites and the other edit is discarded, which is right when one system is the record by law. Last write wins, honest for a mailbox and dangerous for anything a person is measured on. Nobody wins, where the record is flagged and a human decides, which is the only safe rule for money.

Whichever you choose, leave a trace of the value that lost. An edit that vanishes without explanation teaches the team the CRM is lying to them, and they go back to their own spreadsheets. That ownership table is also the list of owned fields CRM database design and access control rest on, and where an owner is genuinely unsettled, the argument belongs in CRM strategy rather than in a mapping spreadsheet.

Should accounting and ERP data sync both ways?

Rarely. Finance systems are systems of record by design and often by law. Their data should flow into the CRM so a seller can see whether the last invoice was paid before promising a discount, and it should not flow back out. Editing a customer’s tax details from a sales board is how two ledgers stop agreeing.

The exception is the handover point, where a won deal becomes an order or an invoice draft and a controlled push in the other direction is genuinely useful. Even then, push a document, not a set of fields, and have the CRM record store the reference the finance system gives back. That reference is what lets you answer “which invoice was this?” a year later without a spreadsheet.

Assign ownership for every customer, product, tax, price, quote, order and invoice field that crosses the line. A common split is that the CRM owns the selling process up to the accepted quote, while the accounting or ERP system owns the final financial records. Saying which is which, field by field, is most of the design.

Senitix CRM has no packaged connector today for QuickBooks, Xero or the other accounting systems US businesses run. It can create an invoice from an accepted quote or order, but it is not an accounting ledger. Invoice data leaves as a CSV or Excel export, and what a seller needs to see from finance comes back as a CSV or Excel import that updates the matching records. The accounting system stays the record.

How do you match records without creating duplicates?

Every CRM integration has to answer one question thousands of times: is this the same customer? Get the matching key wrong and each sync run adds another version of the same company.

• Match on something stable. An email address for a person; an account number or a tax ID such as an EIN for a company. Both survive a rename; a company name does not.
• Store the other system’s ID. Keep the ERP’s customer number on the CRM record, and matching becomes a lookup rather than a guess for good. In Senitix CRM that number lives in a custom field.
• Decide what happens on no match. Create a record, or park it for review. Silent creation is how a database doubles in a quarter.
• Make the sync idempotent. Running the same batch twice should change nothing the second time. Test that deliberately, because eventually it will happen by accident.

If the systems you are joining are already full of near-duplicates, connecting them multiplies the mess rather than resolving it. Clean first: what a CRM database is, and how to keep it clean is the companion piece to this one.

What happens when a connection fails?

Usually it stops quietly, and the damage depends on whether anybody finds out before a customer does. Tokens expire, a password changes, a rate limit is reached, someone renames a field upstream: every CRM integration meets one of these eventually. Three things decide whether it costs an afternoon or a quarter, and none of them is technically difficult.

1. A named owner. Not a team. A person who is told when it stops and knows what it was for.
2. An alert somebody reads. A failure that only appears in a log is a failure nobody will notice for a month.
3. A way to catch up. When the connection returns, can it replay what it missed, or does someone reconcile by hand? Ask this before you go live, not during the outage.

Questions to ask before you connect anything

• Is this connection built and maintained by the vendor, or by a third party? Both work; only one has a single number to call when it breaks.
• Which direction does it run, and can that be constrained? A connection that can only run both ways is a design decision made for you.
• What is the sync frequency, and is it metered? Real-time and hourly are different products, sometimes at different prices.
• What personal data crosses the boundary? Every connection is a data flow, and it belongs in your data map and in the vendor review your security team runs. Senitix itself is hosted in the EU, with no U.S. hosting option today. Where the data is processed is set out in the Senitix subprocessors list, and the terms it is processed under are in the Senitix Data Processing Agreement.
• How do we disconnect? What stays behind in the CRM when the connection is removed, and what disappears with it.

CRM integration terms, defined

System of record

The one system that owns a piece of data. Everything else holds a copy and should not edit it.

Two-way sync

Both systems may change the same record and the change is propagated. Right for mailboxes, rarely right for anything else.

Field mapping

The table that says which field here becomes which field there. The unglamorous document that decides whether a migration works.

Matching key

The stable value used to decide two records are the same thing, such as an email address, an account number or a tax ID.

Idempotent

Running the same sync twice changes nothing the second time. The property that stops a retry from becoming a duplicate.

Backfill

The one-off run that loads the history after a live connection is switched on, so the record does not start empty.

Rate limit

The ceiling on how often one system will answer another. The usual reason a sync that worked in testing fails at month end.

API scope

The permission a connected app is granted for one type of record, such as read, write or delete. Grant the least the job needs.

Webhook

A message one system sends to a URL when something happens, so the receiver is told instead of having to ask.

In what order should you connect your systems?

Mailbox and calendar first, because they change daily behavior. Then whatever creates records, such as the website inquiry form, so nothing arrives by email only; in Senitix CRM, built-in web forms that turn an inquiry into a lead are coming soon. Then accounting, one way, so a seller can see the payment position. Then anything else, and only with a reason written down. Automation belongs after all of it, not before: rules built on a field that is about to change ownership will fire on the wrong data, and sales automation is much easier to reason about once the sources are settled. If the stages and fields themselves are still in flux, designing a CRM people keep updating comes first.

Each CRM integration then goes live the same way:

1. Define the outcome and the ownership of every field it touches.
2. Map the fields, and the identities that decide two records are the same.
3. Test with sample records before real ones.
4. Test failure, retry and delete on purpose.
5. Release to a small cohort of users first.
6. Monitor latency and errors from the first day.

In Senitix CRM, every connection writes to the same customer record. There is no QuickBooks, Xero, Slack or Zapier connector and no one-click import from Salesforce or HubSpot today, so moving from another CRM is a CSV or Excel import, available on every plan. What each plan includes is published on plans and pricing. And if you are earlier than this, still working out what the CRM itself is for, start with our guide to CRM.

What does the Senitix CRM API cover?

Senitix CRM’s API is not a self-serve developer signup. It reaches four objects (contacts, accounts, deals and activities) through a connected app that the Senitix team registers for your workspace, with its own read, write and delete scopes. Leads, quotes, products, orders and invoices are not exposed through it.

The two terms are easy to blur. An API reads or writes on request; a webhook notifies a target after an event. A production design for either includes least-privilege authentication, idempotency, rate limits, signatures, retry, and a visible dead-letter or error process for the calls that failed.

It is enough to keep a customer list in step with another system, create a deal from an application you run, or log an activity from a tool that already knows something happened. How your workspace gets access, and at what scope, is something to confirm with the Senitix team before you schedule work that depends on it; what connects today is summarized under integrations in the feature catalog.

Outgoing webhooks, where Senitix CRM notifies a URL you register whenever a record changes, are coming soon. Until they arrive, keeping an outside system current means asking on a schedule instead of being told, through the connected app the Senitix team sets up for that integration. Where this work sits in a wider rollout is set out in the CRM implementation steps.