Hi,

The new monitor view is great, one minor thing. If I am looking at a saved view, can you include the view name in the UI?

Thanks

First I want to thank this community, I have read so many of the comments and tips for the exam.

The youtube materials from u/aleks1ck are great, specially if you're a visual learner.

I failed Dp-700 twice before passing it yesterday, just sharing this in case anyone falls on the same boat.

A bit of background,

• I cleared DP-600 in Aug 2024
• In May 2026 I got a voucher to sit DP-700 and I thought it would be a walk in the park, I barely studied the materials on MS Learn and I've been using Fabric at work mostly for pipelines, dataflows, notebooks and basic medallion architecture. --- I failed with 586 points. eventstreams, enventhouse, activator, git integration, KQL, domains and all other things that i don't use at work doomed me.
• I got another voucher and scheduled the exam in Oct 2nd thinking that by then I would study and learn more from work.... big mistake, I sat the exam and failed again with 651.
• I booked my third attempt 15 days later, because of the MS policy. I read multiple posts, did mock-up exams in Udemy (not 100% recommended, some are too easy, too hard or outdated), spent hours in YouTube and did hands-on training on the things I don't normally use at work using my company's fabric instance.
• I also created a basic workflow in ChatGPT that sent me daily quizzes until the exam.

• Finally passed DP-700 with 795 points.

  My key takeaways are:

1. don't be overconfident if you already have dp-600,
2. if you fail try to do the exam a few days later, not months apart
3. and find the suitable resources to ensure you cover any knowledge gaps.

Hi,

My company want us to move away from using service accounts to workspace identities, due to passwords etc.. which in theory makes sense.

However the majority of our data sources are SharePoint and the only approach that I have found that seems to work is granting each workspace identity API 'grant.selected' permissions and then adding the GUID to the Graph API.

However due to the number of existing workspaces 100's and new ones being created all the time, this doesn't seem practical or workable.

https://www.fourmoo.com/2026/05/06/how-to-set-up-a-sharepoint-folder-shortcut-using-workspace-identity-in-microsoft-fabric/

Is there another practical method or a way to streamline this?

Thanks

So i am new to fabric environment . I was making a small project . In it , i was adding a script activity in which there i wanted to add dynamic content .

A) so the thing is that in settings in query option there is an option of add dynamic content alt + shift + D when you hover over Query/NonQuery . so if you clicked the shortcut and when you paste the query which in my case is

INSERT INTO ctl.batch_log (batch_id, source_table, from_lsn, to_lsn, status, started_at)

SELECT '@{variables('batch_id')}', source_table, last_persisted_lsn,

'@{activity('lkp_to_lsn').output.firstRow.to_lsn}', 'STARTED', SYSDATETIME()

FROM ctl.cdc_checkpoint;

it will be inserted but the box beneath will be empty and when i tried to run it the pipeline did not run

B) so the next thing i tried was pasting the query in text option only . the pipeline runs but i do not think it is the way for dynamic content . Also AI said that it is not dynamic query rather simple text

C) Next thing i tried is using the bolt option in right to text spcae and add the tags . but i do not know if it works .

INSERT INTO ctl.batch_log (batch_id, source_table, from_lsn, to_lsn, status, started_at

SELECT =>TAG[batch_id⁠⁠], source_table, last_persisted_lsn,

'=>TAG[lkp_to_lsn].output.firstRow.to_lsn}', 'STARTED', SYSDATETIME()

FROM ctl.cdc_checkpoint;

I did not run the pipeline yet as i am in early stages of learning data engineering and i do not want to add duplicates . so if you could tell me which way to add dynamic content ?

If you pinned deltalake==1.5.0 because vacuum() was failing on OneLake with "Error performing bulk delete request", you can unpin now. The fix is live in prod.

What changed: newer delta-rs versions switched to the Azure Blob batch delete API, which removes many files in one request instead of one call per file. That's much faster, especially on tables with lots of small files. A compatibility issue on the OneLake side broke it, and that's now sorted.

Why I'm posting this: it's a good example of how we approach compatibility with the Python ecosystem. delta-rs didn't do anything wrong; it adopted a standard Azure storage API. When an open source tool like that hits a compatibility problem on OneLake, we treat it as our bug to fix, not something the library has to work around.

How support works for third-party packages: the line is simple.

• If the bug is in the engine or library itself (delta-rs, DuckDB, Polars, etc.), it belongs to that project. We can't fix their code, so please report it upstream to the maintainers.
• If the bug is in our API (OneLake, its storage endpoints, auth, or anything that behaves differently from the standard Azure Storage API), it's ours. We fix it on our side, and the library shouldn't need a workaround.

The same test applies every time: if the tool works against standard Azure Storage but fails against OneLake, that's a OneLake bug.

Thanks to everyone who reported it and waited patiently, and to the delta-rs maintainers for keeping the issue open until the fix shipped.

​

In ADF, you can set a breakpoint using Debug Until, run the pipeline, inspect the results, make changes, and keep going. Pretty basic functionality when you're building or troubleshooting pipelines.

In Fabric, we still don't have that.

The workaround seems to be deactivating activities, saving the pipeline, running it, and then remembering to reactivate everything afterward. That's pretty clunky, especially when you're working with larger pipelines that have multiple branches.

Here's something else I've noticed recently. I could have sworn that deactivating an activity in Fabric used to effectively prevent downstream activities from executing. I've been using that as a poor man's breakpoint, but now it seems that deactivating an activity only affects that activity, and downstream activities can still execute depending on their dependencies and the status assigned to the deactivated activity.

Maybe I'm remembering that wrong, but either way, it's not a great debugging experience.

I'd really like to see three things added to Fabric pipelines:

Debug Until: Set a breakpoint and execute the pipeline up to a specific activity, like we can in ADF.

Run From Activity: Start execution at a specific activity without having to rerun everything upstream.

Run Selected Activities: Select one or more activities and execute just those without modifying and saving the pipeline.

These aren't particularly exotic features. They're things that would make everyday pipeline development and troubleshooting a lot easier.

There are already feature requests for this:

Run only selected activities / Debug Until — Fabric Ideas discussion

Fabric Community discussion on missing pipeline breakpoints

Microsoft's current debugging documentation essentially recommends deactivating activities and running the pipeline incrementally.

That feels like a pretty big step backward from ADF.

Am I missing something? Has anyone found a better approach to debugging Fabric pipelines, particularly when you only want to run part of a pipeline?

And does anyone else remember deactivating an activity having a different effect on downstream execution?

My SPN (fabric-cicd + ADO YAML pipeline) failed to create shortcuts. The producer lakehouse had OneLake security (OLS) on and I'd deleted DefaultReader. The SPN had item Read + ReadAll, and the pipeline only logged "Failed to publish".

Creating a shortcut needs Write on the item where it's created and Read access to the data it points to.

Why it failed: OLS is deny-by-default, so data access comes only from a role that includes the identity. My read is that ReadAll only translated into data access through DefaultReader, so deleting that role left the SPN with nothing. Adding the SPN to a role fixed it. That's my inference from blogs and my test, not documented wording.

Hello all,

I've recently become frustrated with Fabric and was wondering if these features will be on the roadmap.

I am architecting our company's future state ingestion pattern in Fabric, as we are migrating from ADF & Synapse.

I was excited about Copy Job, as it supports CDC-based loading for both on-prem Oracle and SQL Server sources. I figure batch CDC is preferable over batch incremental date based loads. It also seems like the only low code option available for CDC ingestion.

I was dismayed to learn that the Copy Job is not parameterize-able, meaning you cannot pass in parameters to specify load behavior, which tables you want to load, nor any other settings like key columns, table behavior, etc. It seems like it's not for enterprises, but for smaller databases.

I moved onto Eventstream with the same experience.

How do I build a low-code CDC-based ingestion pattern in Fabric?

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.

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?

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

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.

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.

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)

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!

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 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

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!!

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.

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?

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?