HubSpot Data, BI and Middleware Integrations
Most reporting problems presented as tool problems are layer problems. A question is being asked of the CRM that the CRM cannot answer, not because its reporting is weak but because the question spans systems the CRM cannot see.
Knowing which layer a question belongs to is most of the skill in this category, and it decides whether the answer is a HubSpot report, a warehouse query or a middleware job.
18 systems in this category.
Which layer the question belongs to
HubSpot reporting is strong within one object graph and is bounded by it. Asked to join across systems, or to look at a state that existed at a point in the past, it reaches a limit that no configuration removes.
A warehouse answers both, and costs a pipeline, a schema and somebody to maintain them. That cost is worth paying once there is a question the business asks repeatedly and cannot answer, and not before, because a warehouse built on incomplete data models incomplete data faithfully.
The commonest reporting defect has nothing to do with layers. Joining two one-to-many relationships in a single report multiplies rows, and the resulting total is larger than reality in a way that looks plausible.
The layers a revenue question can be answered at, and what each one costs
How joining two one-to-many relationships inflates a total that still looks right
HubSpot Middleware: Native Sync, an Integration Platform or Custom Code
HubSpot's native option is data sync. Once a supported app is connected, records sync one way or both ways, and a chosen default app wins when values disagree. After the initial sync, each change arrives within ten minutes (HubSpot). Data sync runs on every HubSpot plan; custom field mappings need Data Hub Starter, Professional or Enterprise (HubSpot). Where a data sync app exists for the system and its default object pairs fit the business, it adds no code to maintain, and it is assessed first.
An integration platform such as Workato, Make or Tray.ai covers a system with no data sync app, or a flow that transforms or routes records on the way across. It adds a subscription, and flows that someone owns, monitors and corrects when either system's API changes.
Custom middleware is code written for the two systems in question, with its source and documentation held by the client. It is warranted where volume, a composite identity rule such as name plus subsidiary, or a custody requirement exceeds what platform connectors express. Every API change on either side then becomes work for whoever owns the code. Custom HubSpot development covers that case once the native and platform options have been assessed and rejected on the record.
Systems in this category
CRM data landed in the warehouse with a stated grain and refresh.
Modelled tables read back into HubSpot as properties, not as dashboards.
Scores and segments written to named fields with a documented refresh.
Tiles embedded where the work happens rather than in a separate portal.
Reporting built on a defined semantic layer instead of raw exports.
Metric definitions agreed once and reused on both sides.
Identity resolution decided before events start flowing.
Managed extraction with schema drift treated as a scheduled task.
Self-hosted extraction where data residency is a requirement.
Metric logic held in one tested place rather than in each report.
Suited to edge automation; not to a load-bearing connection.
Scenario ownership and error handling agreed at design time.
Recipes with centralised observability rather than per-flow logging.
Governed workflows where the estate has outgrown point automation.
The spreadsheet that became a system, mapped properly on the way in.
Recognised as a system of record where it genuinely is one.
Document and export custody inside an account the client controls.
Middleware run in the client's own tenancy where custody matters.
Related illustrative case studies
Illustrative case studies in this category that are not single-system integrations, and so do not appear in the directory above.
Fixed-scope offers
Where the work in this category is bounded enough to price up front.
Common Questions
Frequently Asked Questions
When a question the business asks repeatedly cannot be answered inside any single system, and the cost of not answering it exceeds the cost of the pipeline. Before that point a warehouse adds maintenance without adding an answer, and building one on data that is not yet clean models the mess accurately.
Different rather than better. A native connector is cheaper and is maintained by the vendor. An iPaaS platform earns its cost where logic sits between the systems: a transformation, a conditional route, or a third system in the path. Using one where a native connector would serve adds a dependency and a subscription.
Usually a definition rather than a defect. The two are filtering differently, using different date fields, or one is counting records that the other deduplicated. Reconciling them means agreeing a definition in writing, and that agreement is the deliverable rather than the report.
Further reading
Long-form already published on the argument this category turns on.
- HubSpot Attribution ReportingThe models, and the coverage none of them has.
- RevOps in Oil and GasA sector where the operational system outranks the CRM.
- Deduplication Across Three SystemsWhy in-portal deduplication does not hold when an ERP and an operational platform also mint identifiers.
- HubSpot Duplicate ManagementWhat deduplicates automatically, what a merge destroys, and how to prevent the rest.
- The HubSpot Custom Report BuilderThe primary source object, and why it decides what a report can ask.
- HubSpot DashboardsWhich question belongs on which dashboard, and filter scope.
- Centralised or Federated Data GovernanceWho owns a definition when several teams report on it.
Related categories
A system in this category that is not listed
The directory shows range rather than limits. A scoped build is quoted from the object model on each side and the fields that have to cross between them.