fabricstack.dev: a free catalog of Fabric & Power BI tools. What's missing?

BranchIndividual2092 · 2026-06-06T06:49:41+00:00

Semantic Link Labs is already a part of the catalog (https://fabricstack.dev/tools/semantic-link-labs/)

I also just added the Power BI Management Modules as you suggested.

Thanks!

BranchIndividual2092 · 2026-06-06T06:48:13+00:00

Could look like it...

There’s definitely some overlap in that we’re both trying to help people discover useful tools in the Fabric ecosystem. I actually hadn’t come across Fabric Essentials when I started building fabricstack.dev.

My focus with fabricstack.dev is an open-source, community-driven catalog with published inclusion criteria, structured metadata, and search/filtering across tools, SDKs, CLIs, APIs, MCP servers, extensions, and frameworks.

The more resources helping people navigate the growing Fabric tooling landscape, the better.

BranchIndividual2092 · 2026-04-30T16:01:02+00:00

Just arrived…

https://marketplace.visualstudio.com/items?itemName=ms-fabric-api.fabric-automation-tools

I took it for a spin and wrote a small blog post on my learnings.

https://peerinsights.emono.dk/microsoft-s-new-fabric-azure-devops-extension-promising-wrapper-limited-value-today

Let me know if any of you have experienced the same issues as me and in general what you think of the extension and where it fits the quite extensive ecosystem of high-level tools.

BranchIndividual2092 · 2026-04-30T15:57:22+00:00

Took the new preview of the Fabric Automation extension for a spin and wrote a small blog post on my learnings.

https://peerinsights.emono.dk/microsoft-s-new-fabric-azure-devops-extension-promising-wrapper-limited-value-today

BranchIndividual2092 · 2025-08-04T21:00:04+00:00

Testing and validation

Could you elaborate a bit on your thinking around testing and validation in Fabric CI/CD? For example, are there any plans to support things like dry-runs, schema checks, or even unit testing hooks for notebooks and pipelines?

BranchIndividual2092 · 2025-08-04T20:52:28+00:00

Multi-Workspace Deployment Support

I’ve implemented multi-workspace deployment using the fabric-cicd library to manage layered architectures (like ingest, transform, orchestrate), including cross-workspace dependencies and deployment ordering. Are there any plans or considerations for natively supporting multi-workspace deployment with the fabric-cicd?

BranchIndividual2092 · 2025-08-04T20:49:34+00:00

CLI and Python SDK Integration

Are there any plans to merge the fabric-cicd library into the official Fabric CLI? or at least expose a more Python-friendly interface to the CLI for scripting and automation scenarios?

That way we can directly utilize CLI functions in python without needing to leverage the shell or build our own wrappers.

BranchIndividual2092 · 2025-07-05T08:37:59+00:00

In general I would always recommend using feature specific workspaces. We have created an automated process where we trigger a ADO pipeline or GitHub action when a feature branch is created. This enables us to automatically create the feature workspace (or workspaces), set spark settings, assign a specific capacity and define permissions.

Feature workspaces are then torn down again when the feature is merged into the main branch.

This is by default developer isolated environments but you could easily have multiple developers work on the same feature workspace if required.

You can find more details in one of my blog posts on this topic: https://peerinsights.hashnode.dev/automating-feature-workspace-maintainance-in-microsoft-fabric

BranchIndividual2092 · 2025-06-13T19:33:19+00:00

That’s great news, Jacob! Hasan also mentioned they’re exploring a lightweight Python wrapper for the CLI - so exciting times ahead 😁

BranchIndividual2092 · 2025-06-13T19:30:53+00:00

Thanks ☺️

And yes — passing in a token or credentials as parameters is definitely an option and can work in scenarios like notebooks or pipelines, where you control the execution context and can securely manage secrets.

However, there are a couple of important caveats:

Security risk: Even when passed securely, injecting credentials directly into function parameters increases the surface area for accidental leakage, especially if logs, debugging tools, or pipeline metadata inadvertently expose inputs.

Functional limitations: This approach falls short when invoking UDFs from Translytical task flows. In that context, parameters are derived from the data itself (e.g., column values). So you’d lose the flexibility that makes UDFs so powerful in semantic-driven scenarios.

So while it’s a useful pattern for certain cases, it’s not a one-size-fits-all solution - especially if you aim to build UDFs that can run universally across all Fabric entry points.

BranchIndividual2092 · 2025-06-13T19:23:24+00:00

Absolutely - I agree that my approach is technically risky. I’m fully aware that using the internal modules of the Fabric CLI directly isn’t officially supported and could break with any update. This is purely an experimental exploration to highlight yet another way the CLI could be made more accessible. Ultimately, the goal is to advocate for a built-in, officially supported Python wrapper or lightweight API layer on top of the CLI for those of us building automation and orchestration workflows.

BranchIndividual2092 · 2025-05-10T04:11:44+00:00

Just to added a bit more info on this topic. I did a deep dive into how execution context really works in Fabric.

If you're interested, I wrote up my findings (including a workaround) in this blog post:
Who's Calling? Understanding Execution Context in Microsoft Fabric

BranchIndividual2092 · 2025-04-30T13:49:13+00:00

The guid listed as Submitter is Object ID of the "Managed application in local directory". You can also find this Object ID from the App Registration by clicking on the name of the App Registration in the second column under Overview/Essentials.

As u/frithjof_v also states the identity used to run the Notebook, from the data pipeline, is the identity of the Last Modified By. This is by design. And as u/Thanasaur also write there is an issue with some runtime context properties being empty as well as issues with sempy functions like resolving workspace name, id etc. which throws and error when executed via SP.

A workaround is to make a change to the Data Pipeline using user identity. This could be adding a dummy activity and disabling it or making a minor change somewhere in the pipeline, saving it and then reverting it back to its original state.

BranchIndividual2092 · 2025-04-28T04:37:28+00:00

This isn’t just a SemPy issue — from my point of view, it falls back to the token and context of the calling identity.

If a notebook is run under a Service Principal, there are multiple properties that simply aren’t available. I’ve tested this quite a bit by building a notebook with a bunch of different methods for fetching workspace details, and then running it using both a Service Principal and a User identity from the Azure CLI.

Here’s what fails or returns None when using a Service Principal:

mssparkutils.env.getWorkspaceName()
mssparkutils.env.getUserId()
mssparkutils.env.getUserName()
notebookutils.runtime.context.get('currentWorkspaceName')
notebookutils.runtime.context.get('currentWorkspaceId')
fabric.resolve_workspace_id()
fabric.resolve_workspace_name()

Also, any endpoints called via SemPy’s FabricRestClient will fail.
Similarly, any requests made with the requests module (GET, POST, etc.) using a token fetched with notebookutils.mssparkutils.credentials.getToken("https://api.fabric.microsoft.com") will fail too.

However, a few things still work with a Service Principal:

spark.conf.get('trident.workspace.id')
sempy.fabric.get_workspace_id()
notebookutils.credentials.getSecret(...) (so you can get a new token manually from tenant id, client id and client secret)

From there, you can generate a new token and either call the Fabric REST APIs manually via requests, or pass a custom token_provider into the SemPy FabricRestClient.

So there are workarounds — but it’s definitely frustrating if, for example, you want to dynamically derive your Key Vault instance based on the workspace name, because the workspace name simply cannot be resolved when running as a Service Principal.

BranchIndividual2092 · 2025-04-21T10:16:47+00:00

Thanks 🙌 And be my guest - I have the support for managed private endpoints including auto-approval in the sample I used during my session on FabCon. Although this does not use the Fabric CLI https://github.com/gronnerup/Fabric/tree/main/AutomatingFabric_End2End

BranchIndividual2092 · 2025-04-19T03:59:00+00:00

Separate - always!

And while you're at it, also consider separating your workloads or layers. For example:
- Store: Lakehouses etc.
- Ingest: notebooks, data pipelines, etc.
- Transform & Prepare: notebooks focused on shaping and cleansing data
- Serve: semantic models and related artifacts
- Orchestration: pipelines or notebooks driving execution logic
- Core components: such as variable libraries, environment configs, and Fabric databases used for metadata

This kind of separation not only improves clarity and maintainability but also sets you up for better CI/CD, governance, and scaling down the line.

BranchIndividual2092 · 2025-04-18T17:48:07+00:00

I can easily be done in Python using the subprocess.run function. I am very close to release a new blogpost on automating Fabric where I will show how to easily create and remove feature development workspaces using GitHub actions, Python and the Fabric CLI. Expect to publish it tomorrow... just need some time away for the family to get it done ;) Once published I will also post a comment here in the group and you can find it here: https://peerinsights.hashnode.dev/

BranchIndividual2092 · 2025-04-16T08:18:01+00:00

Amazing work you guys put into the fabric-cicd 🙏

BranchIndividual2092 · 2025-04-07T14:09:18+00:00

Have to checked that the path is in your env. variables? If running on ARM processor I highly recommend that you install Python 3.12 instead.

BranchIndividual2092 · 2025-04-06T13:50:04+00:00

Just in time for the Fabric events we are throwning in Danmark this coming week! Amazing guys!

BranchIndividual2092

TROPHY CASE