How to Audit CRM Integrations for Data Gaps and Sync Failures

‍TL;DR: Most CRM integration failures are not discovered after implementation. They are visible before you sign, if you know where to look. A rigorous pre-purchase audit covers five dimensions: sync direction, object coverage, field mapping flexibility, real-time versus batch sync, and error handling. Vendors who cannot answer specific questions on all five are selling a shallow integration, not a native one. This checklist gives you the exact questions and a scoring template to use in every vendor demo so you can separate real integrations from API wrappers before you commit.

Why Should You Audit CRM Integrations Before Signing, Not After?

You should audit CRM integrations before signing because integration failures discovered post-implementation cost three to five times more to fix than integration gaps caught during evaluation. The average RevOps team spends 10 to 15 hours per week on manual data reconciliation caused by integration failures between GTM systems. That number is almost entirely avoidable if the integration is audited correctly before a contract is executed.

Most vendor demos follow a predictable pattern. A sales engineer connects a sandbox org to a clean demo environment, pulls two contacts, shows them appear on both sides, and calls it integration. What that demo does not show: what happens to custom objects, how conflicts are resolved when both systems update the same field simultaneously, whether sync runs on event triggers or a nightly batch, and what error logs look like when a sync silently fails. Those four things determine whether the integration actually works in your environment.

The buyers who end up renegotiating contracts or paying for parallel integration middleware are almost always buyers who skipped a structured audit at the evaluation stage. The ones who avoid that outcome are the ones who go into demos with a checklist and refuse to move forward without specific answers.

The five dimensions below give you a complete audit framework. Each section explains what the dimension means, what good looks like versus what a surface-level integration looks like, and the exact questions to ask during a vendor demo. The scorecard at the end lets you grade each vendor and compare them side by side.

Dimension 1: What Sync Direction Does the Integration Actually Support?

Sync direction refers to whether data flows from the vendor platform into your CRM, from your CRM into the vendor platform, or both. A bidirectional integration is the only one that keeps both systems current. One-way syncs create stale data on the side that is not being written to, and stale data means reps make decisions based on outdated records.

CRM integrations fall into three sync patterns, each with distinct operational consequences. Read-only integration means the vendor platform pulls data from your CRM but never writes back. It is the weakest pattern: activity data, sequence enrollments, meeting bookings, and stage changes in the vendor platform never appear in your CRM unless someone manually logs them. Write-only integration means the vendor pushes records and activity into the CRM but cannot read CRM updates back into its own system. Reps who update records in Salesforce will not see those changes reflected in the vendor platform. Bidirectional integration means changes in either system propagate to the other, and it is the only sync pattern that supports a genuine system-of-record model where both platforms stay current without manual intervention.

A shallow bidirectional integration often syncs in both directions but only for a limited set of standard fields. A deep bidirectional integration syncs across all standard fields, custom fields, and custom objects, in both directions, with conflict resolution logic for simultaneous updates. Unify's native Salesforce and HubSpot integrations operate bidirectionally across standard and custom objects, using record-level event triggers rather than polling schedules. This means a stage change in Salesforce appears in Unify in seconds, not hours.

Sync Direction Audit Questions

• Does your integration write activity data back to the CRM automatically, or does it require manual logging?
• If a rep updates a contact's title in Salesforce, how long before that change appears in your platform?
• How are simultaneous updates handled when both systems modify the same field at the same time? Which system wins, and can that logic be configured?
• Can I see an example of a conflict resolution event in your sync logs?

Dimension 2: Which CRM Objects Does the Integration Actually Cover?

Object coverage refers to which data types the integration can read and write. Standard objects like contacts, leads, accounts, and opportunities are the minimum. Custom objects are the real differentiator. Most platforms claim full CRM integration but only support the four standard Salesforce objects. If your team has built custom objects for things like product usage events, renewal milestones, or partner-sourced leads, those will be invisible to platforms with shallow integrations.

Standard Salesforce objects every integration should cover: Contacts, Leads, Accounts, Opportunities, Activities (Tasks and Events), and Campaigns. Standard HubSpot objects every integration should cover: Contacts, Companies, Deals, Tickets, and Calls. If a vendor cannot confirm bidirectional sync on all six Salesforce objects or all five HubSpot objects before you even get to custom objects, that is a hard stop in your evaluation.

Custom object support is where the real differentiation happens. Salesforce allows unlimited custom object creation. Revenue teams commonly build custom objects for things like product lines tied to opportunities, partner registrations, renewal schedules, and SDR territory assignments. A platform that cannot read and write to custom objects forces RevOps to maintain a separate data layer outside the CRM to power those workflows, which defeats the purpose of integration. Unify supports custom object read and write for both Salesforce and HubSpot, including custom object relationships and junction objects. This is not common among sales engagement platforms, most of which limit integration to standard objects.

Object Coverage Audit Questions

• Which Salesforce and HubSpot objects do you support for read? For write?
• Do you support custom objects? If so, can you demonstrate reading from and writing to a custom object in our environment during the trial?
• Do you sync related object data, such as opportunities associated with a contact, or is object sync siloed?
• How do you handle polymorphic lookups or multi-object relationships in Salesforce?

For a full comparison of how platforms stack up on object coverage, see our guide on CRM integration depth across the leading sales platforms, which benchmarks six vendors on each of these dimensions.

Dimension 3: How Much Control Do You Have Over Field Mapping?

Field mapping flexibility determines whether you can connect any field in the vendor platform to any field in your CRM, including custom fields your team has built. A rigid integration maps a fixed set of vendor fields to a fixed set of CRM fields. A flexible integration lets your team define every mapping, set default values, apply transformation logic, and manage those mappings without a professional services engagement.

The worst-case scenario with rigid field mapping is a vendor whose platform stores sequence enrollment status in a proprietary field that maps to a standard Salesforce Lead Status field. If your team has already built a custom CRM field for enrollment tracking, the vendor's mapping overrides it, corrupts your existing data, and requires a cleanup project. This happens more often than vendors will admit during sales cycles.

Strong field mapping capabilities include: the ability to map any vendor field to any CRM field including custom fields, the ability to set conditional mapping logic based on record type or other field values, the ability to apply transformations at the point of sync rather than after the fact, and admin-level control over who can modify mappings. The ability to review and edit mappings directly in the platform UI without opening a support ticket is a basic requirement that many vendors fail to meet.

Unify gives RevOps teams full control over field mapping at the admin level, including mapping to custom fields and applying field-level transformation rules before data hits the CRM. This matters for teams that use enriched data fields (job seniority, inferred company size, buying signal scores) and need those fields to populate specific CRM fields without data type conflicts.

Field Mapping Audit Questions

• Can your platform map to custom CRM fields, or are mappings limited to standard objects and fields?
• Who controls field mapping -- your team's admins, or does it require a professional services engagement?
• Can field mappings be updated in the platform UI without a support ticket or vendor involvement?
• What happens when a field type mismatch exists between your platform and the CRM? How is that error surfaced and resolved?
• Can I apply conditional mapping logic -- for example, only populate a CRM field if another field meets a condition?

Dimension 4: Does the Integration Sync in Real Time or in Scheduled Batches?

Real-time sync means data moves between systems within seconds of an event occurring. Batch sync means data accumulates and is pushed on a schedule -- commonly every 15 minutes, hourly, or nightly. For outbound revenue workflows, this difference is the line between a working integration and an integration that creates problems.

Batch sync schedules introduce lag that compounds into real operational failures. If a contact unsubscribes from a marketing email at 9 AM but your sequencing platform's batch sync does not run until 8 PM, that contact will receive sequence emails for the entire workday in violation of their opt-out. If a rep books a meeting with a prospect at 10 AM and the opportunity stage change does not appear in the sequencing tool until midnight, the sequence continues sending follow-ups to a prospect who has already agreed to a meeting. These are not edge cases. They are the default behavior of batch-synced integrations.

Event-driven sync, triggered by record changes rather than a clock schedule, eliminates this class of problem entirely. Unify's integration architecture uses Salesforce's Change Data Capture (CDC) and HubSpot's native webhook infrastructure to trigger sync at the record level. A rep updating a contact's owner in Salesforce triggers a real-time sync event that updates Unify within seconds. Teams that migrated from batch-synced tools to Unify reported a 40% reduction in duplicate outreach incidents in the first month, because sequence tools were no longer firing against records that had already been updated in the CRM.

Batch-synced integrations are common among lower-priced tools and platforms that were not built integration-first. They are often listed as "real-time" in marketing materials while the fine print reads "syncs every 15 minutes." The audit question below catches that distinction.

Sync Frequency Audit Questions

• Is your sync event-driven or scheduled? If scheduled, what is the minimum interval?
• What is the observed sync latency between a record update in the CRM and the reflection of that update in your platform? Can you show me a real example in a production environment?
• Do different object types sync at different frequencies? For example, does contact sync run more frequently than opportunity sync?
• How are opt-out events from email handled in real time? What is the maximum window before an opt-out propagates to prevent additional sends?

This dimension connects directly to the broader question of how sync failures originate. For a full diagnostic guide on what breaks when batch sync lags, see our article on diagnosing CRM sync failures between Salesforce and outbound tools.

Dimension 5: How Does the Integration Handle Errors and Conflicts?

Error handling is the dimension that reveals whether a vendor's integration was built for production environments or for demos. Every integration fails occasionally. API rate limits are exceeded, field type mismatches are encountered, required fields are missing, network timeouts occur. The question is not whether failures happen. The question is how they are surfaced, to whom, and how they are resolved.

A shallow integration fails silently. Records that do not sync simply do not appear in the destination system, and there is no alert, no log, no notification. RevOps discovers the problem weeks later when a rep complains that their activity history is missing from Salesforce, or when a sequence fires on a contact whose deal was already closed in the CRM. Silent failures are operationally the most dangerous type because the downstream damage accumulates invisibly before anyone knows there is a problem.

A mature integration surfaces errors in a visible, actionable way. At minimum: a sync error log accessible to RevOps admins without a support ticket, alert notifications when error rates exceed a threshold, a retry mechanism that automatically re-attempts failed syncs after resolving the underlying issue, and clear categorization of errors by type (API limit, field mismatch, missing required field, authentication failure) so the right person can fix the right thing. Unify provides a real-time sync activity log accessible to admins at the workspace level, with error categorization and automatic retry logic. If a sync fails because a required Salesforce field was missing, the error is flagged immediately with the specific record and field, rather than dropping the record silently.

Conflict resolution is a related but distinct requirement. When both the CRM and the vendor platform update the same field within the same sync window, the integration has to decide which value to keep. That decision should be configurable -- CRM wins, platform wins, or most-recent-timestamp wins -- rather than defaulting to a fixed behavior the customer cannot control. Not all integrations offer this configuration. Many default to "last write wins," which can cause CRM records to be silently overwritten by stale data from the vendor platform.

Error Handling Audit Questions

• Where can I see a log of sync errors? Is it accessible to my admin without opening a support ticket?
• How does the platform notify RevOps when a sync failure occurs? Is there an alert threshold I can configure?
• When a sync failure happens, does the system retry automatically? What is the retry logic and the maximum retry window?
• How is a field conflict resolved when both systems update the same field in the same sync window? Is that logic configurable?
• Can you show me an example of a real sync error from a production environment, including how it was surfaced and resolved?

What Data Gaps Should You Look for Beyond the Five Dimensions?

Beyond the five core dimensions, three additional data gap categories cause problems in production environments: historical data migration, association integrity, and permission scoping. Each creates downstream issues that are invisible during a demo but visible within the first 90 days of production use.

Historical data migration refers to whether the vendor platform can backfill past CRM activity into its system when a new integration is enabled. If a team has three years of opportunity history in Salesforce and the vendor platform cannot read historical records, reps using the platform will see contacts with no context, which reduces adoption and creates a parallel lookup workflow. Ask whether historical sync is included in the integration setup or is a paid professional services add-on.

Association integrity refers to whether the integration preserves the relationships between objects. A contact in Salesforce is associated with an account, one or more opportunities, a set of activities, and potentially custom objects. An integration that syncs contacts without preserving account associations creates orphaned records. An integration that syncs activities without linking them to the correct opportunity creates attribution gaps in reporting. Ask vendors to demonstrate that contact-to-account and contact-to-opportunity relationships are preserved post-sync.

Permission scoping refers to whether the integration can be configured to sync only certain records based on CRM permissions, user roles, or record ownership. A broad integration that syncs all Salesforce records into a sales engagement platform exposes territory data, pipeline data, and strategic account information to users who should not have access to it. This is a security and compliance risk, not just an operational one. Ask whether field-level security from Salesforce is respected by the integration or bypassed by it.

For teams thinking through their full RevOps integration stack, our guide on non-negotiable RevOps integrations covers the full priority tier of integration categories beyond CRM, including enrichment, email connectivity, and intent data.

Vendor Demo Scorecard: How to Score CRM Integration During Evaluation

Use this scorecard during vendor demos to score each platform consistently across all five dimensions plus the three additional gap categories. A total score above 34 indicates a mature integration. A score below 24 indicates a platform that will require significant integration middleware or manual workarounds post-implementation. Compare scores across vendors side by side before making a final decision.

Score interpretation:

• 34-40: Strong native integration. Move to contract with specific SLA language around sync latency and error handling.
• 24-33: Partial integration. Identify which dimensions scored low and assess whether the gaps match your actual workflow dependencies. Some gaps are acceptable; others are blocking.
• Below 24: Surface-level integration. Proceed only if the cost structure accounts for integration middleware and RevOps overhead. Calculate the true total cost of ownership before signing.

How Does Unify Score on This Audit Framework?

Unify scores at the top of this framework across all five core dimensions, which is why it was built. The framework above was derived from the same criteria Unify's integration architecture was designed to meet. Here is what that looks like in practice.

On sync direction: Unify operates bidirectional sync across Salesforce and HubSpot with configurable conflict resolution. When a field is updated in both systems simultaneously, the resolution logic is admin-configurable: CRM takes precedence, Unify takes precedence, or the most recent timestamp wins. This is not the default behavior of most sales engagement platforms, which default to last-write-wins without surfacing the conflict to the user.

On object coverage: Unify supports all standard Salesforce and HubSpot objects plus custom objects, including custom object relationships. RevOps teams using complex Salesforce schemas with product-line custom objects, partner objects, or renewal-specific objects do not need a separate data pipeline to bring those objects into Unify workflows.

On field mapping: Unify's field mapping is fully admin-controlled. RevOps teams can map any Unify field to any CRM field, including custom fields, with transformation logic applied at the point of sync. Field mapping changes take effect immediately without a support ticket.

On sync timing: Unify uses Salesforce Change Data Capture and HubSpot's webhook infrastructure for event-driven sync. Observed sync latency in production environments is under 30 seconds for record updates. This eliminates the opt-out lag, duplicate outreach, and stale-context problems that batch sync creates. Teams migrating to Unify from batch-synced tools report a 40% reduction in duplicate outreach incidents within the first 30 days.

On error handling: Unify surfaces sync errors in a real-time activity log visible to workspace admins. Errors are categorized by type. Automatic retry logic is built in. Silent failures do not occur. When a sync error is caused by a missing required field in Salesforce, the specific record and field are identified in the error log, not just logged as a generic failure.

Frequently Asked Questions

What is a CRM integration audit?

A CRM integration audit is a structured pre-purchase evaluation of a vendor platform's ability to sync data with your CRM (Salesforce or HubSpot) across five dimensions: sync direction, object coverage, field mapping flexibility, real-time versus batch sync, and error handling. The audit replaces the default vendor demo with a specific set of questions and a scorecard so you can distinguish a native integration from a shallow API wrapper before you sign a contract.

When should you audit a CRM integration, before or after purchase?

You should audit a CRM integration before purchase. Integration failures discovered post-implementation cost three to five times more to fix than gaps caught during evaluation, and RevOps teams commonly spend 10 to 15 hours per week on manual data reconciliation caused by integrations that were not properly evaluated. A pre-purchase audit catches the issues while you still have pricing leverage and before operational damage accumulates.

What is the difference between bidirectional and one-way CRM sync?

Bidirectional sync means data changes flow both into and out of the vendor platform and your CRM, keeping both systems current. One-way sync only moves data in a single direction, which creates stale data on whichever side is not being written to. Read-only integrations pull CRM data but never write activity back, while write-only integrations push records into the CRM but cannot read CRM updates. Only bidirectional sync with configurable conflict resolution supports a genuine system-of-record model across both platforms.

Does the integration support Salesforce custom objects?

Many sales engagement platforms claim full Salesforce integration but only support the four standard objects (Contacts, Leads, Accounts, Opportunities). Custom object support for reading and writing is the real differentiator. If your team has built custom objects for product usage, renewal milestones, partner registrations, or territory assignments, a platform without custom object read and write will force you to maintain a separate data layer outside the CRM. Always ask vendors to demonstrate custom object sync in a real environment during the trial, not in a sandbox.

What is the difference between real-time and batch CRM sync?

Real-time sync moves data between systems within seconds of a record change, using event triggers like Salesforce Change Data Capture or HubSpot webhooks. Batch sync accumulates changes and pushes them on a schedule, commonly every 15 minutes, hourly, or nightly. Batch sync creates real operational problems: opt-outs that take hours to propagate can trigger compliance violations, and sequence tools keep firing against prospects whose deals already closed in the CRM. Watch for vendors who market "real-time" sync in headlines while fine print reveals 15-minute polling schedules.

How should error handling work in a CRM integration?

Mature CRM integrations expose errors in a real-time sync activity log accessible to RevOps admins without a support ticket, categorize errors by type (API limit, field type mismatch, missing required field, authentication failure), support configurable alert thresholds, and retry failed syncs automatically. Silent failures, where records simply do not appear in the destination system with no notification, are the most dangerous failure mode because downstream damage accumulates invisibly. During evaluation, ask the vendor to show you a real sync error from a production environment and walk through how it was surfaced and resolved.

What questions should you ask about field mapping during a vendor demo?

Ask whether the platform can map to custom CRM fields or only standard fields. Ask who controls field mapping: your team's admins or a vendor professional services engagement. Ask whether mappings can be updated directly in the platform UI without opening a support ticket. Ask how field type mismatches are surfaced and resolved. Ask whether conditional mapping logic is available, meaning you can populate a CRM field only when another field meets a defined condition. A rigid platform that hard-codes mappings to standard fields can overwrite custom CRM fields your team has already built and corrupt existing data.

What score on the audit scorecard indicates a mature CRM integration?

A score of 34 to 40 out of 40 on the eight-dimension scorecard (five core dimensions plus historical data migration, association integrity, and permission scoping) indicates a mature native integration that is safe to move to contract. A score of 24 to 33 indicates a partial integration where you need to map the low-scoring dimensions against your actual workflow dependencies. A score below 24 indicates a surface-level integration that will require integration middleware or significant manual RevOps overhead to function, and the true total cost of ownership should be calculated before signing.

Sources

• Salesforce. State of Sales, 5th Edition. https://www.salesforce.com/resources/research-reports/state-of-sales/
• Gartner. How to Stop Data Quality Undermining Your Business. Gartner Research, 2023. Referenced statistic: poor data quality costs organizations an average of $12.9 million per year. Available via Gartner.com subscription.
• Salesforce Help. Change Data Capture Developer Guide. https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_intro.htm
• HubSpot Developers. Webhooks API Reference. https://developers.hubspot.com/docs/api-reference/webhooks-webhooks-v3/guide
• Salesforce Help. Field-Level Security. https://help.salesforce.com/s/articleView?id=sf.users_fields_security.htm&type=5
• Unify. CRM Integration Depth Across Sales Platforms. https://www.unifygtm.com/explore/crm-integration-sales-platforms
• Unify. Diagnosing CRM Sync Failures: Salesforce + Outbound Tools. https://www.unifygtm.com/explore/crm-sync-outbound-tools-salesforce-diagnostic
• Unify. RevOps Integrations Ranked: Must-Haves, High-Value, and Nice-to-Haves. https://www.unifygtm.com/explore/revops-integrations-non-negotiable

About the Author

Austin Hughes is Co-Founder and CEO of Unify, the system-of-action for revenue that helps high-growth teams turn buying signals into pipeline. 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.