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.
Allow personal bookmarks to be displayed on the report canvas
Please add a visual or extend the bookmark navigator to display the signed-in user’s personal bookmarks as a clickable list directly on the report canvas. Report viewers should be able to create and access their own saved views without needing report editing permissions or opening the Bookmarks pane. This would make it easier for customers to switch between their saved filter selections directly within the report.CoPilot for Power BI improvements
With the advent of AI - it's becoming a lot easier to visualize data by quickly generating HTML pages using CoPilot, than it is to do this using Power BI. It is time to stop insisting on the Workspace being included in a Fabric Capacity, to enable use of CoPilot in power BI. Even when the workspace is in a Fabric capacity - the CoPilot agent can't "see" any of the data - only the schema - so it's a lot less useful than it really should be. Even people who love Power BI are starting to code up web pages instead for near-instant visualizations - MS needs to make CoPilot more useful for Power BI Report Builders - and FAST. Suggest: For Power BI Workspaces: Let CoPilot in Power BI Work - with visibility limited to Schemas only. For Fabric Workspaces/Semantic Models: Make CoPilot in Power BI talk to the Fabric Data Agents by default, to ensure it can actually see the data as well. (It's also time to give Report Reader rights at something smaller than the F64 Capacity).
Allow multi-column conditions /output in Power BI Activator rules (Power BI visual-based alerts)
Description: When I create an Activator alert from a Power BI report visual, the rule can only evaluate the single column or measure it was created from, and the alert can only reference that same value. This blocks common governance and monitoring scenarios. Example scenario: I wanted an alert for Dev workspaces that sit on a billable (Premium/Fabric) capacity. That needs a condition on both Workspace Name (contains “Dev”) and Capacity/Billing type (not blank). Activator can’t combine the two in one rule, so I had to build the alert in Power Automate with a DAX query instead. Limitations: A condition can use only one column or measure, with no AND/OR across several attributes. The alert message or action can include only that same column. I can’t add related details like workspace name, dataset link, or owner. There’s no way to run a DAX query as the rule logic. Requested improvements: Conditions across multiple columns/measures (AND/OR). Selectable output fields, so the Teams or email action can include several columns, and dynamic links. Optionally, the ability to define the trigger with a DAX query, as the Power Automate “Run a query against a dataset” action does. Impact: Without this, governance and monitoring alerts need a separate Power Automate flow, which is harder to build and maintain than a native Activator rule.
Rule to force only HC Sessions while working with interactive notebooks
As a Fabric Platform Admin, I would like to force users of specific workspaces to only be allowed to spin-up and use High Concurrency (HQ) Sessions while working interactively with notebooks. This can help with best capacity utilization and faster notebook startups.
Org apps - Cannot be arranged in folders and do not stay hidden
Currently, Organizational Apps (Org Apps) are displayed in the standard Apps section of the Get Apps experience, alongside regular workspace apps. For organizations managing large-scale Power BI deployments, this creates navigation and discoverability challenges. **Current Behavior:** Org Apps appear mixed with regular apps in a single list, making it difficult for end-users to distinguish and locate organizational-level content, especially in environments with dozens of apps. **Requested Behavior:** Add the ability to display Organizational Apps in a separate, dedicated section within the Get Apps experience (similar to how Featured and Recommended apps are organized separately). This would: - Improve discoverability for org-level content - Create clear visual separation between user-scoped and organization-scoped apps - Enhance the app navigation experience at scale **Business Impact:** Organizations deploying large numbers of apps (particularly during migrations and multi-tenant rollouts with 100+ apps) would benefit significantly from dedicated Org Apps visibility. This is especially valuable for external-facing platforms serving multiple client organizations, where organizational apps serve as the primary content distribution mechanism. **Suggested Implementation:** Add a new collapsible "Organizational Apps" section in the Get Apps experience that displays all Org Apps separately from regular workspace-published apps. Admins should have the option to control this visibility via tenant or workspace settings. **Workaround:** Currently unavailable.Add a link to Fabric Capacity Metrics in Monitoring > Capacities
The new Capacities page in Monitoring is very useful. Thank you for this improvement. I would like to suggest adding a direct link to Fabric Capacity Metrics from the Monitoring > Capacities page. When investigating capacity utilization, I often need to switch from the Capacities page to Fabric Capacity Metrics for more detailed analysis. Having a direct link would make navigation easier and provide a smoother monitoring experience. It would also reduce the need to rely on a separately deployed Capacity Metrics app, which may require manual updates to access the latest version.📉 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
Have an uption to ignore delete for Database Mirror
We have a data source has regular data purge activities which will result data records be deleted. But I would still want to keep it downstream. Can there be an option for the individual databadse table mirror to have somthing like "Ignore delete" to not process delete for that table for the mirror operation?Fabric Apps: standalone URLs, mobile/tablet support and ALM for production use
Fabric Apps works well for building governed, data-driven web apps on top of semantic models. Several gaps still stop organizations from moving these apps from pilot to production. I'd like the following on the roadmap, with timelines published: 1. Standalone app URL outside the Fabric portal Deployed Fabric Apps currently open only inside the Fabric portal. Business users should be able to open an app from its own standalone URL, without the portal around it. This needs to work for apps connected to semantic models, including Direct Lake, while keeping Entra SSO and running queries as the signed-in user. Other things that would help: Custom domain support. A stable URL that doesn't change between deployments, so links shared from intranets and portals keep working. 2. Mobile and tablet support Many app consumers, especially executives, mainly use phones and tablets. Please: Make Fabric Apps available in the Power BI mobile apps for iOS, iPadOS and Android. Fully support Fabric Apps in mobile browsers. Document support for Intune-managed distribution, such as iOS Web Clips and Android managed web apps. This should cover SSO, Conditional Access and token refresh behaviour. 3. ALM and multiple environments Support Fabric App items in Git integration and deployment pipelines. Support non-interactive (service principal) deployment through the Rayfin CLI for CI/CD. Add an option to require a target workspace, so a deployment can't create a new workspace or land in the wrong one. 4. Enterprise security Support workspace and tenant private links, and outbound access protection. Document clearly that semantic model queries run as the signed-in user, so row-level and object-level security (RLS/OLS) apply. 5. Clarity on licensing and GA State whether app viewers need Pro or PPU licences on capacities below F64. Show Fabric Apps usage clearly in the Capacity Metrics app. Publish an expected GA timeframe and the planned support for other data sources, such as warehouse and lakehouse SQL endpoints. Why it matters: Today, teams have to work around these gaps with portal deep links, device-management web clips and manual deployment between environments. Closing them would let Fabric Apps serve as a real front end for enterprise analytics on every device.
