Over 600 Salesforce Architect respondents in the latest Salesforce Ben study, diving deep into one of the most critical roles within the revenue lifecycle.
A snapshot from page 23 reveals a broad set of core integrations that Salesforce leaders invest in. Why do you need to study these?
❗ No one individual tool can deliver what an organization with hundreds or thousands of people requires (and half the architects are employed in organizations of 5,000+ employees). I can’t stress that enough for the broader SaaS realm of “this tool will save your life”, without a deeper consideration of the 4 pillars of RevOps:
– People
– Data
– Processes
– Technologies
The last one alone clearly points to dozens and dozens of tools and systems interconnected to deliver strong reporting for boardrooms, executive teams, and informing quarterly planning and BDR KPIs.
♻️ DevriX has integrated many of these together: Salesforce, HubSpot, WordPress, NetSuite, QuickBooks, Workday, Avalara, Databricks, Google BigQuery, Redshift, Marketo, Pardot, Outreach.io, MailChimp, Zoominfo, 6sense, Twilio, Aircall, Slack, Teams, Zoom, Tableau, Looker, Grafana, Dynamics 365 come to mind from current contracts in our portfolio.
The underlying data layers, especially at the bottom of this pyramid, act as the sources of truth for growing organizations redefining their revenue lifecycle modeling with upgraded corporate and product positioning and AI-augmented teams in parallel.
Well done, Ben McCarthy, Julia Solis, and team for making this possible, and thank you, Odaseva, for sponsoring the survey.
When the Deal Clock Starts: Revenue Stack Diligence for PE Buyers and Portfolio Operators
The integration map above looks complex enough when you’re running a single organization. Now imagine acquiring one. Or three. Or folding a platform acquisition into a portfolio company that already runs its own Salesforce instance alongside a legacy CRM the founder never fully migrated away from.
This is where IT due diligence shifts from a compliance checkbox to a value-creation lever. The revenue technology stack, and specifically how cleanly it can be rationalized post-close, often determines whether a deal’s projected synergies materialize in 18 months or 36.
The Duplicate System Problem Nobody Budgets For
Technical due diligence teams routinely flag obvious infrastructure risks: outdated servers, unpatched security vulnerabilities, single points of failure. What gets less attention, until integration planning begins, is the quieter problem of system overlap.
A target company running Salesforce as its CRM of record might also maintain partial customer data in HubSpot (from a marketing experiment two years ago), a parallel pipeline in a spreadsheet the VP of Sales trusts more, and billing records that live in NetSuite but sync inconsistently. None of these qualify as a “finding” in most diligence frameworks. All of them create integration drag.
The practical cost shows up in three places:
- Redundant licensing fees that persist for 12 to 24 months while teams “figure out” the consolidation plan
- Data reconciliation labor as finance teams manually cross-check numbers that should match but don’t
- Integration failures when APIs built for one system’s data model break against another’s field conventions
A proper technology due diligence checklist should inventory not just what systems exist, but which ones are actually authoritative for each data domain and which represent institutional muscle memory that the organization never formally deprecated.
CRM Entity Mapping: The Foundation of Post-Close Rationalization
CRM consolidation sounds straightforward until you open the hood. The acquiring company calls them “Accounts.” The target calls them “Organizations.” Both have a field labeled “Customer Type,” but one uses a dropdown with six options and the other uses a free-text field with 847 unique entries, including spelling variations.
This is not a Salesforce problem or a HubSpot problem. It’s a data governance problem that happens to manifest in CRM objects.
Before any M&A IT integration can proceed, operators need a clear entity map that answers:
- What constitutes a “customer” in each system, and do those definitions align?
- How do both organizations handle the distinction between billing entities and operating entities?
- Where does contact ownership live, and how will that translate when sales territories merge?
- Which custom objects carry business logic that downstream systems depend on?
The M&A integration playbook we use with portfolio companies starts with this mapping exercise precisely because skipping it creates compound problems. Every automation, every report, every dashboard that references misaligned entities will either break or produce misleading outputs.
Integration Risk: What the Architecture Diagrams Hide
Most targets can produce a system architecture diagram during diligence. Few can accurately describe what happens when one of those integration arrows fails.
Consider a revenue stack where Salesforce pushes closed-won opportunities to NetSuite for invoicing, which then syncs payment status back to update the customer record. That’s a standard pattern. But what happens when the sync fails midway? Does someone get notified? Is there a retry mechanism? Can finance identify which records are stuck in limbo?
Integration risk assessment should cover:
- Failure handling: What breaks visibly versus what fails silently?
- Data latency: How stale can data get before it affects decisions?
- Dependency chains: Which integrations are downstream of others, creating cascade risk?
- Documentation state: Could a new engineer understand and maintain these integrations within 30 days?
Organizations with mature business process management practices tend to have answers to these questions. Organizations that grew fast and bolted on systems opportunistically often don’t realize they lack answers until something breaks during the transition.
A Working Framework: Revenue Stack Diligence Scope
The table below outlines the core areas we assess when conducting digital due diligence on revenue infrastructure. This is illustrative rather than exhaustive, but it captures the categories that most frequently surface integration risk or hidden costs.
| Diligence Area | Key Questions | Common Red Flags |
|---|---|---|
| System Inventory | Which tools touch customer or revenue data? Which are authoritative? | Multiple systems storing overlapping data with no clear hierarchy |
| Data Governance | Who owns data definitions? How are changes to schemas approved? | No documentation; field definitions exist only in tribal knowledge |
| Entity Alignment | How do account, contact, and opportunity structures map across systems? | Custom objects with hardcoded business logic; inconsistent ID conventions |
| Integration Architecture | What connects to what? Through which middleware or direct APIs? | Point-to-point integrations with no error handling or logging |
| Reporting Dependencies | Which dashboards drive executive decisions? What data sources feed them? | Reports built on deprecated fields or manual data entry workarounds |
| License and Contract Exposure | What are the renewal dates, terms, and termination provisions? | Multi-year commitments signed shortly before the transaction |
| Consolidation Feasibility | Can the target’s stack fold into the acquirer’s, or vice versa? | Heavy customization that would require rebuilding rather than migrating |
Post-Close Rationalization: The 100-Day Reality
Deal models often assume system rationalization happens cleanly in the first year. Experienced operators know better. CRM consolidation alone typically spans 6 to 18 months when done properly, longer when data quality issues surface mid-migration.
The most successful post-close technology integrations share a few characteristics:
- They establish a single authoritative system for each data domain before attempting to merge anything
- They run parallel operations long enough to validate that the consolidated system produces trustworthy outputs
- They sequence the work so that revenue-critical processes migrate last, after lower-risk systems prove the integration approach
- They budget for cleanup that the diligence process identified but didn’t fully scope
The stack complexity shown at the top of this page, with dozens of systems feeding into centralized data layers, represents the mature end state. Getting there after an acquisition requires acknowledging that you’re often starting with two or more partial implementations that evolved independently and now need to become one coherent architecture.
That’s not a technology project. It’s an operating transformation that happens to involve technology.
