CRM integration: decide which system owns each field before you sync

List the fields the integration will touch and assign one owning system to each. Company name and sales stage may belong to the CRM. Billing contact, payment terms and invoice status may belong to the accounting system. Contract dates may belong to a contract repository. The owner is where the value is created and corrected; other systems receive copies.

A field without an owner is a warning sign. If two teams expect to edit the same value, decide whether one system becomes read-only for that field, whether changes route through a request, or whether the field should be split. "Billing address" and "shipping address" are often two fields that were stored as one.

I would also record the business meaning of each field. Two systems may both have a "status" field that means different things. Mapping them directly creates a record that looks consistent and is wrong.

For each field, decide whether changes flow one way, both ways, or not at all. One-way flows from the owner are easier to reason about. Two-way sync needs a conflict rule, and "last write wins" is a conflict rule that quietly discards someone's work.

Timing matters as well. Some values need to move within minutes, such as a closed deal that should create an onboarding task. Others can move on a schedule. Faster is not automatically better: frequent polling consumes API capacity and can spread a bad change across systems before anyone notices.

Platform limits shape this design. HubSpot's API usage guidelines describe per-app burst limits measured over 10-second windows, a daily limit shared across the apps in an account, and 429 responses once an app exceeds its limits. Salesforce's API request limits set a total number of calls per 24-hour period that depends on edition and licenses. Check the current figures for your own accounts before choosing a sync frequency, because other integrations may already be using part of that allowance.

Matching on email address or company name feels convenient and breaks in ordinary ways. People change jobs, companies rename, and two branches share a name. I prefer storing the other system's record identifier on each side once a match is confirmed, and using that identifier for every later update.

The first match is the hard one. For existing records, run a matching pass that proposes pairs and flags ambiguous ones for a person to confirm. Do not let the integration create a new record whenever it fails to find an exact match; that is how duplicates multiply.

Keep an exceptions list for records that could not be matched or that matched more than one candidate. That list needs an owner and should shrink over time. If it grows, the matching rules or the source data need attention.

Deletions and merges are where integrations do the most damage. If a salesperson merges two duplicate companies in the CRM, should the accounting system merge them too, archive one, or do nothing? If a contact is deleted at the person's request, which copies must also be removed?

I would not propagate deletions automatically until the team has agreed what each one means. A safer first release marks the record as inactive in the receiving system and places it in a review list. The rules can become more automatic once the team has seen real cases.

Every sync will eventually fail: an expired credential, a validation rule in the destination, a rate limit, a renamed field. The integration should record each failure against the business record it affected, retry only where repeating the call is safe, and surface the rest to a named person.

The quiet failure is worse than the loud one. If a record stops syncing and nobody is told, the two systems drift apart until a customer notices. A short daily list of records with unresolved sync errors, oldest first, is often more useful than a large dashboard.

AI can help with parts of this work. It can suggest likely matches between records with slightly different names, explain a sync failure in plain language, or propose a field mapping from sample data. Those are suggestions for a person to confirm.

I would not let a model decide which value is correct when two systems disagree about a customer's billing details, or let it merge records on its own. Those decisions affect invoices and customer relationships, and they need an accountable person and a record of what was decided.

Before go-live, run the integration against a copy of real data in a test environment, including the awkward cases: duplicates, missing required fields, recently merged companies, and records edited in both systems on the same day. Check the results with the people who own each field.

The acceptance condition I would agree with the team is simple to state. For the agreed fields, each system shows the value its owner entered, conflicts appear in a review list instead of being overwritten, and every failed sync is visible to someone who can act on it.

Bring the list of systems, the fields that matter and the cases that currently go wrong.