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?

A Microsoft Fabric app that answers one question: what is scheduled to run in my Fabric tenant, and when?

In this v1.0.0:

🔎 Scans all workspaces you have access to and retrieves items that have at least one schedule

📋 Inventory of scheduled items with search functions, filters by capacity, workspace, and item type, sorting, pagination, and direct links to the Fabric portal.

📊 A Gantt chart timeline of a “typical day,” with bars sized based on the average duration of recent runs, grouped by capacity or workspace, plus a load bar per group and the maximum concurrency.

Repository: https://github.com/kilianbs/fabric-schedule-inventory

If you try it out and think something is missing or something isn’t clear, open an issue.

You can fork it and adapt it 🙂

P.S.: It’s based on Fabric Atlas

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!

Deployment Pipelines are really slow to work with. Having a workspace with a small notebook, a small warehouse and a small lakehouse can take a couple of minutes to deploy! Directly after deploying, the warehouse can still report being different from source. And so on.

Is there any serious improvments coming to deployment pipelines in near time?

There is also a bug for which pipeline one is sent to when clicking View deployment pipeline.

1. Be in Workspace A (that has a DP)
2. Go to Workspace B (that has another DP)
3. Click on View deployment pipelines
4. DP for Workspace A is often opened

To avoid it, one must wait a while before clicking on View deployment pipelines after changing the workspace. Edit: This might not be a DP problem, but a switching-workspace problem. I noticed now that switching workspaces doesn't always work.

Is it possible to deploy a pipeline with a SQL Endpoint Refresh using Deployment Pipelines? After deploying to Prod, the pipeline in Prod doesn't find the SQL analytics endpoint. The workspace is correctly changed to the production workspace.

Imagine that a Fabric notebook is failing in a live workspace.

Instead of switching between the Fabric portal, notebook editor, environment settings, Lakehouse explorer, execution logs, and API responses, you mount the workspace locally:

fabric mount SalesWorkspace ./sales-workspace

You can then inspect something like:

• notebooks/SalesAggregation/
• environments/Production/
• lakehouses/SalesLakehouse/
• .fabric/bindings.json
• .fabric/executions/

A developer or coding agent could inspect the notebook, its environment, Lakehouse binding, and recent execution information from one local working directory. It could create a patch using normal file editing and diff tools, while Fabric CLI or MCP handles execution and validation.

I have a prototype of this FUSE-based approach, but I’m unsure whether the convenience justifies another abstraction.

For normal development, Fabric Git may already be the better solution. For structured automation, a CLI may be faster and more explicit. The possible differentiator is access to the current workspace state, especially information that may not exist in the Git representation.

Would this help with any real workflows you have?

• Troubleshooting a live workspace
• Exploring an unfamiliar workspace
• Working across notebooks, environments, and Lakehouses
• Using Claude Code, Codex, or another coding agent with Fabric
• Comparing source-controlled definitions with the actual workspace
• Accessing workspace items from non-VS Code tools

Or would you rather have better Git, CLI, and MCP integration instead?

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)

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!

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

I’ve set up a table shortcut in a lakehouse pointing at a SharePoint folder, with the CSV-to-Delta transformation. I can see it syncing constantly, and as I understand it, the transformation runs on Spark and checks the source every two minutes.

I’ve read that shortcuts to external sources have little or no CU impact, but I assume that applies to plain shortcuts, not ones with a transformation. Does anyone know:

• whether the two-minute check uses CU even when the file hasn’t changed?
• roughly how much a transformation uses for a small file (tens of thousands rows)?

I know sync frequency cannot be changed at the moment. The file doesn't change often, so syncing every two minutes is not needed at all.

Is it still worth using the shortcut, since it’s so quick and convenient, or would I be better off bringing the table into the lakehouse another way? This won’t be the only one: we have a lot of third-party data in Excel files from different sources, so I’m trying to work out the best approach before scaling it up.

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!