u/frithjof_v

I'm a capacity Admin. I'm in the Admin portal. I can see that a workspace is in a Blocked state due to workspace level surge protection.

I click the cogwheel associated with this workspace and I see that the radio button choices are all greyed out: "Available", "Mission critical" and "Blocked". Blocked time remaining: 10 hours 15 minutes.

There is a green button: "Unblock and forgive workspace".

Clicking on the green button returns an error: "We couldn't apply changes. Please try again later or contact... Try a different action."

So I'm stuck.

How to unblock the workspace?

The capacity overall isn't throttled, it's less than 50%.

Thanks!

Hi all,

I'm considering a pattern for error handling in Fabric pipelines and I'm wondering if there are any documented limits I should be aware of.

The idea is that individual notebooks return a small JSON object via "notebookutils.notebook.exit()", for example:

{
"status":"failure",
"activity":"LoadSales",
"message":"Something went wrong"
}

The pipeline appends these to an Array variable:

[
  {"status":"success","activity":"LoadCustomer","message":"OK"},
  {"status":"failure","activity":"LoadSales","message":"Something went wrong"},
  ...
]

A final notebook receives the array, checks for failures, and raises a hard failure if any are found.

My questions are:

1. Is there a documented maximum size/number of elements for a Pipeline Array variable?

2. Is there a documented maximum size for a parameter passed from a Pipeline to a Fabric Notebook?

3. Are there any other limitations or gotchas with using this pattern?

I can see the documented 896 KB activity payload limit, but I haven't found a specific limit for Array variables or Notebook parameters.

I'm mainly interested in whether this would be a reasonable pattern for a reusable pipeline framework, assuming the messages themselves are kept small.

Thanks in advance!

Hi all,

Is there an easy way to trigger a second interactive run of the same pipeline, or do you need to use the REST API / a wrapper pipeline?

It seems like the Run button isn't available while an interactive run is already in progress.

I'd like to trigger two or more concurrent runs interactively, with some delay between each.

Thanks!

Hi all,

I use ABFSS paths in Fabric notebooks to read/write Lakehouses, and I prefer using display names rather than GUIDs.

For example:

abfss://accounting_test@onelake.dfs.fabric.microsoft.com/lh_business_central.Lakehouse/Tables/gold/fact_sales

instead of:

abfss://7f3a91c2-6d84-4e17-b2a9-91f4c8d73e52@onelake.dfs.fabric.microsoft.com/3b82d1a7-5f49-4c63-a921-8e76d4b19037/Tables/gold/fact_sales

All our workspace and Lakehouse names use "snake_case", so spaces/special characters aren't an issue.

I store the workspace name in Variable Library, so the same notebook code works seamlessly across Dev/Test/Prod.

The Lakehouse name is also stored in the Variable Library and referenced when generating ABFSS paths in the notebook. It's currently the same across environments, but this also handles the edge case of renaming the Lakehouse - which we don't expect to do.

I prefer names because they're much easier for humans - and AI - to reason about. If I see "accounting_test/lh_business_central", I immediately know what it is. This is very convenient for a code review or being onboarded to a new project. A GUID tells me nothing without looking it up - which is too time consuming.

I know the main argument for GUIDs is that they survive renames. But are there other practical downsides to using names?

I'm curious what others do:

• Do you use names or GUIDs in ABFSS paths?

• Have name-based paths caused problems for you?

• Are there CI/CD, cross-workspace, permissions, or other scenarios where GUIDs are materially better?

• Are there pitfalls to using display names even with a strict snake_case naming convention?

  • Fabric enforces unique Workspace names within a tenant, and unique Lakehouse names within a workspace, right? So we could never experience path ambiguity.

My current thinking is: use names - not GUIDs, because the readability of names is superior.

Is this robust, or am I missing something?

Thanks in advance!

Didn't see any other posts about it here, so thought I would share: https://community.fabric.microsoft.com/t5/Fabric-Updates-Blog/Fabric-Runtime-2-0-Generally-Available/ba-p/5326359

Hi all,

We have a use case where we need to get the data from an Azure SQL Database exactly as it was at the end of each month?

Is the following a good plan?

• The DBA enables Temporal tables on the Azure SQL Database.

• We ingest the data from the Azure SQL Database into Fabric once a month, using a SQL query with FOR SYSTEM_TIME AS OF 'YYYY-MM-01 00:00:00' to capture the state at the end of the previous month.

  • We may need to join multiple source tables, I guess we just add the time travel clause to each table in the query.

I have no experience with temporal tables, neither has the DBA :) But it sounds like a nice feature.

Thanks in advance for sharing your thoughts and/or experiences with temporal tables as data source.

Hi,

I'm curious whether anyone from Microsoft has shared plans for supporting User Assigned Managed Identities (UAMI) in Fabric alongside Workspace Identity.

Workspace Identity is a great addition, but I think UAMI could complement it rather than replace it.

Some advantages of UAMI would be:

• A single identity could be shared across multiple workspaces.

• An identity could be scoped more narrowly than a workspace, for example to a specific item or even a single folder within a Lakehouse.

• Greater flexibility overall, since the scope could be either broader or narrower than a Workspace Identity.

  • Similar to how SPN provides more flexibility than WI today.

  • Benefit of UAMI over SPN: no credentials to handle.

It would basically provide the same flexibility as an SPN, just without the credentials.

Some scenarios where I think UAMI would be useful:

Project identity

• A project often spans multiple Fabric workspaces (for example, Engineering, Store, Integration, Presentation).

  • Instead of granting permissions to multiple Workspace Identities, a single UAMI could represent the entire project.

• Data source owners would only need to authorize one identity, and additional workspaces could reuse it without requiring new access requests.

Granular ETL identities

Imagine a workspace containing data for several departments or business units.

The ETL pipeline branches into multiple identical flows, each responsible for a different department.

Each branch (or downstream semantic model) could authenticate using its own UAMI.

OneLake security could ensure each identity only has permission to read its own Gold data, enforcing least privilege through the identity itself rather than relying solely on ETL logic.

Hi,

Today we receive an email from Microsoft whenever our Fabric capacity reaches 100%.

The problem is that 100% isn't necessarily an issue. For example:

• A brief spike in interactive Power BI usage can temporarily push the capacity above 100% without causing throttling.

• We then have to manually open the Capacity Metrics app (no link in the email) to see whether it was just a short-lived spike or whether the capacity is actually close to being throttled.

So I'm wondering:

• Can alerts be triggered on events like At Risk of Throttling or actual throttling instead of just 100% utilization?

• Is it possible to include more context in the email (e.g., interactive vs. background usage or proximity to throttling) so we don't need to open the Capacity Metrics app every time?

How are others handling this?

Thanks in advance

My organization has an API hosted in Azure and protected by Microsoft Entra ID. Is it possible to use a Fabric Workspace Identity to authenticate against this API?

With Azure Managed Identities, this can be done by requesting an access token for the API's audience/resource. How would I do the equivalent with a Fabric Workspace Identity?

Is the only supported approach in Fabric today to use a Service Principal with the Client Credentials flow, or is there a way to use Workspace Identity for this?

Also, is support for using Fabric Workspace Identities with custom APIs something that is on the roadmap?

Thanks in advance for your insights!

Related Ideas, please vote:

• https://community.fabric.microsoft.com/t5/Fabric-Ideas/Enable-Azure-Resource-Manager-ARM-API-Authentication-Using/idi-p/5142197

• https://community.fabric.microsoft.com/t5/Fabric-Ideas/Support-Fabric-Workspace-Identity-for-custom-APIs/idi-p/5322919

Hi,

I'm seeing what appears to be inconsistent behavior when deploying a Fabric Data Pipeline using fabric-cicd, and I'm wondering whether this is a bug or an unsupported scenario.

Our setup is:

• The pipeline contains a Notebook activity.

• The notebook uses a Workspace Identity connection.

• The deploying identity is a Service Principal.

• The SPN is a member of an Entra ID security group.

• That security group has User permission on the Fabric Connection (configured in Manage Gateways and Connections).

The deployment fails with:

• «User does not have access to the connection used in the Pipeline.»

However, if I grant the same SPN direct User access to the connection (instead of through the security group), the deployment succeeds immediately.

So the only difference is:

• SPN -> Entra ID security group -> Connection (User) -> deployment fails

• SPN -> Connection (User) -> deployment succeeds

The Manage Gateways and Connections UI allows assigning security groups to connection permissions, so I expected this scenario to be supported.

Has anyone else run into this?

I'm trying to determine whether:

• security groups are actually unsupported for connection authorization during fabric-cicd deployments,

• this is a known bug in fabric-cicd or the Fabric deployment APIs, or

• there's some additional configuration required for group-based permissions to be recognized.

Are you able to use Security Groups to successfully share connections with the SPNs that deploy items using fabric-cicd? Or must the connection be shared directly with each SPN?

I'd love to use a Security Group for sharing Workspace Identity connections with SPNs.

I would add all the fabric-cicd deployment SPNs to a Security Group, and share the Workspace Identity authenticated connections (notebook connection, pipeline connection, etc.) with that Security Group. Instead of adding all SPNs individually to the WI connections. But the Security Group approach seems to fail when attempting to deploy a pipeline.

Any experiences or official documentation would be much appreciated.

Hi all,

One thing that annoys me with the Variable Library integration in OneLake Shortcuts is that we need to manually update the Lakehouse after changing a variable value in the Variable Library, a process which is described in the linked blog article.

I would prefer that the shortcut actually used the variable library value directly (resolve the value at query time), instead of keeping a cached version of the variable value - a cache that needs to be manually synced.

Is there at least an API to force this sync, or check the sync status? (I.e. check that the shortcut actually uses the current variable value)

Thanks in advance!

For example, when hovering over a table or a schema in the Lakehouse UI, I'd like to be able to see a tooltip description - made by the developer - about what the table or schema contains and what its purpose is.

I'd also like to have a tooltip description for workspace folders. It doesn't seem to be possible.

This metadata could also be visible to GitHub Copilot when doing agentic development of the project.

Hi,

I sometimes use a pattern where default values are defined in a Variable Library, and when doing an interactive pipeline run I can override the defaults by explicitly entering parameter values - otherwise, just leave the parameter input boxes blank to use the defaults (variable library). This is achieved by using @coalesce(parameter, variable library) in the pipeline activities. If the parameter is blank, the activity will use the variable library.

However, for any datatype except String type, the parameter input boxes show as Required in the run pipeline UI when triggering a manual run.

Although, they're not actually Required, because just clicking "Ok" - without entering any value for the so-called Required parameters - also works.

Why do these parameters show as Required when running a pipeline interactively?

It's confusing - and I want the parameters to be optional.

Thanks in advance!

Hi all,

I'm working on a Disaster Recovery plan for a solution built in Microsoft Fabric, which uses OneLake as the storage layer.

OneLake is Fabric's default storage layer - an abstraction built on top of Azure Data Lake Storage.

By default, Fabric and OneLake uses Availability Zones (ZRS) for redundancy.

Cross-region BCDR (aka geo-redundant storage) is available for OneLake as an opt-in feature at an additional cost.

My questions:

• Has there ever been a disaster/situation in Azure where cross-region duplication (GRS/GZRS) was needed to avoid permanent data loss in Availability Zone (ZRS)-enabled regions, or has GRS/GZRS only been required for near-continuous availability so far?

  • What is the longest known duration that data using ZRS has been unavailable?

Thanks in advance!

Additional context: As I understand it, Fabric's opt-in, cross-region BCDR purely covers files and folders in OneLake - not Fabric infrastructure.

The arrows seem to indicate a semantic model being used as the data source for

• Real time dashboard
• KQL query set

https://preview.redd.it/ds1agx8hzz9h1.png?width=1038&format=png&auto=webp&s=93fa8b8b1018386a186a63ddc2b451d07f233386

https://learn.microsoft.com/en-us/azure/well-architected/microsoft-fabric/overview#architecture-pattern

Is that possible?

Seems wrong to me.

Is it mainly a matter of priority or are there specific reasons not to include these settings in Git integration?

I would pretty much like to control all workspace settings and semantic model settings through Git / Variable library.

Is there planned work to make more workspace and item settings version controlled through Git integration - and parameterizable through Variable Library - or are there specific reasons why that would be a bad idea?

Thanks in advance for your insights!

Hi all,

I'm looking for your input and real world experiences.

Case (updated description):

I'm tasked with ingesting data daily into a Microsoft Fabric Lakehouse (medallion architecture).

The data source is a new operational app built on Azure SQL Database.

The Azure SQL DB will have ~50 tables with relatively lightweight rows (~30 columns, no large text/blob fields).

The app team owning the Azure SQL DB plans to use hard deletes only, with no CDC, no soft deletes.

• Is this still common in 2026?

• Would you push back on this?

  • If yes - how hard would you push back?

• When does daily full copy from source become unrealistic (10M / 100M / 1B rows)?

Thanks in advance!

Is there an expected sync period before the WI also gets deleted?

So far, it's been a few hours after deleting the Workspace, and the Workspace Identity still exists in Azure.

Thanks!