Make production workspace items read-only (editable only via Deployment Pipeline, Git, or API)

[frithjof_v]

Please add a workspace-level toggle that allows the workspace admin to make all items read-only in the Fabric user interface.

With this setting enabled, items (such as notebooks, semantic models, dataflows, etc.) cannot be edited, created, or deleted manually via the UI. Instead, all changes must go through:

• Deployment Pipelines
• Git
• API

Ideal implementation:

A toggle in the workspace settings (e.g. “Make items read-only in UI”).

Only workspace admins can enable/disable this setting.

[frithjof_v]

I want to prevent unintended changes to items in production workspaces. Specifically, sometimes I want to open items in the prod workspace to inspect the code, but I don't want the risk of making unintended errors (or items saving themselves via auto-save while I have opened the item).

[frithjof_v]

To be clear: My intention is only to make the items' source code read-only in prod workspaces. I still want to be able to set up refresh schedule in the prod workspace, for example. But I don't want to be able to edit the items' source code in prod. That should only be done in dev.

[SJCuthbertson]

I like this idea and would use it if it existed today. This is a friction/pain area I also have. But it probably doesn't go far enough, in that the 4 defined workspace roles we have (Admin, Member, Contributor, Viewer) don't make nearly enough distinction between what in Azure is called "data plane" vs "control plane". @frithjof_v , I _think_ your idea here is essentially about toggling the definition of the Member and Contributor roles, to restrict them to (mostly) just the subset of their capabilities that could be described as "data plane" (doing things with data in LH/WH/EH etc), and negating (most of) the subset of their capabilities that are "control plane" (doing things with workspace objects). Is that fair? I suspect it's more fruitful to rethink that paradigm more broadly, and based on murmurs and comments I've seen, I think that might be on the way already, which might make this suggested toggle unnecessary.

[BEJCC]

Production is a read only workspace, therefore all members assigned to it have viewer role. Does not matter if the tenant setting is enabled or not everyone is viewer. Only admin user can edit hotfixes on production.

[yaronprigal]

Hi, why not try to use service principal? the service principal is the only admin in the prod workspace while all other users are only viewers? the only way to update the prod will be through automation process.

[frithjof_v]

Some activities in Fabric cannot be performed by Service Principal (SPN) and/or require manual interventions. E.g. Dataflow Gen2 requires manual interventions post deployment. Not all notebook functions are supported by SPN, but it's getting better (!). For advanced (pro code users), who avoid using Dataflow Gen2, it might be possible to do almost everything with an SPN, but in my experience there are still some blockers in Fabric support for SPN preventing us from relying 100% on SPN. Besides, Fabric is also being used by no code/low code developers who have a need to protect their prod workspaces as well. They may use notebooks for some ETL without being ready to go code-first for deployments and CI/CD. Other examples: Teams and Outlook activities in Pipeline are not supported by SPN. Lakehouse connection in Pipeline is not supported by SPN. SharePoint shortcuts are not supported by SPN. Fabric Deployment Pipelines are not really useful with an SPN - in order to use the UI and see diff comparisons you need to authenticate as a user. Thus, many times, there is still a real need to use a user account, due to limitations in SPN support across Fabric workloads. The support for SPN has improved and hopefully will continue to improve, making SPN, Workspace Identity (and perhaps also User Assigned Managed Identity) first class citizens. Bottom line: this idea will allow Fabric UI-assisted development (used by both "no code"/"low code" and often times pro code developers) to use a switch to lock a prod workspace's user interface to read-only - and also the ability to intentionally and temporarily unlock the prod workspace's user interface to edit mode in special situations where they have a temporary need to make manual adjustments in prod. And, even for pro code development, not all Fabric operations are currently supported by SPN, making user account intervention necessary sometimes, even when taking a code first approach.