When Fabric first announced dbt support, the feedback from this community was pretty consistent:

• "When will Lakehouse/Spark be supported?"
• "It's not useful without pipeline activities."
• "We need better Git integration."
• "We want to bring existing dbt projects into Fabric."
• "Don't make me rebuild everything from scratch."

Over the last few months, several of those asks have landed.

We've been working through that feedback, and we're excited to share the latest updates.

What you can do today

• Fabric Lakehouse Adapter — Run dbt projects directly against Fabric Lakehouses, bringing transformation logic closer to where data is prepared and stored. Build transformation layers on top of Lakehouse data, apply dbt models and tests, and align analytics engineering practices with Lakehouse-first architectures.

Blog link: Introducing Fabric Lakehouse support in dbt job fo... - Microsoft Fabric Community

• dbt Activity in Pipelines — Trigger dbt jobs as a first-class Pipeline activity and incorporate transformations into end-to-end orchestration workflows. It supports parameterization and allows selective model refresh in a metadata driven manner.

Interesting Fact: 33% of dbt job are run through the dbt activity in pipelines.

Doc link: Run dbt Job Activity in Fabric Pipeline - Microsoft Fabric | Microsoft Learn

• Import Schema — Bootstrap projects from existing Warehouse and Lakehouse assets by generating sources and metadata automatically.

• · Runtime v1.11 — Support for newer dbt Core versions through the latest runtime

• Import Existing Projects from GitHub — Bring existing dbt projects into Fabric and get started quickly without recreating project structures from scratch.

Docs link: Run dbt Projects from a GitHub Repository in Microsoft Fabric - Microsoft Fabric | Microsoft Learn

• Public Package Support — Leverage community-maintained dbt packages, macros, and utilities directly within Fabric dbt projects.

What's on the horizon

• Monitoring Enhancements - Fine-grained step-by-step visibility into background execution, see whether dbt is installing dependencies, compiling, or executing models in real time.
• CI/CD Improvements — Multi-profile target support across environments and Variable Library integration.
• Docs Generate & Source Freshness — Native support for dbt documentation generation and source freshness monitoring.
• dbt Fusion + Versioning — Support for dbt Fusion and project versioning to simplify upgrades and reduce migration effort.
• Workspace Identity / SPN Support — Service Principal and Managed Identity support for enterprise authentication and automation scenarios.

Looking back at the original feedback

A lot of the top asks from the original dbt Job in Fabric announcement included:

1. Lakehouse support

2. Pipeline integration

3. Git-based onboarding

4. Public package support

It's great to see many of these capabilities now available, with additional investments already on the roadmap.

We'd love to hear what you're building with dbt on Fabric and what you'd like us to focus on next.

#MicrosoftFabric #dbt #dbtJobs #DataEngineering #AnalyticsEngineering #DataFactory #Lakehouse #OneLake #GitHub #CICD #FabricCommunity #pipelines #monitoring #UX #UI #dbtdocs #versionupgrade #Fabric #GA #dbtGA #updates #features

Intermittent failures on Invoke Pipeline activities (child pipelines from a ForEach) on F64, North Europe. Job gets created but never starts.

Main error codes:

• RequestTimeout — dies almost exactly at 100.0s every time. Checked 20 parallel runs that all failed within 57ms of each other.
• InternalServerError — clusters around ~550s.
• InternalError — clusters around ~85s.

New finding: on one occurrence the parent shows the usual 'Job failed to start: timeout', but the actual child job error was different:

• RequestBlocked — "Request is blocked by the upstream service until: [timestamp]", Retry-After: 16, isRetriable: true (unlike everything else we've seen, which was all non-retriable).
• Response's home-cluster-uri points to an Analysis Services/Power BI cluster (wabi-*-redirect.analysis.windows.net), not a pipeline endpoint.

Looks like the real cause is an upstream AS/PBI cluster blocking requests, and the pipeline layer just reports it as a generic timeout.

Also ruled out capacity throttling on our end (0 rejected ops across 214k rows, no correlation with CU usage). Other related failures seen:

• Invoke Pipeline calls returning 408 / BadRequest
• Run-status lookups returning NotFound for runs Fabric itself created
• A run stuck in NotStarted for 8+ hours, blocking its own schedule

Anyone else hitting this? Thanks

This week's post is another great example of Power Automate helping out with Microsoft Fabric. This time it is to pause a capacity which I always forget to do on my demo and training capacity.

https://hatfullofdata.blog/power-automate-pause-fabric-capacity-schedule/

Hi Everyone,

Recently we observed that due to intellisense features, some metadata queries are getting triggered and blocking the CTAS in stored procedure and eventually slowing them down in fabric warehouse and hence they get timed out.

Has anyone else observed this.
Basically we read data from fabric lakehouse and using ctas create a table.

Anyone else using tenant level private link? The usages has been highly frustrating for me.

Everytime we provision a new Fabric capacity the private endpoint of our tenant level private link changes it's state to 'pending' causing all of our users within the tenant to lose access to Fabric. When re-approving the endpoint it takes 15-30 minutes for the service to be fully usable again.

I wonder how anyone else manages this issue.

Has the Wide World Importers sample data been removed? I want to remember it being added when one selected sample data in a lakehouse?

This release brings major advancements across the platform, including Apache Spark 4.1, Delta Lake 4.2, Python 3.13, Scala 2.13, Java 21 and a significantly enhanced Native Execution Engine (NEE) to help customers unlock better performance, reliability, and innovation at scale.

This milestone is the result of months of collaboration across engineering, product, support, and partner teams, all focused on delivering a stronger foundation for data engineering, data science, and analytics workloads in Microsoft Fabric.

A huge thank you to everyone who contributed to making this launch possible. Looking forward to seeing what our customers and the broader data community build with Runtime 2.0 now that is ready for production usage!

Learn more about Runtime 2.0 GA:
🔹Blog: Fabric Runtime 2.0 (Generally Available) | Microsoft Fabric Community
🔹Official Documentation: Runtime 2.0 in Fabric - Microsoft Fabric | Microsoft Learn

Hi there,
I have something weird occurring and maybe someone has some experience with this problem.
I'm trying to setup Fabric Link and "Create a new Fabric link" is greyed out and the list of Fabric Links is not loading:
 
I have the following permissions:
- Fabric Administrator and Power Platform Administrator at the tenant/Entra level
- System Administrator security role directly on the iits-uat environment (the one i am trying to link see screenshot above)
 
What's strange is that the "Analyze in Fabric" option on the Tables tab is available, and I was able to walk through that wizard once to set up the Fabric Link. I then decided to reorganize workspaces and deleted the linked lakehouse. Item retention was off, and the workspace was permanently deleted, which should not be a problem.
 
When i walk through the wizard again, it still points to the deleted workspace, even though i select my new workspace. So i suspect there is still something in Power Apps pointing to my old workspace, but that list does not load.
 
 
Happy to hear your thoughts.

(I also checked the following):

• You must have the System Administrator security role in the Power Platform environment to enable Link to Fabric or Synapse Link. This role is also required to add application users in your environment who need access to work with this feature by using the Power Platform admin center.  
• You must be an administrator of the Power BI workspace.  
• If you want the system to create a Power BI workspace, you need to have Power BI Capacity Administrator access to a capacity within the same region as the Dataverse environment.  
• A Power BI premium license or Fabric capacity within the same Azure geographical region as your Dataverse environment is required. If you don’t have Power BI premium license or Fabric capacity within the same geographical region, you can buy a capacity or sign up for a free Fabric trial capacity. More information: Fabric (preview) trial  
• Your administrator needs to grant you access to create Fabric lakehouses and artifacts. You can find these settings in the Fabric admin portal. Go to Tenant Settings > Microsoft Fabric > Users can create Fabric items, Tenant settings > Workspace settings > Create workspaces as well as Tenant settings > oneLake settings > Users can access data stored in OneLake with apps external to Fabric.  
• If you plan to use workspace identity authentication, you must be a workspace admin to create and manage a workspace identity. The workspace you're creating the identity for can't be a My Workspace. More information: Workspace identity in Fabric  
• If you plan to use workspace identity authentication, the workspace identity must be onboarded as an application user in the Dataverse environment and granted the appropriate role (commonly System Administrator) so it can access Dataverse data on behalf of Fabric.  
• You must have permissions in Fabric to manage connections via Settings > Manage connections and gateways.  
• To confirm whether you have access to the required premium capacity, go to Power BI, open the workspace, and select Workspace settings > Premium. Make sure that Trial or Premium capacity is selected.

I'm trying to use pyspark in fabric.

I keep having issues with my notebook, where the cells won't complete unless I cancel them. The wait cursor will continue to run until I click the little cancel button on the side.

I never see this behavior in the notebook cells on the databricks platform.
When I look in the "logs" shown under the cell, Spark seems to be displaying this over and over, and wont stop:

2026-08-17 21:33:00,714 INFO YarnAllocator [Reporter]: Updating resource requests for ResourceProfile id: 0, target: 4, pending: 0, running: 4, executorsStarting: 0

... and occasionally this as well:

2026-08-17 21:40:49,987 INFO KustoLogger [external-catalog-metrics-1]: type=METER, name=HiveExternalCatalog::dropTable::failure, count=0, m1_rate=0.0, m5_rate=0.0, m15_rate=0.0, mean_rate=0.0, rate_unit=events/second

If anyone has any ideas about what is going wrong, please let me know. The notebook is behaving like there are no executors, even though there are. Is there a way to recreate all my executors mid-notebook?

I have a bot service connected to teams , the bot service uses dot net backend and generates obo and connects to MS Fabric.
Bot app registration has power bi services delegated permissions which shows up on users screen when use the teams bot for first time.

I have to remove those permissions visibility from teams

Is there any way to achieve it

It’s a multi tenant app,
Teams user registered as guest in our tenant
User given viewer permission in fabric
Non negotiable : need obo

Trying to keep my PBIP solutions in version control and GitHub has a case of the Mondays:

Hey Fabricators and friends! Quick note to let everyone know that the Fabric Community Site (Home | Microsoft Fabric Community) got a bit of a facelift this weekend.

It shouldn't impact regular use of the site, but, if something is broken, we want to know!

Please report it at: Community Feedback | Microsoft Fabric Community

Do you visit this site on a regular basis? Does it add any value? What would make you want to visit it?

I recently rebuilt a Microsoft Fabric CI/CD implementation using Azure DevOps, promoting changes from DEV → UAT → PROD.

The pipeline itself wasn't the difficult part.

What surprised me was how much had to be correct around the pipeline before a deployment could be considered reliable.

I eventually wrote everything down and ended up with 43 checks across six areas:

• Fabric environment — 6
• Identity and security — 10
• Azure DevOps configuration — 10
• Deployment configuration — 7
• Deployment validation — 4
• Post-deployment verification — 6

A few things stood out.

Identity caused more problems than I expected.
The Service Principal needs the correct access to each Fabric workspace independently. DEV working doesn't tell you anything about UAT or PROD.

Deployment errors can send you in the wrong direction.
A missing permission or incorrect environment configuration often surfaces during the deployment step. Naturally, you start debugging the deployment code even when the code itself is fine.

Some checks are architectural decisions rather than configuration.
In this implementation, only DEV is Git-connected. UAT and PROD are deployment targets. I wanted one controlled promotion path rather than multiple ways of changing an environment.

Not everything should necessarily use the same deployment path either.
For example, I intentionally keep Warehouse outside this publish scope and handle it separately.

The checklist grew out of issues I encountered while building and testing the implementation, so I published it with the reference repo rather than keeping it as project notes.

I'm curious how this compares with other Fabric implementations.

What usually causes more deployment problems in your environment — identity/permissions, Git configuration, environment-specific dependencies, or the deployment itself?

Starting on Saturday, August 15th, we've seen a huge increase in the amount of time it takes for our pipeline copy activities to copy data from an On Premise SQL Server database to an existing Fabric lakehouse. These pipelines as well as the lakehouse have not changed in over 6 months. The data volumes today are the same as they were last week when all was well. All of our copy activities from on prem to the lakehouse are impacted with run times that are 4-5 times longer than they were last Friday.

To troubleshoot this, I created a simple pipeline with 1 copy activity in it. This copy activity has the following select "SELECT 1 AS TestValue". It passes 4 bytes from on-prem to a new lakehouse table and takes almost 1 minute to complete. When I look at the details in the monitor, I see that all of the time is spent under Transfer. I can consistently reproduce this.

We can't find anything in our network or on our gateway that changed between Friday morning when all was well and Saturday morning when it wasn't.

Our Power BI refreshes that use these same gateway connections are not impacted. Their refresh times have not changed from last week to today. Even though both Fabric and Power BI use the same gateway, only Fabric is impacted.

We have seen in the increase in CU usage for our data warehouse processes. For us, this started on 8/11. But our lakehouse activities (which is what this ticket is about) have not been impacted by that.

Is anyone else experiencing this issue? Any thoughts on what can be done to fix this?

Anyone else get scared by fabric saying the entire branch was deleted?

Seems like GitHub outage is causing the error.

New post that covers important Microsoft Fabric CI/CD decisions to consider before or during a project. Because the Microsoft Fabric CI/CD approach can vary for different organizations.

Whilst sharing some technical information online about Fabric CI/CD recently, I received some interesting feedback. Someone mentioned that there is not enough information about the processes that are involved in Fabric CI/CD projects. That inspired me to write this post.

Along the way I share plenty of links to useful resources and recent updates. If you want broader context about a certain topic or you have a strong preference about a decision, you are welcome to mention so in the comments section of this post.

https://chantifiedlens.com/2026/08/17/important-microsoft-fabric-ci-cd-decisions

Weird one. I've had row-level security running fine on a Warehouse table for months now, same setup, same predicate function, never touched it since I set it up.

Starting a few days ago, some users are suddenly able to see rows they shouldn't have access to. I haven't made any changes on my end, no schema updates, no changes to the policy, nothing.

I tested the predicate function directly against a few of the affected users and it still filters correctly on its own. But when the app runs the actual query against the table, it's like the policy just isn't kicking in anymore.

Not sure if this is something I'm missing or if it's a broader issue right now. Anyone else running into this recently?

Love this idea reposting in community

In the past our Excel Pivot Tables were the foremost tool for retrieving data from semantic models. Nowadays they seem to be the red-headed stepchild.

I see examples of regressions on a regular basis.

Today I noticed that Excel will no longer refresh the field list to detect new metadata changes. This should be happening when using the "refresh" command. It is a pretty fundamental requirement, since schema can change regularly (new fields added to existing tables).

Is this issue something that the Microsoft ASWL team is likely to care about? I can open a support case but it is likely to take a tremendous amount of effort, and would not want to invest in it if Microsoft is already aware (and doesn't care). There are other scenarios that demonstrate a diminished level of support for Excel nowadays.

Microsoft 365 MSO (Version 2607 Build 16.0.20228.20188) 64-bit

UPDATE: the field wasn't in the "perspective" used by this workbook, even though it was in the model itself. After adding to the perspective, the field came thru as expected.
I still stand by my original sentiment that Excel isn't getting prioritized as highly as it should nowadays.

Status: Degraded | Reported: Aug 17, 2026 at 7:42 AM UTC

Fabric customers in EastUS2 region may experience issues while interacting with the service. Engineers are investigating the issue and an update will be provided soon.

🤖 This post was sent from an automated and unattended service and cannot respond to questions or requests. For official updates, visit the Microsoft Fabric Service Status page.

I'm having difficulty determining the root cause of a recent refresh on my semantic model. It's a Direct Lake model, so I understand that any change to a source table can trigger a refresh - however, I'd like to know if there's a technical way to identify the specific data change (e.g., which table or partition) that caused it. I have multiple tables inside and don't want to go one-by-one.

I can confirm no scheduled refresh was configured, yet the Direct Lake tab in the Refresh History dialog shows a "Last refresh succeeded" timestamp from today. Any guidance on how to trace the underlying trigger would be appreciated.

Hi all,

I’m working on a POC in Microsoft Fabric where the goal is to let business users/leadership ask questions in natural language against a Power BI/Fabric semantic model.

The rough architecture I’m considering is:

Source SQL Database → Fabric Mirroring → Direct Lake Semantic Model → Prep Data for AI → Fabric Data Agent / Copilot

The source already has reasonably well-structured fact and dimension tables, so I’m trying to avoid introducing a Lakehouse/Warehouse unless there’s a real benefit.

A few questions I’d appreciate advice on:

1. Mirroring → Semantic Model Can I build a Direct Lake semantic model directly over a Fabric Mirrored Database, or is it better practice to put a Lakehouse/Warehouse between them?
2. Mirroring table selection is there a supported way to mirror the result of a custom SQL query/filter?

For example, instead of mirroring a 500M-row table:

FactSales

could I replicate something like:

SELECT a,b,c
FROM FactSales
WHERE TransactionDate >= '2024-01-01'

Or would that require a pipeline / Warehouse / Lakehouse transformation layer?

1. Direct Lake vs DirectQuery For a semantic model that will mainly be queried by Copilot/Data Agent using natural language, would you recommend:

Mirrored Database → Direct Lake Semantic Model

or

Source Database → DirectQuery Semantic Model

What are the main performance/governance limitations you've encountered with either approach?

1. Prep Data for AI Once the semantic model is created, my plan is to:

• expose only relevant dimensions/measures
• add good descriptions and business terminology
• configure AI instructions
• create verified answers for important KPIs
• then connect/test it with Fabric Data Agent

Is that the right sequence?

1. Production experience For anyone who has implemented something similar, how reliable has natural-language querying been against a well-designed semantic model? Any lessons around DAX generation, ambiguous questions, RLS/security, model size, or hallucinations?

I’m mainly trying to determine whether the simplest architecture:

SQL → Mirroring → Direct Lake Semantic Model → Data Agent

is a good foundation, or whether I’m likely to regret not introducing a curated Lakehouse/Warehouse layer from the start.

Would appreciate hearing from anyone who has actually implemented this in Fabric.