How to connect Jedox to Microsoft Fabric with the native connector

· Jedox

A step-by-step guide to connecting Jedox to Microsoft Fabric using the native Fabric connection added in Jedox 2026.1 - the OAuth token setup, the Fabric Warehouse and Lakehouse SQL endpoints, and read and write-back jobs in Integrator, with placeholders instead of anyone's tenant.

Jedox 2026.1 added a native Microsoft Fabric connection to Integrator. The release note is two sentences long, which undersells it, so this is a walkthrough of what the setup actually involves and why I think it matters more than the entry suggests.

The short version: once the connection exists, a Fabric Warehouse behaves like any other relational database in Integrator. You create a Relational table extract, choose a schema, choose a table, pick your columns, add a where-filter, and load it into a cube. That is the same workflow your team already uses for SQL Server or Postgres. No REST calls to compose, no JSON to flatten, no result-size ceiling to design around, and on Jedox Cloud no support ticket to get a driver installed.

This is written as a template. Every environment-specific value is a placeholder, so you can follow it against your own tenant.

Two things to check before you plan anything

It is a licensed add-on. The Fabric connector sits in the Jedox Microsoft Connector Bundle, listed under third-party connector licences alongside the OData Connector and the Power BI Connector. It does not simply appear on upgrade. Confirm the licence before you design around it, because this is an awkward thing to discover in a design workshop.

One detail worth getting in writing: the bundle lists an OData Connector, not the OData Hub service. The Hub is named only in the Ecosystem and Enterprise bundles and requires its own licence, so if the client also wants OData Hub patterns, that is a second line item rather than an assumption.

Private networking can rule it out entirely. If the Fabric tenant has Azure Private Link with public internet access blocked, or the workspace restricts inbound public access, a cloud-hosted Jedox instance cannot reach the endpoint at all. That is a conversation to have with the Fabric administrator on day one, not during testing.

Neither of these is a criticism. They are just the two questions that decide whether the rest of this is worth reading for a given client.

What the connector actually is

The 2026.1 release notes carry it under their September 2026 section, so it arrived as a patch inside the 2026.1 cycle rather than at the April release. That is worth knowing when a client says they are "on 2026.1": as with everything else in this release, the patch level is the real answer. The entry states that Integrator now includes a native Microsoft Fabric connection, that it reaches Fabric Data Warehouses and Lakehouse locations through their SQL endpoints, that you can browse workspaces, schemas, tables and views, that both read and write-back jobs are supported, and that an OAuth Token connection is required.

Worth noting on maturity: the entry carries no availability label. The same document marks Cube Delta Extract as Early Access and the new Integrator interface as Beta, so the absence of a label reads as ordinary general availability. That is an inference from the labelling pattern rather than a published stamp, so verify against your own instance.

There is a dedicated documentation page for the connection, though it is not linked from the Integrator connections overview, so you have to go to it directly.

Two ways in, not one

Fabric shows up twice in Integrator, and the distinction decides what you can do:

So the two are not alternatives for the same job. One gives you SQL against tables; the other gives you file exchange against a Lakehouse. Which matters most for the write question below.

Step 1: get the SQL endpoint from Fabric

Open the settings of your Warehouse or SQL analytics endpoint, go to the SQL endpoint page, and copy the SQL connection string. Microsoft's own wording is that you use this to connect externally from Power BI Desktop, applications or client tools. Jedox is one of those client tools.

It has the shape:

<unique-identifier>.datawarehouse.fabric.microsoft.com

You also need the database name, which is simply the name of the Warehouse, for example Sales_Warehouse. These are two separate values and mixing them up is a common first mistake: the database name does not include the host part.

Step 2: create the app registration in Entra ID

Fabric SQL endpoints accept only Entra ID user principals and service principals. SQL authentication is not supported, so for an unattended Jedox job a service principal is the only sensible option.

Register an application in Entra ID (a descriptive name such as Jedox Fabric connection is fine) and collect:

Copy the secret value immediately, because the portal shows it once. Record its expiry date somewhere you will actually look again; an expired secret is the classic reason a working connection dies months later.

Then two grants, both made by administrators:

The step that breaks first attempts

This one deserves its own heading because it is genuinely obscure and it will cost you an afternoon.

A newly created service principal has to be initialised by signing in through the Fabric REST API once. Connecting through the SQL connection string does not by itself mint the principal's Fabric security token. Until that happens, a correctly permissioned service principal still fails, and the errors talk about missing files or absent permissions, which sends you looking in exactly the wrong place.

So: have the Azure administrator make one Fabric REST API call with the service principal before your first Jedox connection test. The token then needs renewing roughly every 30 days, which the platform handles, but it explains why the very first attempt behaves differently from every attempt after it.

Step 3: create the OAuth token connection in Jedox

Here is the structural thing worth understanding: the Fabric connection in Jedox is two connections, not one. The first holds the credentials and fetches the token; the second uses it to reach the Warehouse. That split is the right design, because the token connection is reusable and the secret lives in exactly one place.

Create a connection of type OAuthToken, named something you will recognise in a dropdown later, for example FabricToken:

Field Value
Token endpoint https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token
Authentication method oauth2ClientCredential
Client ID your application (client) ID
Client secret the secret from step 2
Access token scope https://analysis.windows.net/powerbi/api/.default
Client authentication type body

Two notes. The access token scope is the value most often typed wrong, and it looks odd the first time: Fabric SQL endpoints authenticate against the Power BI API scope, and the trailing .default is required for the client-credentials flow. And pick oauth2ClientCredential deliberately - the OAuthToken connection also offers password-credential and refresh-token grants, but those tie a scheduled job to a human account.

Step 4: create the Fabric connection

Create a second connection, type FabricWarehouse, named for example FabricConn. It asks for four things and nothing else:

Field Value
Token connection the FabricToken connection from step 3
host the SQL endpoint, <unique-identifier>.datawarehouse.fabric.microsoft.com
database the Warehouse or Lakehouse name on its own
Additional JDBC parameters leave empty unless you have a specific reason

There is no port, user or password field, which follows from Fabric rejecting SQL authentication. The port is implicit in the JDBC URL Jedox generates, and it is TCP 1433 over the SQL Server TDS protocol. That matters for firewall requests, and there is a trap in it: some protocol-aware firewalls inspect application protocol as well as port, so allowing 1433 is not always sufficient if the rule expects HTTPS on that port. Microsoft's guidance for outbound restrictions is to allow the Power BI and SQL service tags rather than the endpoint hostname, because the FQDN alone will not do it.

If you want to see exactly what Jedox does with those four fields, run a job and read the log. The connection line it prints is an ordinary SQL Server JDBC URL:

jdbc:sqlserver://<host>.datawarehouse.fabric.microsoft.com:1433;database=<warehouse>;encrypt=true;useBulkCopyForBatchInsert=true

Three things fall out of that. It is the standard Microsoft SQL Server driver rather than anything Fabric-specific, encryption is on, and useBulkCopyForBatchInsert=true means the write path is a bulk copy, which is why write-back performs reasonably. It is also the quickest way to satisfy a security reviewer who wants to know what is actually crossing the network.

Save, then test the connection before going further. A failure at this point is almost always one of four things: the secret is wrong or expired, the scope is wrong, the workspace grant is missing, or the service principal was never initialised.

Step 5: extract like it is any other database

Now the payoff. Create an extract of type Relational table and set:

Jedox reads the catalog over the connection, so those lists populate themselves. If they come back empty, that is a permissions symptom rather than a connection fault. From there you get the ordinary relational surface: output columns with names, defaults and aggregation, a where-filter with column, operator and value, a logical filter expression, and sorting.

Everything after this is normal Jedox work: a transform if the shape needs changing, a cube load, and a job with a schedule. The rest of the project never needs to know the data came from Fabric.

The connection supports the full set of relational components - relational extract, relational table extract, relational load and relational SQL load - so write-back is available too.

The write boundary needs stating precisely, because it is easy to get half right. Over SQL, you can read from a Warehouse or a Lakehouse, but you can only write to a Warehouse. The Lakehouse SQL analytics endpoint is read-only over Delta tables by design; inserts, updates and deletes there have to go through Spark. Jedox will accept a Lakehouse database name for a relational load, and the failure that follows is not clearly explained by either product's documentation.

That is not the same as saying you cannot write into a Lakehouse at all. You can, as files, through the FabricLakehouse file connection described above. Two different mechanisms, and conflating them is the most likely design mistake here.

Why this is good news

It is a relational source, not an integration project. Compare it with the two routes people have used to reach a lakehouse from Jedox. A REST connection against a SQL execution API means composing request bodies, working around a result-size limit, flattening JSON and casting every value, because JSON returns strings. A generic JDBC connection means getting a third-party driver installed on the Integrator server, which on Jedox Cloud is a support ticket, and another one every time the driver needs updating. I wrote up both of those routes for Databricks, and the contrast is the point: this is what it looks like when the vendor does that work for you.

Filtering happens at the source. Because the extract is relational, the where-filter goes into the query rather than being applied afterwards. You pull the slice you need instead of pulling everything and discarding most of it.

Your team can already do this. Any Integrator user who can write a SELECT can build a Fabric extract. That moves Fabric work out of the "ask the consultant" category and into the pile the client maintains themselves, which is where integrations should end up.

The credentials belong to an application, not a person. No personal access token quietly breaking when someone changes role. The one recurring operational task is tracking the client secret's expiry.

And it points both ways. Fabric becomes a source for planning inputs - actuals, drivers, operational volumes - and a Warehouse can equally be where plan data lands for downstream reporting. If you need the other direction without this connector, those routes are here.

Before you promise it

The short of it

Setup is two connections and a handful of copied values: an OAuthToken connection carrying the Entra credentials, a FabricWarehouse connection carrying the endpoint, and then a plain relational extract on top. The hard part is not Jedox, it is getting a service principal correctly permissioned and initialised in someone else's tenant.

What you get back is that Fabric stops being a special case and becomes another database in the list. That is the most useful thing a connector can do.

Back to all posts