Fabric schedule as a separate item
I'm using pipelines with schedules. This works for me. But whenever I change a schedule, the pipeline appears as Uncommitted in the Fabric UI, and Source control tells me I've changed the pipeline. That may be true, but the pipeline itself didn't change. If I commit the change, it will go into the CI/CD process, and I risk promoting my schedule change from dev to production. And I'm very sure these two are different. So, would it be possible to either ignore schedule changes for Git? Or move schedules out of the pipeline and host them at the workspace level. That way, I can reuse them if I want, but I can also control the deployment between environments by excluding them.File level commit - Need the ability to edit the commit description
I tried the recently announce file level commit for Fabric items. One notable issue I have with the feature (testing this with a Fabric warehouse, I'm assuming this would hold true for other items): While I am able to pick files to commit to source control, I am unable to edit the commit description. The current commit has a generic message "Committing 1 item from workspace <workspace_guid>". To best make use of this feature, it would be helpful to be able to edit the commit description so I can clarify what is in the commit.
Add the known commit ID by the "updates" subtab
Often I have a git commit that I want to sync into a fabric workspace, today I never know if the browser tab has actually picked up the latest commit or if it is going to throw an error on conflicts- this is especially true when there are many changes, it would just be nice to know which commit ID I'm about to merge/resolve prior to clicking the button so I know if I need to click refresh first.
Fabric Deployment Pipeline Should Automatically Preserve or Upgrade Semantic Model Compatibility
Category: Microsoft Fabric — Deployment Pipelines | Semantic Models | Direct Lake The Problem When deploying a Direct Lake semantic model containing calculated columns or calculated tables through a Fabric Deployment Pipeline (DEV → UAT → PROD), the deployment process resets the target model’s compatibility level back to 1705. This causes an immediate refresh failure in the target environment with the following error: “Changing the StringIndexingBehavior property requires model compatibility level 1707 or higher. The current model compatibility level is 1705. Upgrade the model and retry the operation.” This error occurs silently after every single deployment — meaning every promotion from DEV to UAT and UAT to PROD breaks the model until a manual fix is applied. Root Cause Fabric Deployment Pipelines do not carry forward or upgrade the semantic model compatibility level when deploying to a target workspace. The target model is always written at the default level of 1705, regardless of what level the source model is at. However, calculated columns and calculated tables in Direct Lake models require StringIndexingBehavior which is only supported at compatibility level 1707 or higher. This creates a guaranteed conflict on every deployment. Impact Affects any Direct Lake semantic model with calculated objects Breaks model refresh immediately after every deployment Requires manual intervention after every pipeline run Adds operational overhead and risk of human error in production deployments Cannot be resolved through the Fabric UI — requires REST API or external tooling to fix Current Workaround A PySpark notebook using the Fabric REST API must be run manually after every deployment to upgrade the compatibility level: python # Must run after EVERY deployment pipeline execution content.replace('compatibilityLevel: 1705', 'compatibilityLevel: 1707') This is a fragile, manual, error-prone workaround that should not be required in a production data platform. Requested Fix We are requesting that Microsoft implement one or more of the following: Option 1 — Preserve compatibility level during deployment The deployment pipeline should read the source model’s compatibility level and apply the same level to the target model after deployment. Option 2 — Auto-upgrade compatibility level If the target model’s compatibility level is lower than required by the model’s objects (e.g. calculated columns require 1707), the pipeline should automatically upgrade the target before completing the deployment. Option 3 — Add compatibility level as a deployment rule Allow users to set a deployment rule for compatibility level — similar to how data source rules and parameter rules work today — so teams can configure the target level per environment. Option 4 — Surface a warning and prompt If the deployment would result in a compatibility level mismatch, surface a clear warning in the pipeline UI and prompt the user to upgrade before completing. Expected Behaviour After a successful deployment pipeline run, the target semantic model should be immediately refreshable without any manual post-deployment steps. Why This Matters As Microsoft Fabric becomes the enterprise standard for data platforms, organisations are building automated CI/CD pipelines for their analytics workloads. A manual compatibility upgrade step after every deployment is incompatible with fully automated deployment workflows and undermines confidence in Fabric as a production-grade deployment platform. Please upvote this idea if you have encountered the same issue. The more votes this receives the faster Microsoft’s product team can prioritise the fix.
Control Schedule Activation per Environment in Deployment Pipelines
Currently, with the new multiple scheduler feature, we can define multiple run schedules for a Fabric item. However, when using deployment pipelines, there’s no way to control which schedules are active in Dev, Test, or Prod. This means schedules intended only for Prod must also run in Dev, consuming unnecessary compute. It would be very useful to allow using the Variable Library or deployment rules to set the active/inactive state of each schedule per environment, making deployments more efficient and flexible.
Display the Business Names in Power BI report when using ODBC connection to connect to Datasphere.
Currently we are only able to see the technical names displayed in Power BI when the Datasphere report is exposed to Power BI using the ODBC connection. It would be better if we have the option to display the Business Names from Datasphere Graphical views to make sure the renaming on the same can be ignored in Power BI .Do not deploy flag to alert users in Deployement pipeline
Hello. I have some notebooks that have differences between workspaces that I'm aware of, where it's by design. For example, I have a notebook creating a table in the attached lakehouse with unique info for each workspace it's residing in. Some values are hardcoded when they are not easily available with system variables, like the current workspace name. Then I'm able to use this table for my process. But in my deployement pipeline, it will always tell me that my notebook is "Different from source", while I know that, as it's by design, and I would like to flag this item to "Do not deploy" / "Do no check for differences", so that it's not always included in the difference comparison and doesn't alert me for that. Thanks
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.
