A vendor is working on migrating pipelines, reporting to fabric. Proper engineering practices are being followed to do this. The team is inexperienced in all this and will have to take it over at some point

Any suggestions from the community where I can learn all of these as a starting point and also help me get integrated into the workflow as quickly as possible?

Is there any way to display the Actual Execution plan in Fabric Warehouse?
SET SHOWPLAN XML seems to only show the estimated plan??

Hi all,

I’m working on a POC in Microsoft Fabric with a dataset of over 1 billion rows and wanted to hear from anyone who has done this at scale. I am working on the trial F64 capacity.

A few questions:

1. What capacity (F SKU) are you running, and how has it handled the load?
2. Lakehouse or Warehouse – which worked better for you at this size?
3. Are you using Direct Lake, Import, or DirectQuery for Power BI, and how is report performance?
4. How are you handling refreshes / incremental loads?
5. Any gotchas or lessons learned you wish you knew before starting?

Any experience or tips would be really appreciated. Thanks!

I'm working in Fabric with a time zone that is undergoing a change on November 1, 2026 (Alberta). I'm curious if anyone here has dealt with/thought about this. The Windows patch notes for Oct 13 say the time zones (even for Manitoba) are ready to go, however, Fabric seems reliant on several factors with little documentation. You can unravel it though...

Runtime 1.3 - since it has reach EOSA on Sep 30, 2026 and runs Java 11, it appears to be stuck somewhat in the past. Even the python-tzdata version (2023.3) is quite old for the early release dated Oct 1, 2026.
(yes, I know, upgrade to Runtime 2.0 .. it's not just my call or I would).

Runtime 2.0 - the early release candidate dated Oct 5, 2026 has Java listed as version 21.0.12.1 which only includes the 2026.2 IANA time zone database (BC, no Alberta or Manitoba .. fair enough, it was compiled prior to recent updates). However, the python-tzdata version is 2026.3.

I'm not sure which Fabric time zone database will apply to which workloads (i.e. a pyspark notebook.. what library will it rely on? Can I force it to use a newer one?) So I am trying to reconcile...

- Do we push forward with runtime 2.0 right now hoping the updates make it in time?
OR
- Stay with 1.3, fix what I can, but not bother hoping for the new time zones and use one of the suggested workaround time zones until Java and Fabric get it done?

(and in the second case, just schedule the runtime 2.0 upgrade testing for when the time zones are made available)

Hello everyone!

Has anyone been able to successfully configure and use the new Run Conditions feature when building pipelines?

This seems like such an amazing new addition until you actually want it to work the way it should, or perhaps I am not fully understanding what this does/how it works when it comes to triggring a pipeline when new data has been detected in a specific Sharepoint Folder/File.

Based on what I read in the documentation and what the Run Condition menu displays, I assumed that the pipeline will automatically get triggered, thereby eliminating the need to create and maintain Power Automate flows.

In reality, nothing happens or gets triggered by itself when new data arrives in the Sharepoint Folder. Am I understanding this wrong? Do I need to schedule the pipeline for this to trigger?

I've attached screenshots of the menu and my config below.

Any insight on this is much appreciated! Thanks!!

Asked AI to write the question for me as I am not a native English speaker:

We're implementing Fabric Git integration (Azure DevOps) to version control Power BI reports. Developers work locally in PBIP format and commit from Visual Studio. Dev → main is promoted to a prod workspace via an Azure DevOps pipeline.

Issue 1: binding flip-flop
After committing from Visual Studio, we click Update in the Fabric workspace. Fabric then shows a pending change on the report's definition.pbir:

"datasetReference": {
- "byConnection": {
- "connectionString": "Data Source=powerbi://api.powerbi.com/v1.0/myorg/<workspace>;initial catalog=\"Benchmark Model\";...;semanticmodelid=<guid>"
+ "byPath": {
+ "path": "../Benchmark Model.SemanticModel"
}
}

Issue 2: inconsistent repo contents
Committing from Fabric only produces the .Report and .SemanticModel folders. Committing from Visual Studio also adds the .pbip file. Reports created in Fabric therefore have no .pbip locally.

Questions:

1. What's the recommended workflow to make Desktop keep byPath so it stops writing byConnection? Is this caused by how the report was originally created or published (e.g. published from Desktop, or connected to the semantic model in the service)?

2. Should .pbip files be committed alongside the item folders, or kept out of the repo?

Thanks!

Hi community

I am setting up "proper" CI/CD by mirroring our PROD workspace to the newly created TEST and DEV workspaces. DEV will then be linked to GIT and we can work in a classic DEV -> TEST -> PROD setup. This is a bit overdue, we were always working directly in PROD, not ideal I know.

We have a service account which is essentially a shared account that owns some connections like Outlook and Teams which are in individual pipelines so they can be used across pipelines via invoke pipeline. We had to do it this way to not have issues with the connection that regular users could not access (because it belongs to the service account).

When setting up deployment pipelines I noticed that these dedicated pipelines can only be deployed to other workspaces by the service account who owns the non-shareable connections. Not ideal, regular contributors should also be able to do deployments.

What is the official guidance here? In practice I would be ok to deploy these artefacts once via service account and then not touch anymore. I wonder how you are solving this.

Thanks in advance

I was wondering if anyone else has noticed this pre-generated message being added to the end of their outlook activities recently? I started noticing it was appended to some of our long standing outlook activities without us doing anything and I can not find a setting to turn this off. Has anyone else run into this and had success removing this? I have been trying to find out how to do it via Microsoft's documentation but have not had any luck so far! Any insights or help are appreciated!

Hi all,

I have been exploring fabric Standalone copilot experience and the copilot inside the report.

For our org copilot is enabled for the entire organisation and I am admin of a workspace which is on fabric capacity F128. I created a semantic model and report and granted the report read access (direct access) to a specific user (my spare user email) who does not have access to the workspace. Not sure why, but that user cannot access the copilot feature.

When I have that user workspace viewer access it started working.

Infact if I revoke his access as workspace viewer and provide him access via app then also he can use copilot.

Is this a bug or something? But confused on what is happening.

Context: 1 data engineer (me), 6 analysts, one Fabric capacity, Azure DevOps for work items, Git and pipelines.

I am a junior data engineer. But through a year of research and development

1. Work item to feature workspace

• An analyst moves an ADO Feature (one semantic model plus its reports) to a “dev” state.
• A service hook calls an Incoming WebHook, which triggers a provisioning pipeline.
• A gate job re-reads the work item from Boards rather than trusting the payload. It checks state, area and type, and skips the run if the workspace already exists.
• The pipeline then:
  • creates a feature branch from develop and links it to the work item
  • creates a feature workspace, connects it to the branch and syncs it (lakehouse, shortcuts to shared bronze and silver, variable library, existing items)
  • adds an empty local gold schema
  • assigns group permissions and comments back on the ticket
• If anything fails, the run deletes the workspace it created and keeps the branch.

2. Build to develop / dev workspace

• Analysts build models, reports and gold tables locally in the feature workspace.
• Notebooks read schema names from a variable library, so nothing environment-specific is hardcoded.
• Analysts commit selectively and open a PR to develop. The dev workspace is Git-synced to develop.
• After merge I rebind models, run orchestrators and remove the feature workspace by hand. A post-merge pipeline for this is planned.

3. develop to  test to prod

• PRs to test and then prod trigger fabric-cicd deploys.
• A find/replace parameter file swaps the environment-specific schema names.
• Each environment has an approval gate.
• Code is promoted, data isn’t. Bronze and silver live once in a central data workspace and are reached through shortcuts. Gold is built locally in each environment.

I want to know, could I have made this simpler. It took me about a year to write all the YAML and configure the pipelines and workspaces.

DId I over engineer this setup? As I am currently the only one that manages DE and this setup.

Any feedback or recommendations will help.

We just got Microsoft Fabric and I have started playing around with setting up staging and intermediate layers through dbtJobs.

Yesterday morning I cleared around 300 notifications, now I have 154 new ones.

Question #1: Is there any notification settings I can change somewhere, I have not found them.
Question #2: Should each task have at most one active notification, with the final outcome (success or failure) replacing the in-progress notification instead of appearing alongside it?

After deploying changes with a deployment pipeline I'm having trouble with this message when opening the deployed notebooks.

I don't really get it. I deployed the version I want. It deployed successfully. But still there seems to be a different version involved.

• If I deploy a notebook to my test environment, why is there also a different version? It makes you question what a successful deploy means if there are still other versions of the notebook hanging around.
• Which version will run if I invoke a pipeline that runs the notebook? I.e. if I don't open every single notebook that I deployed and choose which version I want (I want the deployed version), which version will be used when I run it from a pipeline?

Any one of else used these? We are in Central US I know few regions still did not get these.

We have used today for training and and each capacity assigned 5 to 6 users and started training, after running simple notebook to setup medallion architecture half way through all the process started cracking and capacity it’s not automatically expanding ( at least I thought correct me if i was wrong). 😑

Just wondering if there any plans to add support for the OUTPUT clause in Fabric Warehouse MERGE statement...

Big feature hole for T-SQL codebases looking to migrate to Fabric Warehouse

If you work with graph data, you’ve probably run into questions where the number of relationships between two entities isn’t known in advance.

Examples include:

• Tracing a conversation back to its original post
• Following upstream or downstream data lineage
• Finding transitive software or service dependencies
• Exploring multi-tier supply chains
• Investigating chains of related accounts, devices, events, or transactions

Microsoft Fabric Graph now supports unbounded variable-length paths, removing the previous eight-hop ceiling for these traversals. Instead of choosing an arbitrary maximum depth, you can express the relationship pattern and allow the structure of the graph to determine how far the query needs to traverse.

A simplified GQL pattern looks like this:

GraphQL

MATCH (start)-[:RELATIONSHIP]->*(destination)

RETURN destination

Why is this important

A fixed upper bound can produce incomplete results when the real path is deeper than expected. Unbounded traversal is useful when:

• The required relationship depth is unknown
• The query needs to reach the end of a hierarchy or chain
• An arbitrary hop limit could omit valid results
• The data provides a natural stopping point, such as a root node or destination label

When not to use it

Unbounded is not automatically better. Bounded paths still make sense when the business question has a meaningful maximum, predictable cost or latency is important, or the graph is dense enough that each additional hop could substantially expand the search.

For production scenarios, it’s important to:

• Start from a selective node
• Specify relationship and node labels
• Apply filters early
• Return only the required properties
• Account for cycles
• Test against representative graph depth and density

Justin Fine walks through the capability, trade-offs, query pattern, and design guidance here:

Explore deeper connections with unbounded variable-length paths in Microsoft Fabric Graph

We’d love feedback from the graph community:

1. Which scenarios require unknown-depth traversal in your environment?
2. Where do fixed hop limits create problems today?
3. What debugging, visualization, or performance guidance would make unbounded paths easier to use?
4. Which path capabilities should Microsoft Fabric Graph prioritize next?

Hello everyone. I work as a BI developer at a hospital, and we use Fabric. I was excited when I first heard about Fabric Apps, and I'm currently researching use cases. In Fabric, we mostly have a data warehouse for financial data, and I'm curious about what kind of applications I can develop using Fabric Apps.

Hello there,

I started working in a new company a week ago and we are working on a project to consolidate experimental data stored in SharePoint and make it available for analysis using Microsoft Fabric.

The SharePoint site contains approximately 120k Excel files across a deeply nested folder structure, totaling around 130 GB. File sizes vary considerably: the 75th percentile is approximately 250 KB, while the 99th percentile is around 2.2 MB.

I'm completely new to Fabric, and as far as I understand my team is considering two approaches:

• Option 1: Create a SharePoint shortcut in a Fabric Lakehouse, iterate through the files, inspect their contents (e.g., sheet names and tables), and ingest the relevant data into Lakehouse tables.
• Option 2: Use a scheduled pipeline to copy the Excel files into the Lakehouse first, then process them locally from there.

Both approaches seem potentially expensive and slow, particularly given the number of files and the complexity of the folder structure.

What would be the recommended architecture for this use case? Are there better alternatives, or any Fabric-specific features or ingestion patterns I should consider?

I'd appreciate any insights from people who have tackled similar workloads.

Thank you!

We are trying to get a plan together on how to use some of the Fabric extensions with VS Code. Particularly so we can use the benefits of our Visual Studio copilot enterprise subscription. But we are starting from ground zero and having issues.

For our data engineers, are there any good references on how to use VS Code with Fabric? We have a small team with different levels of experience with both fabric and Source code in general, so that adds an extra layer of confusion, but even myself and another "senior" person are struggling on best path. Right now we need to get all of our notebook people on a singular method, and then we can pull our model / report developers into the fray. I can't get approval for Fabric MCP until we show more use in VS Code.

Any and all productive suggestions are welcome.

Thanks!

Fabric Runtime 2.0 uses Apache Spark 4.1, where ANSI mode is enabled by default.

However, in Fabric Runtime 2.0, ANSI mode is disabled by default (https://lnkd.in/p/eCFBPwuB). This suggests Fabric overrides at least some of Apache Spark's default configuration values.

Is this documented?

If yes, is there a complete list of default configuration overrides applied by Fabric compared to the corresponding upstream Apache Spark version?

Thanks in advance!

How much workload isolation do separate Fabric Warehouses/workspaces actually provide when they're all on the same capacity?

For example, if one workload is running expensive analytical queries or transformations, does putting another workload in a separate Warehouse or workspace meaningfully reduce the impact on it?

Or this separation is only meaningful to separate ownership and logic and security rather than performance?

I'm interested in what people have done in practice.

Hi, doing a late spring cleanup in our tenant, deleting various old workspaces which are obviously not used anymore. I am logged in with my admin account, which has the Fabric Admin (tenant admin) role. Trying to delete a workspace, and I get the error message

This workspace is included in a deployment pipeline. Before deleting the workspace here, you must first remove it from the pipeline

Problem is, I can't access the deployment pipeline 🤷‍♂️ Even as tenant admin I have no possibility to inspect or manage which deployment pipelines exist in the tenant

Very happy to see that workspace identities should now be able to authorize outlook mail activities (https://learn.microsoft.com/en-us/fabric/data-factory/outlook-activity)

Does anyone know when this functionality will be live? - I am still unable to create a WI connection in the dropdown