Short answer: plan each CRM integration before configuring it. Record what flows, which system is authoritative for each field, how records and relationships match, what a failed event is allowed to do on retry or replay, and how you will test the result. The companion worksheet gives those decisions a place to live. The worksheet does not make an integration idempotent; your target-side create/update rules, unique constraints or dedupe ledger, and acceptance tests must enforce the intended business effect.

Step 1 — Inventory each flow and its boundary

Use one worksheet row for each field or relationship that crosses a system boundary. For each row, name the integration, source system, target system, target object, direction, business owner, and the trigger that creates the event.

  • One integration can contain several objects and relationships. An invoicing flow might write an invoice, link it to a CRM deal, and copy a payment date. Treat those as separate mapping decisions.
  • Write down why the flow exists. If stopping it would break a required workflow, record that workflow. If it only supports an occasional manual export, keep it manual.
  • List exclusions beside inclusions. Internal notes, attachments, historical activity, or a field that remains read-only may be deliberately excluded. An exclusion with an owner is easier to test than an undocumented gap.

The unit of planning is the business event that causes a write, alongside the record it will match or update. A nightly batch and a webhook can touch the same field, but they fail and retry in different ways.

Step 2 — Set record authority and explicit relationships

For each object, decide which system owns the record identity and which system supplies each field. Record authority can be per object or per field; either works when the rule is explicit.

  • Record identity: name the key used to find or create the target record. Prefer a stable external ID that neither system regenerates.
  • Field authority: state which value wins, or route disagreements to a named human queue with a review cadence and a documented timeout action.
  • Relationship: map the relationship after both records are identified. Do not treat a display name as proof that two records are the same entity.
  • Deletion and archival: choose whether deletion propagates, becomes an archive or suppression state, or remains local. State which system is authoritative for that decision.

For a contact-to-company flow, the worksheet needs two linked decisions: match or create the company using a company key, then write the contact’s company relationship. Mapping a form’s company_name directly into what is presented as a contact field hides that relationship. A company name can be an input to review, but it is not a reliable cross-system identifier.

Step 3 — Map fields, keys, and value rules

Use the 19-column worksheet to record the route, behavior, and failure rules for every mapping row. The columns cover:

  1. Routing: integration_name, source and target systems, object, direction, master_system, source_field, and target_field.
  2. Runtime choices: sync_trigger, frequency, conflict_rule, error_handling, owner, and status.
  3. Failure proofing: record_matching_key, null_semantics, timezone_currency_rule, and failure_replay_rule.
  4. Context: notes.

Keep record matching separate from event idempotency:

Decision Question it answers Evidence to keep
Record matching Which business record should this event find, create, or update? Stable ID pair or approved matching rule, plus ambiguity handling
Event identity Have we seen this delivery, retry, or replay before? Source event ID and the target’s observed duplicate-suppression result
Business effect What must remain unchanged when the event is processed again? Create/update rule, unique constraint or dedupe ledger, and a repeat test
  • record_matching_key answers “which business record should this event update?” It ties one CRM contact, company, deal, invoice, or conversation to the corresponding record in another system.
  • failure_replay_rule must also name the event identity and the target-side protection against a repeated business effect. That might be a provider event ID plus a dedupe ledger, or an upsert against a unique business key. The right mechanism depends on what the target system actually provides.

An email address can be part of a matching rule only after the team confirms it fits the workflow. Case folding, aliases, address changes, recycled addresses, and shared inboxes can make email ambiguous. Define normalization, ambiguity handling, and a manual-review path. A form’s email field may be required for one lead form while another CRM accepts contacts without email; that form rule is not a universal object rule.

Also write value conversions down:

  • Empty value: decide whether a blank means “leave the target unchanged,” “write an empty value,” or “reject and route for repair.”
  • Date and time: state the source timezone, canonical storage format, and daylight-saving handling.
  • Money: store the currency code with the amount, or document the base-currency assumption and conversion source.
  • Controlled values: map every source stage, status, owner, or picklist value. Send unmatched values to a decision queue rather than silently inventing a default.

Our data export and migration checklist covers the one-time move from one system to another. This worksheet covers the ongoing connection after that migration.

Step 4 — Choose event, conflict, and failure behavior per scenario

Choose timing from the workflow, not from a general preference for “real time.” A lead routing rule may need an immediate event; an accounting reconciliation may use a scheduled batch with a visible run report; a cleanup mapping may remain manual. Record the reason for the choice and who notices when a run fails.

Treat exactly-once business effect as a design target that must be proven at the target system. Delivery can duplicate, a request can succeed before its acknowledgement is lost, a batch can restart from a checkpoint, and an operator can replay a failed event. The integration plan should therefore state:

  • the event’s stable source identifier;
  • the target operation that suppresses a second business effect;
  • what happens when the same event arrives with changed payload values;
  • where ambiguous matches and unrecoverable failures go;
  • who owns the exception queue and how stale items are escalated.

Filling in a CSV cell does not provide that protection. Verify it with duplicate delivery, retry, and replay tests before production and after a material connector change. The general distinction between repeated requests and idempotent effects is defined in RFC 9110 §9.2.2; Microsoft’s duplicate-message detection guidance is one implementation example, not a claim about any CRM package.

Conflict and deletion rules also depend on the scenario. A single-source one-way field has no two-writer conflict, while a bidirectional contact field needs a winner or review queue. A deletion may need to propagate for a lead, become an archive for an invoice, and remain local for an activity record. Write the chosen behavior into the affected rows.

Step 5 — Prove the rules with a small synthetic end-to-end test

Run the test with data approved for non-production use. Keep the source event IDs, target record IDs, payload fixtures, and observed results so another owner can repeat the test.

  1. Match an existing source record to the intended target record without creating a second copy.
  2. Test the same event ID twice. Confirm the second delivery has no additional business effect.
  3. Test a retry after a simulated timeout or lost acknowledgement. Confirm the target does not duplicate the original result.
  4. Fail a batch after some events succeed, replay it from the documented checkpoint, and compare business results rather than delivery counts.
  5. Test a contact-to-company or other relationship mapping. Confirm both records resolve before the relationship is written.
  6. Change both sides of a two-way field and confirm the documented auto-winner or human-review path.
  7. Test an empty value, timezone boundary, currency-bearing amount, and unmatched controlled value.
  8. Check that the integration credential can reach only the agreed objects and fields; test the chosen delete/archive behavior.
  9. Keep the first weeks of run logs, exception-queue counts, and owner acknowledgements under review. Escalate based on the written thresholds rather than waiting for a user to report missing data.

The CRM implementation planning framework places this integration work among configuration, pilot, and cutover. Use the two guides together when the integration is part of a CRM rollout.

What this worksheet is not

  • It is not a connector recommendation. It does not score products, prices, or assume a native connector exists.
  • It is not a guarantee of exactly-once delivery. It is a place to define and test the business-effect controls that the connected systems must provide.
  • It is not a security review. API credentials, least privilege, retention, and customer-data obligations need the approvals your organization requires.

Download the worksheet

Download the CRM integration data-mapping worksheet. The CSV contains 19 columns and six synthetic example rows. Replace them with your own systems, keys, owners, and test evidence.

Sources and scope

This method makes no vendor pricing, speed, customer-count, integration-count, or ROI claims. The two references below support the general repeated-request and duplicate-message concepts used in Step 4; they are not statements about the capabilities of a particular CRM.

Disclosure: this page contains no affiliate links.