TL;DR: Validate all 18 checkpoints across six buckets before enabling CRM writes. This checklist is for RevOps, Sales Ops, and GTM leaders connecting a sales tool to Salesforce or HubSpot. The go-live target is zero unexpected overwrites, zero duplicate creations, and complete activity association in the canary test.

What are the key facts before CRM integration go-live?

A safe CRM integration launch has 18 pass-or-fail checks, six risk buckets, a controlled canary, and a tested pause path. The operating thresholds below combine the checklist's deployment rules with current Unify product documentation and one named customer story.

Methodology & limitations: This refresh reviewed the live Unify Salesforce and HubSpot documentation, official Salesforce and HubSpot guidance, three related Unify articles, and the Quo customer story on August 31, 2026. The checklist is a risk-control framework, not a benchmark study.

It excludes native dialer depth, conversation intelligence, and CRM migration tooling. Quo's one-hour setup is a named customer outcome, not a platform-wide implementation promise. Regulated teams must add their own privacy, retention, consent, and regional legal review.

What is the 18-point CRM integration checklist?

The 18-point CRM integration checklist validates the credentials, records, fields, activities, duplicate behavior, and recovery path that determine whether a new sales tool can write safely to your CRM. Treat every row as a release gate, not a discussion prompt.

Lock authentication and permissions before mapping data

Use a dedicated integration identity with only the access the sales tool needs. Salesforce explicitly recommends one integration user per calling system because separate identities improve traceability and limit the impact of a compromised or disabled account.

• Definition: Checks 1 to 3 cover a dedicated identity, least-privilege access, and tested authorization controls.
• Why it matters: Employee offboarding, broad permissions, or an untested reconnect path can disable or overexpose a production sync.
• How to test: Attempt an approved write and a blocked write, then pause, resume, and reconnect in a controlled environment.
• Pass threshold: The right actions succeed, prohibited actions fail clearly, and mappings persist through reconnect.
• Red flags: Personal credentials, shared passwords, system administrator access used for convenience, or settings that change after reconnect.

For Unify on Salesforce, the live required-permissions guide lists the system and object permissions needed for the intended sync. That explicit permission matrix is more useful than a vendor claim that an integration is simply “native.”

Map CRM objects before you map individual fields

Decide which records should exist before deciding which values they contain. Salesforce can represent a person as a Lead or as a Contact associated with an Account, while HubSpot centers the model on Contacts, Companies, and Deals.

• Definition: Checks 4 to 6 cover the record model, field-level source of truth, and associations.
• Why it matters: A correct value on the wrong object, or an orphaned activity, still breaks workflow and attribution.
• How to test: Create a canary for each person and company path, force one field conflict, and trace every required relationship.
• Pass threshold: Each record lands on the approved object, the documented owner wins conflicts, and no association is missing.
• Red flags: Unclear Lead versus Contact behavior, assumed “most recent update wins” logic, or records attached to the wrong account.

HubSpot's current data-sync documentation lets admins choose sync direction, review mappings, and map deal pipelines and stages. Those choices should be captured in the release record before go-live, not left only in an admin screen.

Test field fidelity with blanks, conflicts, and invalid options

Field testing must cover more than happy-path values. Required fields, custom fields, option lists, blank values, existing values, and read-only properties are the cases most likely to expose unsafe behavior.

• Definition: Checks 7 to 9 cover required fields and defaults, compatible types and options, and overwrite behavior.
• Why it matters: Missing required values, invalid options, and silent overwrites can corrupt data without a visible launch failure.
• How to test: Exercise blank and populated fields, every mapped option, one invalid option, and each required field with its source missing.
• Pass threshold: Valid values arrive unchanged, invalid writes fail visibly, and existing data follows the approved overwrite rule.
• Red flags: Guessed defaults, unknown options becoming blank, or populated CRM fields changing without an explicit rule.

For a narrower deployment test focused on field ownership and a canary batch, use CRM Integration Done Right: Keep Outbound Data Clean from Day One.

Prove activity logging on the exact CRM timeline reps use

Activity logging passes only when emails, replies, calls, and tasks appear on the correct CRM record with the fields needed for rep context and reporting. A complete activity feed inside the sales tool does not repair a blank or misassociated CRM timeline.

• Definition: Checks 10 to 12 cover emails and replies, calls and tasks, and the metadata required for attribution.
• Why it matters: Missing ownership, timestamps, or relationships make activity unreliable for reps and reporting.
• How to test: Send and reply through a canary sequence, complete a call and another task, then query the reporting fields RevOps uses.
• Pass threshold: Every activity appears on the correct person with the expected owner, time, status, relationships, and attribution identifiers.
• Red flags: Replies missing, tasks attached only to a company, or reporting dependent on free-text subjects.

Unify's Salesforce documentation says sent emails and replies can write to the Email Message object, while eligible calls and action items can write to Tasks. Unify's HubSpot documentation describes equivalent email and task sync behavior. For a deeper activity test, see How to Audit Your CRM Integrations for Data Gaps and Sync Failures.

Challenge duplicate handling before production data can multiply

Duplicate prevention must be proven against the records already in your CRM and the collisions a new tool can create. Matching logic should be explicit for people and companies, including what happens when more than one record already matches.

• Definition: Checks 13 to 15 cover the pre-launch duplicate baseline, matching keys, and collision scenarios.
• Why it matters: Without a baseline and deterministic matching, teams cannot separate old data debt from new defects.
• How to test: Use alternate emails, domain variations, multiple existing matches, repeated writes, and updates made in both systems.
• Pass threshold: The documented target is updated and no net-new duplicate or loop appears.
• Red flags: Expecting the integration to clean existing CRM duplicates, unknown multi-match behavior, or a retry creating another record.

Unify's current bidirectional-sync documentation says it matches people by email and companies by normalized website domain, then updates an existing record rather than creating another when a match exists. The same documentation is clear that Unify does not deduplicate records already present in Salesforce or HubSpot.

Build the rollback path before enabling writes

A rollback plan must stop new writes, preserve evidence, and restore the prior configuration without deleting valid history. The plan should be executable by one named operator during the launch window.

• Definition: Checks 16 to 18 cover a recovery package, a rehearsed pause path, and named owners for escalation and sign-off.
• Why it matters: Record exports alone cannot recreate a lost configuration, and unclear ownership delays containment.
• How to test: Have a second admin inspect the recovery package, rehearse the pause during the canary, and run a tabletop failure.
• Pass threshold: New writes stop immediately, valid history remains, and every owner can state the next action.
• Red flags: The only configuration copy is inside the changed tool, queued work is undefined, or only the vendor can disable writes.

Choose the right go-live path in 30 seconds

Choose the smallest launch that proves the highest-risk behavior in your environment. The correct path depends on write scope, CRM complexity, team size, and regulatory exposure.

• If the tool only reads CRM data: prioritize permissions, object coverage, sync timing, and exclusions before testing writes.
• If the tool writes people or companies: prioritize matching keys, required fields, overwrite rules, and duplicate collisions.
• If Salesforce uses Leads: prioritize Lead versus Contact creation, conversion behavior, account association, and lead assignment rules.
• If HubSpot associations drive reporting: include the separate association refresh in the test window before judging completeness.
• If multiple tools write the same fields: define a field-level source of truth and test a deliberate conflict before launch.
• If the team is regulated or enterprise: add security, consent, retention, audit-log, sandbox, and change-approval gates.
• If the team is small and speed matters: start read-only, run a narrow production canary, then enable approved writes.

Evaluate any CRM integration without vendor marketing

A CRM integration is ready when an administrator can prove what it reads, what it writes, how it matches, when it syncs, and how to stop it. “Native” and “bidirectional” are labels, not evidence.

• Definition: Ask the vendor to name every supported object, activity type, direction, timing model, and conflict rule.
• Why it matters: Broad claims hide object-level and field-level gaps that surface after purchase.
• How to test: Give the vendor the same canary scenarios in this checklist and require a live demonstration.
• Pass-fail thresholds: Every approved scenario succeeds, every prohibited write fails safely, and every error is visible to an admin.
• Red flags: The vendor cannot explain matching logic, cannot pause writes separately, or treats the CRM activity timeline as optional.

Use CRM Integration in Sales Platforms: How to Evaluate What Actually Matters when comparing vendors against this neutral standard.

How Unify covers this: Unify is outbound AI for sellers, where AI agents and sellers work side by side from finding in-market buyers to reaching them with the right message from one tab. Its Salesforce and HubSpot integrations document configurable field mappings, default values, read and write controls, activity sync, matching behavior, and approximately 15-minute read syncs. Unify also documents conservative overwrite behavior: populated standard CRM fields are not replaced during an update, while mapped Unify-specific fields can be refreshed.

What does a worked CRM integration test look like?

A useful worked test follows one canary from authentication through reporting, then proves the pause path before broad rollout. The two snapshots below separate a reusable test pattern from a published customer outcome.

Worked example: Salesforce canary

• Symptom: A new outbound tool must create Contacts and Accounts, log email and call activity, and preserve existing lifecycle fields.
• Diagnosis: The riskiest paths are domain matching, required fields, populated-field overwrite behavior, and Task associations.
• Fix: Use a dedicated integration user, map only approved fields, create one new person and one existing person, then send an email and complete a call task.
• Measurable pass condition: Zero duplicate records, zero unexpected overwrites, correct Contact-to-Account relationships, complete activity metadata, and a successful pause test.

Case snapshot: Quo

Quo's published Unify customer story reports that the team integrated Unify with Salesforce and its website in one hour. The same story says Unify handled the complexity of Quo's Salesforce setup out of the box, which is a relevant implementation proof point, but it should not be treated as a universal one-hour guarantee.

Adapt the checklist by role and segment

Keep all 18 checks, but change who owns them and which failure classes get the most scrutiny. Role and segment change the emphasis, not the release standard.

Role variants

• RevOps: own mappings, source-of-truth rules, automation side effects, audit evidence, monitoring, and rollback.
• Sales leaders: sign off on ownership, activity visibility, reporting, and rep workflow before rollout.
• Sales reps: validate the real CRM timeline, task flow, record associations, and opt-out behavior with canaries.
• Marketing: validate lifecycle fields, attribution, campaign context, consent, and suppression rules.

Segment variants

• SMB: use a narrow production canary when a realistic sandbox is unavailable, but keep a full export and pause path.
• Mid-market: add field-owner approval and downstream automation tests for every shared object.
• Enterprise: add sandbox validation, security review, segregation of duties, formal change approval, and rollback evidence.
• EU or regulated regions: add lawful-basis, consent, retention, data-residency, and deletion-path review with qualified counsel.

Run a 30, 60, and 90-day monitoring plan

Monitor the integration after launch because schemas, permissions, automation, and user behavior change. The first 90 days should move from stabilization to drift detection to a repeatable operating cadence.

• Days 1 to 30: review sync errors and canary records, verify every activity type, compare duplicate counts with the baseline, and confirm the integration identity remains authorized.
• Days 31 to 60: sample recently touched records, test associations and ownership, review new fields or options, and reconcile sales-tool activity with CRM reporting.
• Days 61 to 90: rerun the highest-risk checklist items, update rollback evidence, remove obsolete permissions or mappings, and set a quarterly audit owner.

Resolve edge cases before they become false alarms

Several behaviors look like failures even when the integration is following its documented model. Validate timing, object type, ownership, and matching rules before changing production mappings.

• Sync lag versus sync failure: wait for the documented read cycle before escalating, but do not use normal lag to excuse a missing error.
• Record existence versus association completeness: a Contact can arrive before its Company, Account, Deal, or Opportunity relationship refreshes.
• Existing duplicate versus new duplicate: tag the baseline so launch monitoring counts only records created after writes were enabled.
• Blank-field fill versus overwrite: a tool may be allowed to fill an empty field while being prohibited from changing a populated one.
• Read sync versus write sync: inbound data visibility does not prove outbound create and update behavior.

Stop or adapt when a red flag appears

Stop writes immediately for any event that can corrupt data, violate consent, or misroute ownership. Timing-related cases can wait only for the documented sync window.

Top five mistakes to avoid

• Connecting with a personal administrator account because it is faster.
• Calling the CRM a source of truth without assigning ownership per field.
• Testing only new records and skipping populated-field conflicts.
• Accepting activity in the sales tool while the CRM timeline stays incomplete.
• Enabling writes before the team has rehearsed the pause and rollback path.

Ready to test an outbound platform with documented Salesforce and HubSpot sync controls?Sign up for Unify.

Frequently asked questions

These answers cover the most common implementation and procurement questions about a CRM integration checklist. Each answer uses the same release standard: prove safe behavior before expanding scope.

What CRM integration checklist should I use before going live with a new sales tool?

Use an 18-point CRM integration checklist across six buckets: authentication and permissions, object mapping, field fidelity, activity logging, duplicate handling, and rollback planning. Do not launch until every item has a named owner, a passing test, and evidence stored with the deployment record. The same framework applies to Salesforce and HubSpot, but the canary records must reflect each CRM's object model.

How long should CRM integration testing take?

Testing should last until all 18 checks pass, not for an arbitrary number of days. Run at least one full read-sync cycle, then verify create, update, association, activity, duplicate, permission, and pause scenarios. If HubSpot associations are in scope, include its separate daily association refresh in the test window.

Should I test a CRM integration in a sandbox?

Use a sandbox whenever the integration can create or update production records, trigger automation, or change ownership. A sandbox is especially important for Salesforce organizations with validation rules, lead assignment rules, custom objects, or downstream workflows. Repeat a smaller canary test in production before broad rollout.

What is different about Salesforce and HubSpot integration testing?

Salesforce testing must resolve the Lead versus Contact and Account model, integration-user permissions, validation rules, and activity objects. HubSpot testing must resolve Contact and Company matching, property mappings, deal associations, and one-way versus two-way sync rules. The same six checklist buckets apply, but the test records must reflect each CRM's data model.

Which system should be the source of truth?

Assign a source of truth per field and object, not once for the entire stack. The CRM usually owns lifecycle stage, owner, opportunity or deal state, consent, and account relationships. An outbound platform may own sequence metadata and engagement details, but only the approved fields should write back.

When should I stop or roll back a CRM integration launch?

Pause writes immediately after an unexpected overwrite, duplicate creation, ownership change, opt-out violation, or activity association error. Preserve logs and the affected record IDs before changing mappings. Resume only after the same scenario passes in a controlled retest and the deployment owner signs off.

How does Unify integrate with Salesforce and HubSpot?

Unify supports bidirectional CRM sync for Salesforce and HubSpot, with configurable field mappings, default values, duplicate-prevention behavior, and separate controls for reading and writing. Unify documentation says read syncs are scheduled approximately every 15 minutes. Teams should still run the full 18-point checklist against their own schema and automation.

Glossary

Use these terms consistently in deployment notes, vendor demos, and incident reviews. Clear definitions prevent teams from using the same word for different integration behaviors.

• CRM integration: A connection that reads, creates, updates, or associates CRM data with another system.
• Bidirectional sync: A sync in which approved changes can flow from either connected system to the other under defined rules.
• Source of truth: The system authorized to win a conflict for a specific object or field.
• Field mapping: A rule that connects one system's field or property to its counterpart in another system.
• Default value: An approved fallback written when a required destination field has no source value.
• Canary test: A limited production-like test that exposes a small, known set of records to the new integration before broad release.
• Activity association: The relationship connecting an email, call, or task to the correct person, company, and opportunity or deal.
• Kill switch: The documented control used to stop integration writes without erasing valid historical records.
• Duplicate baseline: The known duplicate state measured before a new integration begins writing records.

Sources

All source pages below were verified live on August 31, 2026. Unify-specific behavior is linked to current product documentation or a named customer story.

• Unify: Salesforce integration guide
• Unify: Salesforce required permissions and settings
• Unify: How Salesforce bidirectional syncs work
• Unify: HubSpot integration guide
• Unify: How HubSpot bidirectional syncs work
• Unify customer story: Quo

About the author: Austin Hughes is Co-Founder and CEO of Unify, outbound AI for sellers where AI agents and reps work side by side, from finding the buyers already in market to reaching them with the right message. Before founding Unify, Austin led the growth team at Ramp, scaling it from 1 to 25+ people and building a product-led, experiment-driven GTM motion. Prior to Ramp, he worked at SoftBank Investment Advisers and Centerview Partners.