The word “integration” hides the decision that causes most CRM trouble: when two systems disagree about a customer, which one wins?
A connector cannot answer that. It can move an address from billing into the CRM, then move an older address back on the next run. It can merge two people who share an email address. It can faithfully restore a field that a privacy workflow just cleared. Faster movement makes unresolved authority more expensive.
CRM integration services should begin with a record constitution. This is a buyer-owned table that names who may create, change, suppress, and delete each customer fact. The implementation follows that constitution. It does not invent one in code.
Our system and API integration cost guide owns the broad build-versus-platform and budget decision. Our data integration consulting guide covers the operating model for pipelines. This page is narrower: customer records that are read and written by sales, marketing, support, finance, and product systems.
Put one customer on the table
Choose a real customer whose history crosses several systems. Redact private values, but preserve the shape of the case. The packet might contain:
- two CRM contacts attached to one account;
- a billing customer with a different legal name;
- a support profile keyed by email;
- a marketing opt-out recorded after the last campaign export;
- an old product user ID that still appears in renewal reports.
Ask the provider to reconstruct why every copy exists. Do not accept “we will deduplicate during migration.” You need to know which identifiers are stable, which matches are assumptions, and which disagreements require a person.
The exercise turns a vague integration proposal into a specific model. It also reveals whether the provider treats the CRM as the automatic master of everything. Usually it is not. Billing may own the invoicing address. Identity may own the login email. Support may own a case classification. The CRM can display those facts without becoming their writer.
Write the record constitution
Create one row for each fact that crosses a boundary.
| Record element | Required decision |
|---|---|
| Business meaning | What the field means, including what it does not mean |
| Stable identity | The identifier used to join records across systems |
| Authoritative system | The system whose accepted value wins |
| Permitted writers | Users or services allowed to change the value |
| Propagation window | How late another system may receive the change |
| Conflict rule | Automatic winner, rejected update, or human review |
| Suppression and deletion | What stops movement and what must be removed |
| Reconciliation | How disagreement is found, assigned, and closed |
This is a proposed delivery artifact, not a feature promised by a CRM vendor. Its value is contractual. A field cannot quietly acquire a second writer after launch without reopening the row.
Salesforce’s architecture guidance separates process, data, and virtual integration and asks teams to consider timing, failure handling, and transactionality. Those dimensions are useful even if Salesforce is not in the stack. They force a buyer to name the job before choosing a transport.
Identity is a product decision
Email is convenient and often mutable. Company names are worse. A CRM’s internal ID may be stable inside the CRM but meaningless to billing or a product database.
For each participating system, record its native identifier and the cross-system identifier. Then test these cases:
- A person changes employers but keeps a personal email address.
- One customer uses two emails.
- Two family members share an inbox.
- A company changes its legal name.
- A user asks for one profile to be removed while another legal record must remain.
Some cases can be resolved by rules. Others need a review queue. The design should preserve the reason for a match or split, not just its result. Otherwise an operator cannot explain why two records became one.
Choose timing from the decision
“Real time” is not a quality grade. It is one timing choice.
Start with the business action. If a sales rep must see a credit hold before accepting an order, the allowed delay may be seconds. If marketing prepares a weekly audience, an overnight batch may be easier to inspect and replay. If users need external facts without copying them into the CRM, virtualization may fit.
The provider should state the consequence of delay and the consequence of unavailability. A synchronous credit check can block an order when billing is down. An asynchronous update can let the rep proceed with stale information. Neither is universally right.
Require the proposal to name timeout behavior, queue retention, retry rules, duplicate handling, and the maximum useful age of a message. “Near real time” without those values is sales copy.
Keep credentials smaller than the connector
A packaged connector may request broad CRM access because it supports many use cases. Your use case may need three objects and two actions.
Inventory every read, write, bulk operation, webhook, and administrative action. Map each to a dedicated integration identity where the platform permits it. Record the credential owner, rotation process, environment, and shutdown step.
NIST SP 800-228 treats API security as a lifecycle problem spanning development and runtime. Apply that lifecycle to the CRM connection: design permissions before build, test authorization failures before release, monitor use in production, and remove access at retirement.
The acceptance test should include a forbidden write. A connector that completes the happy path with an overpowered credential has not passed.
Reconcile facts, not job status
A green integration run proves that software executed. It does not prove that every system agrees.
Build an independent reconciliation for the facts that matter. For example, compare the number and value of accepted orders by stable ID, not merely the number of messages consumed. List missing records, mismatched values, duplicates, and records older than the propagation window. Send each exception to a named owner.
Reconciliation must survive the integration itself. If the same transformation creates the CRM value and declares it correct, one defect can produce both the error and the green check.
Agree how far back a replay can reach. Then run one. Expire a credential after the source has accepted a change, restore access, and have the operator recover without creating a duplicate or erasing a newer edit.
Make deletion travel on purpose
Deletion is not merely another field update. The participating systems may have different legal, contractual, and operational reasons to retain data. The integration team should not improvise retention policy.
For each deletion or suppression event, name:
- the authority that approves it;
- the systems that receive it;
- the data each system removes, masks, or retains;
- the evidence that confirms completion;
- the behavior of backups, exports, queues, and failed messages;
- the route for an exception.
Do the same for communication preferences. A marketing opt-out that reaches the CRM after the next export is not a harmless delay. Test the cutoff at the boundary where the audience is produced.
Compare providers with a recovery session
Give shortlisted providers the same redacted customer packet and constitution. Ask each team to show how it would detect and recover from one partial failure. The session should end with evidence: logs tied to the business record, the prior and final state, the retry decision, and the reconciliation result.
Score five things:
| Review area | Evidence to request |
|---|---|
| Meaning | Field definitions, identities, and authority decisions |
| Safety | Minimum permissions and a rejected forbidden action |
| Failure | Partial-write behavior, duplicate defense, and replay |
| Operation | Dashboard, exception queue, runbook, and named owner |
| Exit | Source, configuration, credentials, documentation, and transfer drill |
Connector count belongs near the bottom. A provider with fifty connectors and no conflict model is offering faster ambiguity.
What gmware would bring to discovery
Bring one disputed customer record, a diagram of the systems that touch it, a recent manual workaround, and the person who fixes bad records today. That is enough for a useful first session.
We would leave the session with an initial record constitution, an unknowns list, the first failure scenario, and a recommendation on whether native connectors, an integration platform, custom code, or no new connection is the smallest credible answer. No tool shortlist should exist before the record has rules.