Two systems.
One clear version of the work.

What is CRM data sync?

CRM data sync keeps an agreed set of information aligned between a CRM and another system over time. A migration moves an initial dataset; a recurring sync also handles later changes, interruptions and conflicting edits. An initial import can be the starting point, but it is not proof that the continuing connection works.

“Two-way sync” is an incomplete specification. Does it cover every field, selected records, deletions, ownership changes or only a subset? Can both sides edit the same value? How quickly should a confirmed change appear? Write those answers down before selecting a connector or building a worker.

The aim is not to make two applications identical. A finance system may own invoicing facts while the CRM owns relationship context. Each can show a useful copy of selected information without becoming responsible for the other system’s entire data model.

Assign authority to fields, not vague system labels

For each shared field, name the authoritative source, permitted writers and direction of movement. In a fictional services business, the CRM might own the relationship owner, a delivery tool might own project completion and a finance application might own invoice payment status. A copied value should not become a competing source simply because it appears in another interface.

Some values look similar but mean different things. A deal amount can be a proposed fee while an invoice total includes tax or later adjustments. Keep them separate rather than allowing either system to overwrite the other. Likewise, a forecast close date is not a signed date and a contact’s preferred name is not necessarily a legal billing name.

Use the contract worksheet to record transformations and empty-value behaviour. Does an empty source clear the destination, mean unknown or leave the existing value alone? Test each case. Treating null, an omitted field and an empty string as interchangeable can erase useful information during an otherwise successful sync.

Keep an identity map that survives ordinary changes

Use stable source and destination IDs. Store the source system and workspace alongside an external ID so identical values from different tenants cannot collide. Names, domains and email addresses may help locate a candidate record, but their uniqueness and stability need an explicit policy.

When matching an existing dataset, separate confirmed matches from ambiguous candidates. Two companies may share a name; a person may change email address. Put uncertain matches into a review queue with enough context to decide. An automatic merge is difficult to undo once unrelated activity has accumulated on the combined record.

Define deletion and reactivation explicitly. A missing item in a filtered export does not necessarily mean the source record was deleted. Decide whether a source deletion archives the copy, removes a link, records a tombstone or requests human review. Preserve the identity history needed to prevent the next full load from recreating something deliberately removed.

Choose polling, events or a combination

Polling reads the source on a schedule. Events notify the consumer when something changes. A common design performs an initial load, processes events for ongoing changes and reconciles periodically. The right combination depends on the provider’s change-history guarantees, quotas and your acceptable delay.

Meibo’s record-list cursor paginates by record ID; it is not a modified-since change feed. Its webhooks can notify a consumer, but the integration still needs a recovery strategy. Do not describe an ID-based list request as an incremental update query or promise complete bidirectional sync solely because the two APIs exist [1].

Provider-specific history can expire. Gmail’s sync documentation describes full and partial synchronisation and requires a full sync when a stored history ID is no longer available [2]. The broader design lesson is to keep a tested reinitialisation path instead of treating a checkpoint as valid forever.

Advance the checkpoint only after durable progress

A checkpoint records what your integration can safely consider handled. Its meaning must be tied to durable work, not merely to the last request sent. If the worker advances its cursor before saving a destination result, a restart can skip records that were never applied.

One useful pattern records the batch, each item’s outcome and the destination identity before advancing the completed checkpoint. If individual records fail, either retain the checkpoint or durably track those exceptions under a clearly defined policy. Do not mark a batch complete while leaving its failures only in a transient log.

Plan the first load while new changes continue arriving. The provider may offer a snapshot or a history cursor; otherwise you need a documented reconciliation approach. There is no universal safe ordering for every API. Test the source’s actual behaviour with edits occurring during the load and make the remaining limitations visible.

Resolve concurrent edits without creating loops

A conflict occurs when both systems change information that the sync would otherwise overwrite. The simplest policy is one authoritative writer per field. Where multiple writers are genuinely needed, decide which changes can merge, which use a documented ordering rule and which require review.

“Latest timestamp wins” can be reasonable for some low-risk fields, but only if timestamps are comparable and their meaning is understood. It can be dangerous for a contract amount or a manually corrected address. Preserve enough prior state to explain which values differed and why a decision was made.

Prevent echo loops. If system A writes to B and B emits a change event, the worker should recognise whether the resulting value already matches the intended state. Use supported origin metadata, version checks or comparison of mapped values. Do not suppress every event for an arbitrary time window and risk losing a genuine human edit.

Measure agreement, not just activity

A healthy queue can still carry the wrong mapping. Reconciliation compares the agreed source population with destination identities, selected values and relationships. Define the population, time boundary and exclusions first; otherwise two different filters can create a false discrepancy.

Record created, updated, unchanged, rejected and unresolved outcomes with definitions that do not overlap. Compare totals, then inspect the exceptions and a representative sample of mapped values. Count agreement alone is weak evidence: a missing record and an unwanted duplicate can cancel each other numerically.

Set an operational target appropriate to the workflow. An enquiry may need prompt attention while an overnight reporting copy can tolerate more delay. Track the oldest unapplied change, unresolved conflict count and last successful reconciliation. These measures reveal a stuck connection more clearly than a permanent green “connected” badge.

Pilot one object, one direction and one recovery path

Start with a bounded population and a small field set. Run a dry comparison where possible, inspect proposed changes and establish who approves exceptions. Preserve a recovery reference before enabling destructive operations. A narrow pilot makes it easier to tell a mapping error from a volume problem.

Test a renamed record, an empty field, a deleted source, two competing edits and a restart in the middle of a batch. Include an expired or invalid checkpoint if the provider uses them. Demonstrate how the operator resumes work and confirms the destination has recovered.

Only expand the scope after the identity rules, failure states and monitoring are understood. Use the contract worksheet as a maintained reference, not a one-off launch document. When a field changes meaning or a provider changes its contract, review the mapping before enabling the new behaviour.

Common questions.