I joined an already in progress project a few weeks ago and they're using a Warehouse. On the surface it looks good - schemas, table defs, sprocs, views, all end up in the repo. I can even download a "zipped project" from the menu bar.

Try to update your workspace with changes someone else made or you made in your desktop-VS-Code version, wow. The fun ends there.

1. Reordered two columns in a table definition by mistake? (or simply added them in a different order than they did) Broken, unable to resolve the conflict.
2. (same as adding a brand new column, better patch that table first)
3. Having trouble with a Shared Query that ended up in Git which somewhere along the lines disappeared during the sync? Forget it, it's gone. Can't add it back under the same name either.
4. (there appears to be some magic to this relationship not exposed to git, yikes)
5. (this feature is buns, I hate Shared Queries)
6. Did someone delete a view, commit the change, and you also deleted the view prior to sync'ing? Sync'ing of the WH is now broken - it wants those views back no matter what you think!
7. (Undo'ing the delete ... gets part way there, until this just appears again)
8. Delete the entire damn warehouse and try to get a new copy from the repo? Sorry, that doesn't really clear the workspace's cache and we're going to just make you go through the same song and dance again.

Either do it properly or don't do it. This has been the _worst_ Fabric experience to date. I am beyond frustrated.

The worst part is that it also means there is no clear way to keep the dev-git-connected workspace in sync without manually running some updates before attempting to sync. You can't create a SQL script or Notebook to do patching with your branch-pull-requested-into-main.. because if the Warehouse alphabetically comes first, those Notebooks don't get added/updated because it can't sync.

The fun part is that when I delete the warehouse and bring it back, I have to "apply the system update" over and over because I guess it changes the git repo (but no changes show up under Source Control/Change).

I don't understand why I can't update individual items. I understand it could break things if objects depend on each other, but I don't care.

Per subject, I am likely taking a position where I will be once again working within Fabric after almost a year of working within Snowflake and not touching Fabric at all.

This is not meant to be a rage-bait or troll post.

When I transitioned to Snowflake about a year ago it was honestly a relief, everything from the UI to the tooling just felt better, so the possible return is leaving me somewhat apprehensive. But I'm hopeful that in the intervening period there have been improvements in Fabric.

Basically, can folks name a few items that they see as Fabric doing better than Snowflake so I can sort of console myself with this transition?

Edit: Already looking pretty grim, it's not a good sign when people with actual Fabricator flair are dogging your product Microsoft.... So maybe a follow up question is "can I 'use' Fabric but actually behind the scenes basically barely touch it?" Like somehow give the appearance of using Fabric but really I'm just running dbt and duckdb (and maybe even Snowflake) but using an API or 2 to make it seem like Fabric is an important part of our stack?

A couple months ago I was playing around with Planning Sheets and was able to generate some mock ups and played around with the features. I was pretty happy with the outcome so far.

Today I was trying to implement a real business use case. Unfortunately, the planning sheets do not work anymore since Semantic measures do not populate any data:

Here is my issue:

- Successfully connecting to Semantic Model with RLS (located on same capacity, but in different workspace)

- All fact, dimensions as well as columns and measures are available

- No measures return any data

Does anyone else experience this issue? If yes, how did you solve it?

There already seems to be a post in the Microsoft Fabric community about it:

Planning sheets show "No rows to display" with model measures since 30 Sep update | Microsoft Fabric Community

A bit of good news around using DAX Lib and UDFs. It helps AI search and install UDFs on DAX Lib easier.

https://www.sqlbi.com/blog/marco/2026/10/22/install-dax-libraries-into-power-bi-desktop-by-asking-your-ai-assistant/

I’ve been evaluating Microsoft Fabric Planning, and while I see significant potential in the functionality, the current 30-day user session billing model seems fundamentally flawed.

From my understanding, a single interaction with Planning triggers a 30-day billing period, regardless of whether someone uses it for five minutes or every day.

I do appreciate that Microsoft avoids double billing users across different roles or workspaces within the same capacity, charging based on the highest role activated rather than stacking charges.

However, the underlying model still seems like a significant capacity hog relative to actual usage. A user could spend five minutes reviewing or updating a forecast and trigger 30 days of capacity consumption.

For organizations with existing dedicated capacity, this may not immediately translate into additional costs, but it still consumes capacity that could otherwise support other Fabric workloads.

This seems particularly inefficient for occasional users, such as leadership reviewing forecasts or employees participating in periodic approval workflows.

Why not implement daily active-user billing or a consumption-based model more consistent with the broader Fabric platform? Even a daily minimum would seem substantially more reasonable than a 30-day commitment.

Has Microsoft acknowledged concerns about this pricing structure or indicated any plans to revisit it? I’m curious whether there have been discussions, roadmap updates, or community feedback suggesting this might change.

Hi guys,

With the recent updates in fabric and power bi. I am seeing so many copilots... Im not sure how they are different from each other. My client has m365 copilot premium, we have fabric f128 capacity in which there are 2 copilot it seems standalone and within report. Does anyone have any documents indicating the difference between them and how they interact differently?

In this part of the project, I reached the semantic model in Power BI and built the Overview report.

At this stage, I tried the Power Bi Copilot agent in fabric . When I asked it for a specific number or KPI, it returned accurate results. But when I asked it to build a layout, it got confused and didn’t deliver what I asked for, even though my prompt was precise. I hope the team can find a fix for this.

After that, I started applying OneLake Security to the Bronze and Silver layers, since those are the two layers that data engineers are mainly supposed to access, and not everyone with workspace access should be able to see the data inside them. One thing that bothered me a bit about OneLake Security is that we can’t enable Git integration for them.

And that’s it, my project is done.

Hi,

Anyone else not being able to access a warehouse anymore?

Through SSMS it keeps loading, using the GUI I'm getting this...

I have been experimenting with building interactive dashboards in Claude directly on top of Power BI semantic models using the Power BI MCP server.

At first glance, it is quite impressive! You can ask Claude to build an interactive dashboard, and it generates one by querying your semantic model using DAX. No need to export or copy the underlying dataset.

But building a dashboard is one thing, making it work in a real business environment is another.

I spent quite some time testing different scenarios, including RLS, sharing, permissions, authentication, and connecting to multiple Microsoft Fabric tenants.

Here are some of my findings:

• RLS works, but there is a catch! Claude respects the RLS configured on the semantic model for the account authenticated through the connector. However, sharing the dashboard with another user doesn't automatically mean their own security context is applied. This is an important distinction, especially in enterprise environments.
• Read vs Build permissions: I tested how semantic model permissions and workspace roles affect the results. Giving users elevated workspace permissions can completely change how RLS behaves.
• Sharing isn't as straightforward as you might expect. A working dashboard doesn't necessarily mean you have a solution that securely serves different users with different access requirements.
• Multiple Fabric tenants introduce another challenge: I couldn't get my tested configuration working across multiple tenants. I also discuss a possible workaround, but I haven't tested it, so I cannot confirm that it works.
• Claude actually generates DAX queries: It is interesting to see what happens under the hood rather than just looking at the generated visuals.

I also looked at how Claude Dashboards compare with Power BI reports and Microsoft Fabric Apps, and whether this approach is actually practical for production environments.

I have gone through quite rigorous testing, and covering all the configurations, results, gotchas, and nuances in a Reddit post is pretty much impossible. So this is just a summary of some of my findings.

For those interested in the technical details, I recorded a step-by-step walkthrough, from Entra ID app registration and Fabric Admin Portal settings to building the dashboard and testing the security behaviour.

Full video with demonstrations:
https://youtu.be/27sGekTfBas

Podcast version on Spotify (AI-generated from my original video):
https://open.spotify.com/episode/2cybQ1AnGYAyxX0ZZHqZyg

My takeaway is that Claude Dashboards are genuinely interesting, and I can see potential use cases for them. But I wouldn't confuse generating a working dashboard with having a production-ready solution.

I'm particularly interested to hear if anyone has tested a different approach to handling per-user authentication or multiple Fabric tenants.

Have you experimented with this? I'd be interested to hear about your findings, especially if you've managed to address any of these limitations.

I'm seeing Fabric IQ Planning stops updating the grid when more complex calculation item exists in the connected semantic model. The grid keeps its previous state. The calculation group isn't used or filtered anywhere in the sheet.

This seems to be chaging the datatype of the returned data from DECIMAL to STRING.

This item triggers it:

AVERAGEX(
    VALUES('Dim Calendar'[Date]),
    SELECTEDMEASURE()
)

Removing the item restores grid updates. Items using SELECTEDMEASURE() or SELECTEDMEASURE() * 2 work.

What I've checked:

• Power BI reports on the same model work.
• Profiler confirms Planning's DAX query executes and returns data.
• The DATA response contains 297 rows in both cases.
• In the failing response, the numeric measure is serialized as UTF8 text in Parquet. In the working response, it's DOUBLE.
• Wrapping the measure in CONVERT(..., DOUBLE) doesn't help.

Microsoft documents that calculation groups make measures Variant. I suspect Planning isn't handling that consistently.

Has anyone hit this or received a fix from Microsoft/Lumel?

Disclosure: I work on ETLMaestro, which orchestrates pipelines on both ADF and Fabric, so weigh that. Every number below is a public list price (East US, pay-as-you-go unless I say otherwise, checked October 2026), and the math is here so you can check it.

TL;DR: Per non-copy activity run, ADF and Fabric list prices are within 1% of each other. The difference is that Fabric needs a running capacity. If you’d buy capacity just for pipelines, ADF is cheaper at almost any volume. A reserved capacity you keep busy beats ADF by about 40% per run, and capacity you already pay for with room to spare makes orchestration close to free.

The per-run math

• ADF: $1.00 per 1,000 orchestration runs on the Azure integration runtime.
• Fabric: 0.0056 CU-hours per non-copy activity run. At $0.18 per CU-hour, that’s $0.001008 a run, or $1.008 per 1,000.

The meters look designed to match. The last column is what you’d pay for a capacity used only for pipelines.

Why an F2 is both a floor and a ceiling

An F2 is 2 CUs, so it costs 2 × $0.18 × 730 hours = $262.80 a month, the same as 262,800 ADF runs. It also supplies 1,460 CU-hours a month. At 0.0056 CU-hours per run, that’s room for about 260,000 non-copy activity runs a month (about 8,600 a day) if nothing else runs on it.

So on pay-as-you-go, a dedicated F2 costs $262.80 whether you run 5,000 activities or 260,000. ADF charges $5 to $260 for the same work. They meet only when the F2 is full, and above that you step up to an F4 or F8 and the same thing repeats.

Reservations change the answer

A one-year Fabric reservation is $938 per CU per year, about 40% less than pay-as-you-go. A reserved F2 comes to about $156 a month, or about $0.60 per 1,000 runs when it’s full. Against ADF’s $1.00, a reserved F2 used only for orchestration is cheaper above roughly 156,000 runs a month. You’re committing for a year, though, and the reservation bills whether or not anything runs.

If you already pay for capacity

If you already have, say, an F64 for Power BI, pipeline runs draw on CUs you’ve paid for, so the marginal cost is close to zero while there’s headroom. The tradeoff is sharing. Pipeline activity runs are background operations, smoothed over 24 hours. Once a capacity has used up its next 24 hours of CUs, Fabric rejects all new jobs, pipelines included. If your capacity admin turns on surge protection, background jobs get rejected earlier, at whatever threshold they set. ADF pipelines don’t draw on the capacity your reports use.

Small print

• Fabric’s 0.0056 includes what Microsoft calls activity integration runtime charges. ADF bills execution separately, rounded up to the minute: $0.005 an hour for pipeline activities like Lookup and Get Metadata, $0.00025 an hour for external ones like stored procedures. A one-minute Lookup adds about 8% to ADF’s side; external activities add well under 1%.
• ADF also counts each trigger execution as an orchestration run.
• ADF’s idle charge for pipelines is $0.80 a month for each one with no trigger and no runs that month. A paused Fabric capacity can’t run anything.
• Copy activities, and the compute a pipeline calls (notebooks, data flows, Databricks), bill separately on both platforms and aren’t compared here.

Where I land

If your orchestration is bursty or low-volume and you don’t have Fabric capacity today, ADF is cheaper. If the volume is steady enough to commit to for a year, a reserved capacity can come out ahead. If you already pay for capacity with headroom, run it on Fabric and have someone watch the background percentage in the Capacity Metrics app.

Has anyone compared 0.0056 against what the Capacity Metrics app shows for their own pipeline runs? I’d like to know whether real runs bill the way the pricing page says.

Sources: Fabric pipelines pricing, ADF pipeline pricing, Fabric throttling, surge protection, and the Azure Retail Prices API for the per-meter rates. Longer write-up with a feature comparison: etlmaestro.com/fabric-vs-adf

Has anyone been able to pull the list of all connections in their tenant?

The September update and this article indicates it is possible, but I cannot get it to work.
Data source management - Microsoft Fabric | Microsoft Learn

I am using the same Service Principal I use for the other Admin APIs. The app reg has Power BI service Tenant.Read.All api permissions

This is the endpoint I am trying that is listed in the MS doc

https://api.fabric.microsoft.com/v1/admin/connections

Trying to gauge if I should keep poking at this or wait until something more "official" comes out

Thanks

Hi,

I'm working with multiple workloads across a 4 workspace structure and I've been considering the move between environments. For info we use fabric cicd for deployments.

Looking at the structure of the objects in git, it seems it would make more sense to have environment specific configuration for each object in the same way I would for a C# project.

So we could have

eventstream.json

eventstream.develop.json

eventstream.staging.json

eventstream.production.json

This would role up based on a workspace environment tag.

That way we don't need find and replace etc.

Am I alone on this?

Hi all. I've been working on an open-source tool for a problem many of us know: you need to move one change from a dev model to production, and publishing replaces the whole model.

Model Alchemist runs locally and compares two semantic models in TMDL format. Each side can be a PBIP folder or a semantic model in a Fabric workspace, read and written through the Fabric REST API (getDefinition / updateDefinition). Sign-in is OAuth2 with PKCE in your browser using the public Power BI Desktop client, so no app registration is needed, and the token stays in memory.

What it does:

1. Compare: object-level differences across eleven change groups, with the changed DAX or Power Query fragment highlighted.
2. Select: tick the objects to promote. Changes that must ship together are grouped. A selection that would leave the target invalid (a missing function or named expression, or removing one the target still uses) is blocked.
3. Deploy: dry-run preview, backup, then upload of only the selected objects. Before the upload the live model is fetched again; if it changed since the comparison, the deploy is refused.
4. Verify: an Enhanced Refresh scoped to the affected tables, with per-table status, followed by a model-level recalculate. A readiness check (Model Refresh, then Check Target State) shows which objects in the target still need a refresh or recalculation, at any time.

Known limits: semantic models only, not reports; Windows is the supported platform; model-level annotations are not compared yet.

There is a synthetic Demo Kit in the repo that you can open in Desktop, publish to two test workspaces and use as Source and Target.

It is in active development and I'd value feedback from people promoting models between workspaces: what's missing, what doesn't match your process, and anything that behaves unexpectedly. Issues on GitHub are the best place.

https://github.com/goreckir/model_alchemist

Hi All, Since around the 15th Oct we have been having a nightmare with our development workspace. We have a Dev workspace to Prod workspace CI/CD setup with Git in Devops. We all work in the Dev workspace at the same time. This has not caused a problem in the past but recently Fabric is not managing the changes properly; I can make a change to the notebook and it later gets magically overwritten. At one point I made a change to a notebook, committed in via source control, and my changes were not there. Another issue I had is I deleted a bunch of measures from a model and they reappeared. I did this 3 times and had to give up!

I believe this is due to other devs having their own cached version in their browser and one of the takes precedence. I though models were live edit and handled multiple devs working simultaneously.

I am surprised that there has not been more content online about this as it appears to me as a recent bug which is detrimental to development workflow.

We are dropping Alteryx to consolidate on Microsoft Fabric.

We have dozens of .yxmd workflows with coplex macros and formulas. Rebuilding them all manually in Dataflows Gen2 or PySpark notebooks is going to take months.

How did you guys migrate you workflows? is there an automated tool to convert Alteryx files into Fabric, or do we have rewrite everything from scratch?

Just a note for anyone whos currently using or intend to use Fabric Actions activity in your pipelines AND specifically going to use git integrations

If in the same pipeline you have some activity such as notebook, copy activity, lookup etc if you git integrate into your repo like azuredevops, the json structure of the pipeline would be buggy and different from the actual json u see in pipeline ui.

What this translate to if u were to use said repo to deploy to prod or as backup your pipeline will have issue (ie show blank when u enter the UI in target)

Theres some activity that avoids this like set variable and invoke pipeline activity. One way around it currently is that i put said affected activity in a separate pipeline and call the pipeline activity instead

A Database was established in a Fabric workspace many months ago, and has been used every day since, mainly by a nightly scheduled Pipeline. Since the night of 15/10/2026 (AEDT) I get this error when I try to access it:

 The server principal <my email> is not able to access the database "" under the current security context.

My account is still in an Entra group with workspace admin rights, and I remain the owner of the database. Other users in the Entra group can access the Database with no errors.

Any pointers?

I started support case TrackingID#2610180030000362 a few days ago, but there hasn't been any resolution so far.

Hello Everyone

Has anyone tried to duplicate the existing semantic model connected in composite mode (Import + Direct lake) from one workspace to another via UI functionality (not via notebook)

If yes please let me know the steps

Do we know when Fabric apps will be available in the UK South?

Title: Power BI Embedded – 403 Error: Embed Token Limit Exceeded on Pro/Shared Capacity – Guidance Required on Fabric F2 vs. Embedded A SKU

Product: Microsoft Power BI / Power BI Embedded / Microsoft Fabric

Issue Type: Technical Support – Embedded Analytics and Capacity Configuration

Problem Statement

We are implementing Power BI embedded analytics within our internal business application, BI Analytics Platform, to provide reports and dashboards to external customers through our application.

Our current setup uses Power BI Pro licenses. When our application attempts to generate an embed token, the API returns the following error:

HTTP Status: 403 – InvalidRequest

Error Message: “You have exceeded the amount of embed token that can be generated on a shared or ProPlus capacity. You need to purchase Azure capacities to generate embed tokens.”

This is preventing us from reliably displaying Power BI reports within our application.

Current Architecture and Requirements

Power BI reports are embedded inside our application using an application-controlled embedding flow.

External customers are expected to access reports through our application; direct access to the Power BI Service is optional.

Power BI Pro licenses are currently used for report development and publishing.

Report access is required primarily during business hours.

We are evaluating Microsoft Fabric F2 capacity as a budget-conscious option for production embedding. We are also considering Power BI Embedded Azure A SKUs.

Additional Observation

We have identified a possible workspace configuration mismatch in our application logs:

Workspace ID used by the report at runtime: 16d5170b-9312-4978-9b1e-58fef73089a0

Workspace ID recorded in our application catalog: 49e91424-…

We need to verify whether the report and its semantic model are located in the expected workspace and whether the correct workspace is assigned to the relevant capacity.

Support Questions

Is Microsoft Fabric F2 capacity supported for production Power BI embedding using the app-owns-data approach, where external customers view reports through our application without individual Power BI licenses?

What are the practical limitations of F2 capacity for embedded Power BI reports, particularly around concurrent users, report interactions, semantic model size, refresh operations, and throttling?

For our use case, would Fabric F2 or Power BI Embedded Azure A1/A2 be the more appropriate starting point? Please clarify the technical differences and relevant licensing requirements.

Can an F2 capacity be paused outside business hours and resumed automatically before business hours? Are there any limitations or additional considerations for embedded reports and token generation?

Does assigning the workspace containing the report and semantic model to the correct eligible capacity resolve this type of embed-token error, assuming the workspace configuration and permissions are correct?

What diagnostic steps should we perform to distinguish a capacity/token-limit issue from a workspace mismatch, permission issue, or incorrect embed-token configuration?

Assistance Requested

Please provide the recommended production architecture and minimum suitable capacity for our scenario, along with any official Microsoft documentation covering the applicable licensing, capacity requirements, and embed-token limits.

We would also appreciate guidance on validating our workspace configuration and estimating whether F2 is sufficient for an initial production rollout.

Thank you.

I have a DP-600 (Fabric Data Engineer) and an IT consulting company want me to associate my profile with them and be on the "bench" for opportunities to subcontract with them.

They want 30 day notice to unlink and want to pay $0 retainer. obviously I'm not accepting that. they get the benefits for Partner Capability Score and I get nothing this way.

Curious if people here have experience and range for such things.

does microsoft even accept linking subcontractors?

Hey Fabric folks!

I’ve been diving into Model Context Protocol (MCP) integrations with Fabric recently and love how fast it speeds up context-aware workflows and pipeline building

For those of you using Fabric via MCP:

1. Are you noticing real, measurable productivity gains in your daily workflows?
2. How are you handling review, testing, and data accuracy?

Since MCP lets you execute and generate so quickly, keeping data contracts tight and accuracy locked down is crucial. What does your QA / verification loop look like before hitting production?

Would love to hear your setups, workflow patterns, or any gotchas you've run into! the fabric mcp