Use a managed dbt job in Microsoft Fabric

Fabric’s managed dbt job runs dbt Core inside Fabric. You edit SQL and YAML in the browser, choose the adapter, run dbt commands, inspect compiled SQL and lineage, and schedule the job without operating a separate runner.

This walkthrough uses a Fabric Warehouse in blog_fabric_dbt. dbt jobs are preview technology and must be enabled in tenant settings.

Architecture

CSV seed
   |
   v
stg_orders
   |
   v
fct_orders
   |
   v
Fabric Warehouse + Power BI

Fabric also has a Lakehouse adapter, dbt-fabricspark. That route writes Delta tables through Spark. Do not point the Warehouse adapter at a Lakehouse SQL analytics endpoint. The endpoint is read-only.

1. Prepare the workspace

Create and capacity-assign:

blog_fabric_dbt

Create:

sales_warehouse

The Warehouse was provisioned successfully in the validation workspace before publication.

2. Enable dbt jobs

An administrator must:

1. open OneLake catalog;
2. select Govern > Configurations > Tenant settings; and
3. enable dbt jobs (preview) for the organization or a security group.

You need Contributor or higher workspace access and read/write access to the Warehouse.

3. Create the dbt job

In blog_fabric_dbt:

1. select New item;
2. choose dbt job;
3. name it sales_dbt_models;
4. select the connection to sales_warehouse; and
5. save it.

The managed runtime supplies the dbt-fabric adapter for Warehouse. Fabric owns the runtime; you own the project files, models, tests, and run choices.

4. Add a seed

Create seeds/raw_orders.csv:

order_id,customer_id,order_date,amount,status
1001,501,2026-09-14,124.90,paid
1002,502,2026-09-15,80.00,paid
1003,503,2026-09-16,210.75,fulfilled
1004,504,2026-09-17,52.10,returned

Run:

dbt seed

This produces a deterministic source table for the walkthrough.

5. Build staging

Create models/staging/stg_orders.sql:

select
    cast(order_id as bigint) as order_id,
    cast(customer_id as bigint) as customer_id,
    cast(order_date as date) as order_date,
    cast(amount as decimal(18, 2)) as amount,
    lower(trim(status)) as status
from {{ ref('raw_orders') }}

ref() records the dependency and keeps environment-specific object names out of the model.

6. Build the fact model

Create models/marts/fct_orders.sql:

select
    order_id,
    customer_id,
    order_date,
    amount,
    status,
    case when status in ('paid', 'fulfilled') then 1 else 0 end as is_revenue_order,
    case when status in ('paid', 'fulfilled') then amount else 0 end as recognized_revenue
from {{ ref('stg_orders') }}

Create models/schema.yml:

version: 2

models:
  - name: fct_orders
    description: One row per sales order.
    columns:
      - name: order_id
        tests:
          - unique
          - not_null
      - name: customer_id
        tests:
          - not_null
      - name: amount
        tests:
          - not_null

7. Build and validate

Choose dbt build. It runs models and tests in dependency order.

The UI also supports:

dbt run
dbt seed
dbt test
dbt compile
dbt snapshot
dbt docs generate

After the build:

1. inspect Run Results;
2. review Compiled SQL;
3. confirm raw_orders -> stg_orders -> fct_orders in Lineage View; and
4. query the Warehouse:

select
    count(*) as order_count,
    sum(recognized_revenue) as recognized_revenue
from dbo.fct_orders;

Expected result:

order_count = 4
recognized_revenue = 415.65

The returned order remains in the fact table but contributes zero recognized revenue.

8. Schedule the right layer

Use the dbt job’s Schedule tab when the transformation is independent. Use a Fabric pipeline when the workflow is:

ingest -> dbt build -> validation -> semantic model refresh -> notification

The pipeline should orchestrate. dbt should own model dependencies, SQL transformations, and tests.

Warehouse or Lakehouse?

The adapter is an architectural decision. Check dialect, packages, materializations, and commands before moving a project.

Constraints to design around

• The managed runtime recompiles from source and does not reuse local build cache.
• Generated dbt documentation is stored in OneLake but not rendered directly in the Fabric UI.
• Warehouse and Lakehouse adapters use different engines and capabilities.
• Keep ingestion in a pipeline or copy job when those already own it.

Sources

• dbt job overview
• Create a dbt job
• Common dbt job patterns

Managed dbt jobs are useful because models, tests, dependencies, and monitoring share a Fabric item. The important design choice is still the target: Warehouse and Lakehouse are different execution paths.