Add REST API to Take Ownership of Fabric Pipelines
When using service account to automatically deploy Fabric pipelines from Dev workspace to upper environments, the owner of pipelines in target envionment remain unchanged. In some situations, personal account has made logged in and PL's owner maybe transferred to the personal account, eg. click on "Update All" to resolve source control conflict; When owner of the PL is under personal account instead of service account, it causes issue when running it, since personal account won't have permission to perform the defined tasks. If take over ownership of Fabric pipeline is available, it will be very helpful to automatic the deployment process. Which can reset all pipelines in target environment to the service account, to ensure PLs are run under the service account.
Schedule pipeline as Service Principal
It would be beneficial to be able to specify an anonymous sp or user account while creating a schedule to run a pipeline directly in the Fabric GUI. This is currently only possible via the rest api and an external scheduler. Ti would be nioce to have run as sp , enterprise app or user option.Fabric Workspace Operator Role for Pipeline Monitoring and Rerun Operations
Many organizations have dedicated production support and operations teams responsible for monitoring Microsoft Fabric pipelines and responding to failures. Currently, the available workspace roles are Admin, Member, Contributor, and Viewer. While Viewers can monitor content, they cannot rerun failed pipelines. Contributors can rerun pipelines, but they also have permissions to modify pipeline definitions and other workspace artifacts. This creates a governance gap for enterprises that require segregation of duties between development and operations teams. Proposed Solution Introduce a new built-in Operator workspace role with permissions such as: Allowed View pipeline definitions Monitor pipeline runs and run history View execution logs and error details Manually trigger pipeline execution Rerun failed pipeline runs Cancel running pipeline executions Access workspace monitoring capabilities Not Allowed Create, edit, or delete pipelines Create, edit, or delete Fabric artifacts Modify notebooks, lakehouses, warehouses, or dataflows Manage workspace access or permissions Change workspace settings Connect/disconnect Git repositories Business Value This role would: Support enterprise segregation of duties requirements. Enable production support teams to resolve operational issues without granting development permissions. Reduce the risk of accidental changes in production workspaces. Improve governance and compliance. Align Microsoft Fabric with operational models commonly used in enterprise data platforms. Many organizations need a role that sits between Viewer and Contributor, providing operational control without development privileges. An Operator role would significantly improve security, governance, and supportability for Fabric Data Factory workloads. Use Case: Production support team monitors Fabric pipelines, investigates failures, and reruns failed executions, but should not be able to modify pipeline definitions or other workspace assets.
Schedule Data Pipeline to run as a Service Principal
Please make a UI (user interface) option to schedule a Data Pipeline to run in the user context (security context) of a Service Principal instead of my personal user. This should also have the effect that any Notebooks within the Data Pipeline are run in the security context of that Service Principal.📉 How Would You Investigate a 20% Drop in Revenue?
A data analyst shouldn’t stop at identifying what happened. The real questions are: Where did the decline occur? → Why did it happen? → What caused it? → What should we do next? By analyzing regions, products, customers, time periods, and key business metrics, raw data can reveal the root cause behind the numbers. Good data analysis turns numbers into decisions. 📊 #DataAnalysis #BusinessIntelligence #PowerBI #MicrosoftFabric #DataAnalytics
Support Service Principal for T‑SQL Notebook Execution
Make T‑SQL notebook execution fully compatible with Service Principals by removing or replacing internal OBO calls that reject SPNs. When pipelines or automated runs execute Fabric notebooks using a Service Principal (SPN), T‑SQL notebook cells can fail because internal Fabric calls use an on‑behalf‑of (OBO) authentication flow that does not accept SPNs. This breaks CI/CD, scheduled jobs, and automation that must run under non‑user identities. Request: Ensure T‑SQL notebook execution does not rely on OBO flows that reject Service Principals. Make notebook runtime APIs and internal calls accept Service Principals consistently. Publish clear documentation listing required permissions and recommended configuration for Service Principals when running notebooks. See error here: (Moving to Stored procedures is step backwards we want move forward with -t-sql notebooks for enterprise scale usage ) https://community.fabric.microsoft.com/t5/Data-Engineering/Fabric-Pipeline-T-SQL-Notebook-and-Service-principal/m-p/5139358#M15589
Allow Non-Breaking Schema Changes in Fabric CI/CD Deployments for Data Warehouse Objects
Hi, currently, Microsoft Fabric deployment pipelines can fail when a Data Warehouse deployment contains schema changes such as adding, removing, renaming, or modifying columns in existing tables. In environments where Data Warehouse tables already exist and CI/CD pipelines are used to automatically promote changes across Development, Test, and Production, this limitation becomes very important. For example, deployments can fail with errors similar to: DataLoss: The column is being dropped, data loss could occur. or ALTER COLUMN operation is not supported and deployment is blocked. As a result, even legitimate schema evolution scenarios require manual intervention, preventing fully automated deployments and increasing operational risk. Requested Improvement Provide configurable deployment options for Data Warehouse schema changes, such as: Allow schema evolution during CI/CD deployments. Support automatic handling of column additions, removals, and data type changes when explicitly approved. Introduce deployment settings to ignore or accept "data loss" warnings. Provide deployment modes similar to DACPAC publishing options available in SQL Server tooling. Offer pre-deployment validation and impact analysis without completely blocking the release. Business Impact This limitation significantly reduces the effectiveness of Fabric CI/CD pipelines for enterprise environments, where schema changes are a normal part of application and data platform lifecycle management. Without support for controlled schema evolution: Automated releases become unreliable. Manual production interventions are required. DevOps adoption is slowed down. Development, Test, and Production environments can become inconsistent. Supporting controlled schema changes would greatly improve Fabric's enterprise readiness and align deployment capabilities with modern DataOps and DevOps practices. Schema evolution should not require manual intervention in enterprise CI/CD deployment pipelines. Thank you for your support. I sincerely hope this limitation can be addressed, as it represents a significant challenge for organizations implementing automated CI/CD deployment processes with Microsoft Fabric.Allow Non-Breaking Schema Changes in Fabric CI/CD Deployments for Data Warehouse Objects
Hi, currently, Microsoft Fabric deployment pipelines can fail when a Data Warehouse deployment contains schema changes such as adding, removing, renaming, or modifying columns in existing tables. In environments where Data Warehouse tables already exist and CI/CD pipelines are used to automatically promote changes across Development, Test, and Production, this limitation becomes very important. For example, deployments can fail with errors similar to: DataLoss: The column is being dropped, data loss could occur. or ALTER COLUMN operation is not supported and deployment is blocked. As a result, even legitimate schema evolution scenarios require manual intervention, preventing fully automated deployments and increasing operational risk. Requested Improvement Provide configurable deployment options for Data Warehouse schema changes, such as: Allow schema evolution during CI/CD deployments. Support automatic handling of column additions, removals, and data type changes when explicitly approved. Introduce deployment settings to ignore or accept "data loss" warnings. Provide deployment modes similar to DACPAC publishing options available in SQL Server tooling. Offer pre-deployment validation and impact analysis without completely blocking the release. Business Impact This limitation significantly reduces the effectiveness of Fabric CI/CD pipelines for enterprise environments, where schema changes are a normal part of application and data platform lifecycle management. Without support for controlled schema evolution: Automated releases become unreliable. Manual production interventions are required. DevOps adoption is slowed down. Development, Test, and Production environments can become inconsistent. Supporting controlled schema changes would greatly improve Fabric's enterprise readiness and align deployment capabilities with modern DataOps and DevOps practices. Schema evolution should not require manual intervention in enterprise CI/CD deployment pipelines!! Thank you for your support. I sincerely hope this limitation can be addressed, as it represents a significant challenge for organizations implementing automated CI/CD deployment processes with Microsoft Fabric.Support dbt --vars in the dbt job and in the pipeline dbt activity
The sink of a dbt job (warehouse or lakehouse) can already be configured per environment through Variable Libraries. The source cannot. The source name must be written directly in sources.yml, and our lakehouses have different names in DEV, QA, PP, and PROD. The dbt project therefore cannot be environment-agnostic, which breaks the "one artifact, many environments" model that Fabric promotes. dbt solves this with the --vars flag and the var() function, but Fabric does not expose it. Request: Support vars when the dbt job runs, so var() works inside models and sources.yml. Add a vars input to the dbt activity in Data Pipelines, with dynamic content, so values can come from pipeline parameters or Variable Library variables. Result: one dbt project and one pipeline for all environments, with sources and sinks both driven by Variable Libraries.Support dbt vars in Fabric dbt job item and Data Pipeline dbt activity
Problem The dbt job in Fabric can't be made environment-agnostic. The sink (target warehouse or lakehouse) is already configurable through Variable Libraries, so the same job definition can be promoted through DEV -> QA -> PP -> PROD. The sources are not. sources.yml has to contain the literal name of the source warehouse/lakehouse, and there is no way to inject a value into it from a variable library or from the pipeline. Our lakehouse/warehouse names differ per environment, so we can't hardcode them. The dbt project is no longer environment-agnostic, which breaks the deployment model Fabric promotes (one artifact, many environments, differences handled by Variable Libraries). dbt already has the mechanism for this: the --vars flag, read in the project through var() and usable inside sources.yml via Jinja. Fabric doesn't expose it, neither in the dbt job nor in the pipeline dbt activity. Proposal Support vars in dbt run (and the other dbt commands the job runs, such as build and test) in the dbt job item, so var() resolves inside models and sources.yml. Add a Variables (--vars) parameter to the dbt activity in Data Pipelines, accepting dynamic content, so values can come from pipeline parameters or Variable Library variables. Example sources.yml: sources: - name: bronze database: "{{ var('source_lakehouse') }}" Pipeline dbt activity: vars: {"source_lakehouse": "@{pipeline().libraryVariables.SourceLakehouse}"} Expected result: the same dbt project, the same job and the same pipeline run unchanged in every environment, with the source resolved from the Variable Library of that environment. Benefits One dbt project and one pipeline for all environments, no per-environment edits or branches of sources.yml. Source and sink configuration handled the same way, through Variable Libraries. Parity with how dbt works outside Fabric (CLI, dbt Cloud), which lowers the migration barrier for existing dbt projects. Enables other runtime parametrization: date ranges, full-refresh flags, filters for incremental runs.
