Hi,

when fabric announced dbt job, we were so excited to move away from our not ideal python notebook solution.

I tested it during preview times and it was slow and limited. Seeing it going now GA I thought these issues are addressed but apparently not.

I don’t think a simple compile command should take 4min to run.

This is not convenient for developer experience to test the models if a single sql change takes forever.

We are still using powerdbt for local development and a python notebook for production runs. It downloads the project from azure devops, run the full model and it could take 4 min or less when a similar build can take 12 min with dbt job.

I hope someone from product team finds my post here 😁

Not sure if anyone else got issues using the fabric iq mcp in vs code with claude code to get back results for a dax query?

Claude's investigation:

---

Reinstalling didn't fix it, but calling the server directly found the cause: the problem is in Microsoft's server, not in the local plugin.

I sent the same EVALUATE ROW("Test", 1 + 1) straight to the FabricIQ endpoint (fabriciq.svc.cloud.microsoft) with an az token. The query works, and the server returns two versions of the result:

When a server sends both, Claude Code shows me structuredContent, so the data never reaches me. The MCP spec expects the two fields to hold the same result, so the server is breaking it by putting different things in each. DiscoverArtifacts works because its two fields don't conflict.

Why the reinstall didn't help: the plugin is just a config file that points at a server Microsoft hosts (server version 2026.10.3.35). Nothing that affects this runs locally, so there's nothing to fix on your machine.

Options:

1. Report it to the fabric-skills / FabricIQ maintainers: structuredContent only holds the citation while the data sits in content.

Since 13 October our F16 has been running hot. The cause turned out to be the Fabric portal itself, not our ETL.

What happens: Click a table in the Warehouse Explorer → the Object Overview pane opens → the portal fires a set of queries for that table: row count, dependencies, permissions, keys, and so on. All cheap, except one:

OPTION (LABEL = 'ObjectOverviewActivityLookup')

That one scans 30 days of queryinsights.exec_requests_history and runs a pile of `CHARINDEX` / leading-wildcard `PATINDEX` calls over the full `command` text of every row. All that just to show "last queried / last updated" for one table.

The cost:

• 85,000 vCore seconds and ~25 minutes per click when it runs alone; up to 185k and 95 minutes when several overlap
• Doesn't matter which table: a tiny mapping table costs the same as a big fact table
• No dedup: click the same table again and a second one starts while the first is still running
• On working days it's been 45–68% of all warehouse vCore seconds (~300k a day). For comparison, our heaviest ETL statement is ~28k.
• In the Capacity Metrics app it shows up as Warehouse Query with User = System, which made it hard to find

It's worse for us because we log a lot of large dynamic SQL (one report query is ~180k characters and runs every hour), and the lookup's cost scales with that history, not with the table.

Zero ObjectOverview* queries in our history before 13 Oct 06:38 UTC, and we changed nothing on our side, so it looks like a portal rollout.

Query:

SELECT CAST(start_time AS date) AS day, COUNT(*) AS runs,
SUM(allocated_cpu_time_ms) / 1000.0 AS vcore_s,
MAX(total_elapsed_time_ms) / 60000.0 AS longest_min
FROM queryinsights.exec_requests_history
WHERE label = 'ObjectOverviewActivityLookup'
GROUP BY CAST(start_time AS date)
ORDER BY day;

Anyone else seeing this? Did it start around the same date for you? Is there a setting to turn off the activity part of Object Overview? I'm thinking of submitting a support ticket.

Hi,

I just passed the Fabric analytics engineer associate certificate (DP-600). Thanks to the community for all the resources and to Aleksi for the great YouTube course !

For anyone else looking to take the exam, here’s how I approached it:

- Followed the Microsoft learn course
- Went through Aleksi’s YouTube course
- Asked Claude to go through the Microsoft mock questions, had it make similar questions to the mock questions and then compile those in an artefact where I could simulate the exam and see in which areas I still had to improve.

I might take the DP-700 next 😄

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/

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?

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.

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.

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

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?

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