HubSpot + Microsoft Fabric integration

The request usually starts with a data team that already runs a Fabric workspace, a lakehouse full of operational tables, and a marketing team that cannot see any of it in the CRM. Somebody asks why a prospect takes a week to reach a campaign, and the honest answer is that nothing carries it.

Fabric earns the middle position when the operational system is hard to reach. We built this pattern for a senior living operator whose property management system speaks SOAP, returns XML and has no concept of a webhook. Pointing a packaged connector at that interface was never an option, and neither was a second runtime nobody would own a year later. The lakehouse was already there, already governed, already on the tenant’s identity and its own key vault.

So Fabric becomes the integration hub rather than the reporting destination. Notebooks pull the operational system into raw tables, clean them, and push contacts, deals and timeline events into HubSpot. The same workspace carries the other direction: a website form in HubSpot becomes a record in the operational system within the hour, with the marketing email that follows recorded back on the source record. The data team keeps one platform, one place for credentials and one set of logs.

The cost of that choice is worth saying out loud. Fabric is a capacity you pay for, notebooks are code somebody maintains, and a lakehouse in the middle adds a hop that a plain REST source would never need.

Five streams carry most of the value, and every one of them keys on an identifier the source system already owns, held in a custom HubSpot property. Contacts upsert on the source contact identifier rather than on email, because households share an address and a returning person often arrives with a second record. Deals upsert on the prospect identifier, one deal per prospect, and the stage is set on creation only, so a salesperson who moves a deal keeps that move.

Activity history is the stream that surprises people. Three years of calls, tours and emails is hundreds of thousands of rows, and it belongs on the timeline rather than in properties, so it lands as custom behavioural events with an append-only ledger recording every event ever sent. The ledger, not the source, is what makes a replay safe.

A reference table decides scope. One row per site or property, carrying a flag that says whether that site syncs at all, keeps a business decision in a table the client can read instead of buried in code.

The shape is polling on a watermark, with the lakehouse holding the state. A pipeline runs the inbound notebooks in order, each one gated on the previous one succeeding: reference data first, then prospects, then residents or accounts, then events. Each stream stores where it read up to, so a failed run costs one interval rather than a full reload.

Outbound is a staged queue. Changes are collected, written to a queue table with their payload, transformed into whatever the source accepts, checked against the safety gates, sent, then verified by reading the record back. Every attempt lands in a ledger with its result, and anything that fails a contract check goes to a dead letter table with the reason rather than vanishing into a log file.

Replay is the test of all of it. Re-running a notebook inside a blackout window does nothing at all, and re-running it outside one sends only what the ledger has not already sent.

The route turns on three things. A lakehouse that already exists changes the arithmetic, because standing up a Fabric capacity to move four objects is a poor trade and a managed sync is cheaper in every dimension. The source protocol matters as much: a SOAP interface with per-site scoping and vendor rules about what may be written needs somewhere to put that logic, and a notebook is somewhere. Direction decides the rest. Reporting loads run happily on a listed connector, and a two-way sync that creates records in the operational system and writes activities back to them does not.

Where all three point at Fabric, the build is large and the running cost is a capacity the business is already paying for. Where they do not, the Skyvia page is the cheaper conversation.

1. Scope. We read the source interface documentation, then prove what it actually accepts, because a vendor interface often takes a field and silently drops it.
2. Architect. We agree the identity keys, the layer boundaries and the scope table before a notebook is written.
3. Build. Notebooks over a shared utilities module, with credentials fetched from the key vault at run time and the portal gate in that shared code rather than in each job.
4. Validate. A dry run mode that computes and ledgers everything without writing anything, run against a sandbox portal and the vendor’s test environment.
5. Operate. Watermarks, ledgers and a reconciliation count, with every notebook exported to a repository so the deployed code and the repository agree.