A field mapping can be changed in an afternoon. The decision about which object a lead becomes, what a lifecycle stage means, and which system owns the customer identity — those get embedded in reports, automations and habits, and they are expensive to revisit. This is the layer to get right first.
Trusted by 500+ organizations — including B2B SaaS and technology companies running marketing in HubSpot and revenue in Salesforce with Twopir Consulting.
Revenue Architecture & Design
Architectural debt is not built by careless people. It is built by sensible people solving the problem in front of them without a model to fit it into. These are the six that cost the most to unwind.
Whether a HubSpot contact becomes a Salesforce Lead or goes straight to Contact shapes routing, reporting, conversion metrics and duplicate behaviour. It is frequently decided by whoever clicked first, then inherited for years.
Without a documented owner per field, both systems author everything and the last write wins. The last write is usually an automation nobody remembers building.
Marketing's MQL and sales' qualified describe different populations. Until the definitions are written down and agreed, funnel reporting measures the disagreement rather than the funnel.
The connector matches on email address alone. Without a deliberate identity model — Salesforce IDs surfaced, create dates visible, merge order defined — duplicates are structural rather than accidental.
No sandbox, no change control, no record of why. Two years later nobody can safely remove anything because nobody knows what depends on it.
Reports built ad hoc in each system, then reconciled by hand every quarter. The reconciliation is not a reporting problem — it is the absence of an agreed measurement model.
Salesforce HubSpot architecture is the set of decisions that determine what a record is, who owns each piece of information about it, what the funnel stages mean, how the same human is recognised across two databases, how changes are made safely, and how the two systems arrive at the same number. Everything else — field mappings, workflows, reports — is downstream of those six.
The reason to separate architecture from configuration is cost of change. A sync direction can be corrected in minutes. An object model choice propagates into conversion reporting, routing logic, dashboards, quotas and years of historical data, and revisiting it means reinterpreting the history as well as the schema. Configuration is reversible. Architecture is what you live with.
A workable reference architecture separates three layers that can be tested and owned independently: an enrichment layer that adds firmographic and intent data before records are routed; a sync layer that moves data between the platforms under explicit rules; and an automation layer that acts on records — routing, scoring, rollups, alerting. Collapsing them into one undifferentiated set of workflows is why so many stacks cannot be changed safely.
The most consequential single artefact is the source-of-truth matrix: every field, its authoritative system, its sync direction, and the rule that applies when both sides change it. It is unglamorous and it is the document that determines whether the stack is still coherent in three years. HubSpot's own integration settings documentation describes the mechanics; the matrix is where the decisions live.
Twopir Consulting designs this layer as a Salesforce Partner and a HubSpot Partner, for growing and mid-market companies solving complex CRM, integration and business system challenges, and for enterprise organisations at higher volume. For what the architecture governs in practice, see Salesforce HubSpot data sync; if you want the architecture assessed rather than designed from scratch, that is an advisory engagement. Both sit under our integration services.
Sequencing architecture work by cost of reversal is the most useful prioritisation we know. The expensive decisions are not always the ones that feel urgent.
| Decision | What it determines | Cost to change later |
|---|---|---|
| Object model — lead object or contact-only | Whether a HubSpot contact becomes a Salesforce Lead or a Contact, and therefore how conversion, routing and duplicate behaviour work. | Very high — conversion history, reports and quota structures all assume the current answer. |
| Source of truth — per field | Which system authors each field, and what happens when both change it. | Moderate — the rules can be changed, but data already corrupted by the wrong answer needs remediation. |
| Lifecycle and funnel model | What each stage means, who moves a record between stages, and where the handoffs sit. | High — every historical funnel report is measured against the old definitions. |
| Identity and matching | How the same person and the same company are recognised across both systems. | High — duplicates created under a weak model must be merged in the right order, and merge order matters. |
| Environment and change control | Where changes are built and tested, and who approves them. | Low to adopt, high to skip — cheap to introduce, and its absence is what caused most of the other debt. |
| Reporting and attribution model | Which numbers both teams agree to, and how campaign influence survives conversion. | Moderate — forward-looking fixes are straightforward; historical attribution usually cannot be reconstructed. |
Each of these is an artefact your team keeps and maintains. An architecture that exists only as settings in two admin panels is not an architecture.
What a record is in each system and how the two correspond — decided against how you actually sell rather than against the default configuration.
The central artefact: every field with a named authoritative system, a direction, a conflict rule and the reasoning behind each.
Stage definitions both marketing and sales will sign, with the handoff criteria that make them operational rather than aspirational.
How records are recognised, where changes are built, and who signs them off — the layer that determines whether the architecture survives contact with a busy quarter.
Architecture derived from platform features produces a stack that reflects the software's assumptions rather than the company's. The order matters.
How you actually sell — segments, motions, handoffs, teams and the reporting leadership genuinely acts on. Platform capability is deliberately not in scope yet.
Editions, API limits, record volume and growth, compliance obligations and the capacity of the team who will run this afterwards. Architecture ignoring capacity is theory.
Object model, source-of-truth matrix, lifecycle definitions and identity strategy — drafted, then walked through with the marketing, sales and revenue operations owners together.
The model is tested against real scenarios from your pipeline, including the awkward ones: the reseller, the multi-entity account, the customer who churns and returns.
The artefacts handed over with a named owner, a change-control path and a review cadence — because an architecture with no owner degrades into whatever gets configured next.
Very few revenue stacks are two systems. Each addition is an architectural decision about ownership, not just a connection.
Firmographic and intent data appended before routing. Architecturally the question is which system owns the enriched attribute and whether it may be overwritten by a human.
Meeting booking and assignment tools write ownership and outcome data. Ownership fields have one authoring system, and it is rarely the scheduling tool.
Driven from opportunity data. The architectural decision is whether generated document status is a CRM field or lives in the document system.
Where transformation or volume exceeds the native connector. The boundary decision is which flows belong in the connector and which belong in middleware — mixing them arbitrarily is what makes troubleshooting impossible.
Usage, subscription and payment events joined to the account. These are almost always read-only into the CRM, and saying so explicitly prevents a lot of argument.
Both platforms landed in one place so measurement does not depend on either system arbitrating the other. Frequently the correct answer to a reconciliation problem.
Dedupe and normalisation running continuously. Architecturally it needs a defined position in the write order, or it fights the sync.
Consent state and data subject requests have to resolve consistently across both systems, which makes consent one of the fields whose ownership must be unambiguous.
The engagement below was rebuilt on exactly the layer separation described on this page: enrichment, sync and automation, each with a defined owner after go-live.
The diagnostic surfaced three problems we did not even know we had. By the time we saw the field mapping spec, it was obvious why the previous sync had been silently corrupting data for months. What impressed us most was that every decision was documented — we were not handed a black box. We owned the system at handover.
A three-layer architecture — enrichment, sync and automation — with a field ownership matrix and documented escalation paths delivered at project close.
Design without operational experience produces models that are coherent on paper and unmaintainable in a busy quarter.
How you sell comes first; platform capability comes second. Architecture derived from features reflects the software's assumptions rather than yours.
A matrix that says which system owns a field is useful. One that says why is what lets the next person change it safely.
An architecture that needs a full-time administrator you do not have is not an architecture, it is a proposal for a hire.
Enrichment, sync and automation as three testable layers with distinct owners — so a change in one does not require re-validating all three.
Resellers, multi-entity accounts, returning customers. Models fail at the edges, and the edges are where your revenue team spends its time.
It depends on whether you genuinely run a lead-qualification process with a distinct owner and a conversion event. If unqualified inbound is worked by a team separate from account executives, the Lead object earns its complexity and gives you conversion metrics that matter. If everything is worked by the same team against known accounts, a contact-only model is simpler and removes a whole class of duplicate and conversion problems. The wrong answer here is the most expensive architectural mistake available, because conversion history and reporting both assume it.
It is a document listing every synced field with its authoritative system, sync direction, conflict rule and the reasoning behind each. It matters because without it every field effectively has two owners, and the resolution is whichever automation wrote last. It is also the artefact that survives staff turnover: an architecture that lives in one administrator's memory is one resignation away from being undocumented.
Define the stages once, in language both teams accept, then represent them in both systems rather than mapping each system's native field to the other's. In practice that usually means a dedicated lifecycle picklist on the Salesforce side carrying the same values as HubSpot's lifecycle stage, with Salesforce lead status left as a separate sales-owned field. Mapping lifecycle stage directly to lead status conflates funnel position with current activity, and neither survives. Note that automatic lifecycle transitions will not move a stage backwards, which the model has to account for.
Yes, and the absence of one is a reliable predictor of the problems we get called in to fix. Sync behaviour, validation-rule interactions and picklist parity all need to be proven against representative data before they touch production, and failure behaviour especially needs somewhere safe to be observed. A dedicated integration user is the companion practice — it isolates sync activity from individual logins and makes troubleshooting and permission management tractable.
When you need transformation the connector cannot express, when volume or latency exceeds what it comfortably handles, when a third system needs to participate in the same flow, or when your matching requirements go beyond email address. The decision should follow a requirement, not a preference — middleware adds a component that needs its own monitoring, ownership and failure handling, and stacks that adopted it without a clear reason usually cannot explain which flows live where.
Name an owner, require changes to go through a defined path, and schedule a review. Most degradation is not dramatic — it is a field added directly in production to solve something urgent, repeated forty times over two years. Change control does not have to be heavy; it has to exist and have someone's name on it.
Yes, and it is a common starting point. We assess the existing model against how the business actually operates now, identify where the two have diverged, and produce a target state with a sequenced path to it. In many cases the finding is that the architecture was sound for the business three years ago and the business has changed — which is a different and much cheaper problem than a bad original design.
Unmade architectural decisions do not stay unmade — they get made by default, by whoever configures next. Deciding deliberately is cheaper.
Salesforce Partner · HubSpot Partner · Serving US, Canada, UK, UAE, Australia & New Zealand
