Power BI REST + PowerShell parity without Tenant Admin
Summary Item‑level APIs/cmdlets so engineers can automate what the UI can do without requiring Tenant Admin scopes. Problem Key actions (e.g., sensitivity labels) are admin‑only via REST; others lack item‑level endpoints. Ownership/permissions and structured deployment need elevated roles or manual UI. This blocks least‑privilege automation. Proposed solution - Item‑scoped endpoints/cmdlets to: - **Set/Get item permissions** on paginated reports. - **Set/Get sensitivity labels** at item scope (honor label policy) without admin. - **Create/list/move to folders** and deploy RDLs to them (see Folders idea). Acceptance criteria - A Service Principal with workspace **Contributor** can set a paginated report’s permissions and sensitivity label via API (no Tenant.ReadWrite.All), and move/deploy it into a folder path. Impact Enables proper DevOps with least privilege; removes brittle manual steps.
Microsoft fabric CI/CD deployment using Azure DevOps
Scenario: We are planning to migrate Microsoft Fabric artifacts across tenants using Azure DevOps. I would like to understand the feasibility of this approach and identify which Microsoft Fabric artifacts can be migrated using an Azure DevOps pipeline. Migration Approach: We have two Azure tenants: Tenant 1 and Tenant 2. Tenant 2 has its own Azure DevOps Services environment. The requirement is to migrate Microsoft Fabric items from a workspace in Tenant 1 to a Microsoft Fabric workspace in Tenant 2. To achieve this, I am planning to: Configure Git Integration for the Fabric workspace in Tenant 1 using a Service Principal. Commit the Fabric artifacts to an Azure DevOps repository in a dedicated folder (for example, Fabric Artifacts) within a repository branch. Create an Azure DevOps YAML pipeline along with a Python script that dynamically deploys the artifacts from the repository into the target Fabric workspace in Tenant 2. Use the attached Python script to automate the deployment process. We currently have the following artifact types in the source Microsoft Fabric workspace. I would like to understand whether there are any limitations with this approach and if all of these artifacts can be migrated successfully using an Azure DevOps pipeline. Artifact Types Activator CopyJob DataflowFabric Environment EventStream GraphQL KustoDatabase KustoEventHouse Lakehouse MLExperiment MountedRelationalDatabase Pipeline SQLDbNative SynapseNotebook User Data Functions Variables Warehouse Dataset OrgApp PaginatedReport Report
Fabric Warehouse - Deployment Pipeline - Fix ALTER TABLE issue
Currently, when adding a column to a Warehouse table in Dev workspace, and then using Fabric Deployment Pipeline to deploy the Warehouse to Test and Prod workspace, the existing table gets dropped and recreated with the added column. Unfortunately, this leads to all existing data in the table in Test and Prod getting lost. Please fix this issue. I believe this issue is documented here: Currently, if you use ALTER TABLE to add a constraint or column in the database project, the table will be dropped and recreated when deploying, resulting in data loss. https://learn.microsoft.com/en-us/fabric/data-warehouse/source-control#limitations-for-deployment-pipelines
Pipeline CI/CD Improvement, Get Item ID activity from workspace ID and item name
Currently when following any branch strategy that requires a separate ephemeral feature (or other) workspace running a notebook from the same workspace requires too much ground work To find the ID of the notebook you need a way to call the APIs to GetItems in the workspace to find the correct ID of the notebook (or other item like the lakehouse), this is overly convoluted requiring API calls through web activity or separate notebook in a stand alone workspace with fixed ID that returns the item IDs in the pipeline's workspace Idea: add a pipeline activity that retrieves the item ID of an item using a workspace ID and item name or a function in pipeline expressions that allows the same to be done so this can be inlined without a dedicated pipeline activity.
Pre-Deployment Impact Analysis for Fabric Deployment Pipelines
Before deploying an artifact, Fabric should provide a complete dependency and impact analysis report. Features Show impacted reports, semantic models, notebooks, pipelines, and Lakehouses. Highlight breaking changes. Compare source and target environments. Identify deleted columns, measures, and tables. Generate deployment risk score. Benefit Prevents production failures and provides confidence before promotion.Enhance Fabric Deployment Pipelines with Environment-Aware Connection Rules for fabric CICD
Currently, Microsoft Fabric Deployment Pipelines do not fully support automatic environment-specific connection updates for Data Pipelines, Dataflows Gen2, Lakehouses, and Semantic Models. After promoting artifacts from Development to Test or Production, many connections continue to reference the source environment objects. For example: Data Pipelines continue pointing to the Development Lakehouse. Dataflows Gen2 retain references to Development data sources and destinations. Semantic Models built using Direct Lake (OneLake) continue referencing the original Lakehouse. Developers must manually update connections and dependencies after each deployment. This increases deployment effort and introduces the risk of errors and production issues. Proposed Enhancement Extend Deployment Pipeline Rules to support automatic connection mapping and environment-specific configuration updates for: Data Pipelines Dataflows Gen2 Lakehouses Warehouses Semantic Models (including Direct Lake / OneLake models) Notebooks and related dependencies Desired Capabilities Configure source-to-target artifact mappings once. Automatically replace Lakehouse references during promotion. Automatically update Dataflow source and destination connections. Automatically update Semantic Model Direct Lake connections. Support parameterized environment configurations. Centralized deployment rule management. Dependency-aware artifact remapping. Preview changes before deployment. Example When promoting from: DEV Lakehouse: Sales_DEV Semantic Model: Sales_Model_DEV To: TEST Lakehouse: Sales_TEST Semantic Model: Sales_Model_TEST Fabric should automatically update all dependent Data Pipelines, Dataflows, and Semantic Models to point to the corresponding TEST artifacts without requiring manual intervention. Business Benefits Reduces post-deployment manual rework. Minimizes configuration errors across environments. Accelerates CI/CD adoption in Fabric. Simplifies enterprise deployment processes. Improves governance and consistency. Enables true automated Dev → Test → Prod promotion. Reduces operational risk and deployment time. This enhancement would make Microsoft Fabric Deployment Pipelines significantly more enterprise-ready by providing comprehensive environment-aware connection management across all Fabric artifacts and dependencies.
Add Pre-Deployment Impact Analysis and Destructive-Change Warnings
Before deploying Microsoft Fabric items from Development to Test or Production, Deployment Pipelines should automatically perform a detailed impact analysis. The validation should identify: • Downstream reports, semantic models, notebooks, pipelines, and other dependent items that may be affected • Breaking schema changes, including removed columns or changed data types • Operations that could delete, truncate, or overwrite existing data • Missing connections, permissions, dependencies, or deployment rules • Configuration differences between source and target environments The results should be displayed with severity levels such as Information, Warning, and Critical. Administrators should be able to block deployments containing critical changes or require manual approval before proceeding. This feature would prevent broken reports, failed refreshes, and accidental data loss, making Fabric deployments safer and easier to manage.Fabric > Dataflow Gen 2 > Destination: Allow this to be a dataflow parameter like table name can be
I recently disovered parameters in dataflow which was a big unlock in organization/efficiency, but not being able to specify the detination dynamically (outside of very end table name) nullifies that features' usefulness by having to make at least one per lakehouse because of this. Please update the Destination UI to allow a Parameter to be selected for the lakehouse (including folder/schema/dbo) to be populated by a dataflow parameter.Automatically configure or deploy data source credentials as part of the Fabric CI CD process
Currently, Microsoft Fabric deployment pipelines support data source deployment rules for paginated reports, but this do not deploy or automatically configure data source credentials (including OAuth tokens or user authentication credentials) during deployment. This causes diffculty to automatically deploy the reports and manually had to update the source credentials.Fix the broken Diff Compare for Data Pipelines in Deployment Pipelines
The Compare view for Data Pipelines in Deployment Pipelines is all over the place. Nothing aligns between environments, even if there is no diff or only a small diff in reality. Please fix it - the Compare view works fine for other item types.