The Fabric community is upgrading!
We're excited to announce that the Microsoft Fabric Community will move to an upgraded platform experience beginning August 14, 2026. This upgrade is a major milestone that gives us a more modern, scalable foundation while enabling faster innovation and a better overall community experience. Most importantly, it positions us to respond quicker to feedback and continue improving the community over time. Why We're Upgrading The current platform has served us well, but it's built on an older architecture that makes it difficult to take advantage of modern technologies and deliver improvements at the pace we'd like. By upgrading to the latest platform, we're creating a more flexible, future-ready foundation that will allow us to: Deliver updates and enhancements faster Improve reliability and maintainability Respond more quickly to community needs Continue evolving the experience based on feedback What Members Can Expect The majority of the community experiences you use today will continue to be available after the upgrade, along with several improvements, including: A more modern and intuitive user experience Improved navigation and accessibility Enhanced filtering and content discovery Continued investments in performance and usability Updated Ideas statuses that provide clearer visibility into suggestion progress While a small number of enhancements will follow shortly after launch, this upgrade establishes the foundation for ongoing innovation and future improvements. RSS Feeds RSS feeds will continue to be available after the upgrade. As part of the upgrade, RSS feed URLs will change. RSS feed URLs are configured to automatically redirect to the new RSS feed URLs, so subscribers should continue to receive updates without interruption. Will my existing RSS subscriptions stop working? No. Exisitng RSS feed URLs will automatically redirect to the new URLs. Most users should not need to take any action. If you maintain custom automations or integrations that reference RSS feed URLs directly. Upgrade Timeline August 13, 2026 In preparation for the upgrade, any new support requests that the community managers need to process, such as username changes, email mappings, etc, will be paused started August 13th until after August 16th. August 14, 2026 | 7:00 PM PST Upgrade Begins The community will enter read-only mode while the upgrade is performed. During this time: Existing content will remain viewable New posts, replies, and content creation will be temporarily unavailable A maintenance page may be displayed during portions of the upgrade August 15, 2026 Validation & Stabilization Our team will validate key experiences, monitor platform health, and address any necessary stabilization work before reopening the community. August 16, 2026 Community Returns to Full Operation The upgraded Microsoft Fabric Community will be fully available to all members. Looking Ahead This upgrade is about more than technology. It's about creating a stronger foundation that allows us to move faster, deliver improvements more consistently, and build a better community experience for everyone. Thank you for your patience, support, and contributions to the Microsoft Fabric Community. We're excited for the future of Fabric and Power BI and look forward to building the next generation of the community together. Known Issues Post Upgrade We are aware there are a few minor issues after the upgrade. The team is actively investigating and working on fixes.
Fabric Capacity Cockpit: pause, resume and track the cost of your F-SKU from one window
Why I built it When my Fabric trial capacity expired, I moved my workspaces to a small pay-as-you-go F2. I use it for experiments and demos, not production, so the obvious way to keep costs down is to pause it whenever I'm not working with it. In practice, the information I need for that is spread across several places: Azure portal – capacity overview: status and pause/resume, but no cost Azure Cost Management: cost, but no status Fabric Capacity Metrics app: CU and storage usage, but neither cost nor status Workspace settings: which workspace is assigned to which capacity I wanted one small window that answers three questions at a glance (Is it running? What has it cost this month? Can I pause it now?) and does the pause/resume for me. The result is the Fabric Capacity Cockpit, now open source under the MIT license: 👉 https://github.com/Siebzehnundvier/FabricCockpit-GUI What it does Capacity picker: lists all Fabric capacities across all enabled subscriptions of the signed-in account. The list is cached, so the window is usable immediately while a fresh list loads in the background. Capacity info: name, subscription, resource group, region, SKU, state, provisioning state and month-to-date cost of the selected capacity. Cost split: the cost figure shows the OneLake storage share separately (e.g. 12.34 € (of which storage 0.87 €)), because that part keeps accruing while the capacity is paused. Pause / Resume: each action asks for confirmation, then shows live progress with an elapsed-time counter until the target state is reached. Auto-pause timer: choose 15, 30, 60 or 120 minutes. Two minutes before the deadline, a banner offers Pause now, Extend or Cancel. Tray icon: its colour follows the capacity state (green active, amber paused, blue transitioning). The right-click menu offers Open cockpit / Resume / Pause / Exit. Closing the window only hides it to the tray. Links: Azure capacity overview, cost analysis for the resource group, and your Capacity Metrics app. Log: every action and error is logged with a timestamp and can be copied to the clipboard. Under the hood The cockpit is plain Windows PowerShell 5.1 with WinForms, so it needs no installer, no compiled binaries and no admin rights. All Azure access goes through the Azure CLI: Capacity list, state, suspend and resume use the microsoft-fabric CLI extension (az fabric capacity ...). The cockpit installs the extension automatically on first start. Pause and resume are sent with --no-wait, and the state is then polled every 5 seconds. Without --no-wait, the CLI blocks until the operation finishes, which would freeze the UI. Cost comes from a Cost Management REST query at resource level, grouped by resource ID and meter. Stored-data meters count as storage; everything billed in CU counts as compute. Results are cached for 10 minutes, and throttling (HTTP 429) is handled with a retry. Sign-in and tokens are handled entirely by the Azure CLI. The tool stores no credentials. Its only local data is a settings file in %APPDATA%\FabricCockpit plus cost cache files in %TEMP%. There is no telemetry and no update check. I tested the state transitions (Paused → Resuming → Active and Active → Pausing → Paused) against Azure CLI 2.90.0 with microsoft-fabric 1.0.0b1. Getting started Install the Azure CLI and check that az --version works. Download the release zip from GitHub and unblock it (right-click → Properties → Unblock), then extract it anywhere. Double-click Start-Cockpit.cmd, click Sign in, and pick your capacity. Permissions: Viewing only: Reader on the capacity or resource group. Pause / Resume: additionally suspend/action and resume/action on the capacity, e.g. Contributor. Cost figure: Cost Management Reader. Without it, the field shows n/a and everything else still works. Before you pause anything The cockpit issues the same calls as the Azure portal, so the consequences are the same: Pausing makes every workspace on the capacity unavailable. Scheduled refreshes and pipeline runs fail while it is paused. Running work is aborted. The auto-pause timer does not check for running refreshes, notebooks or Spark jobs. Use it only on personal, dev or test capacities. Resuming starts billing immediately. OneLake storage is billed while paused. Reservations are not detected. If your capacity is covered by a reservation, pausing saves nothing. The cost figure is approximate. Azure cost data lags behind, typically can lag by a day or more. For invoices, use the portal. Trial capacities and Power BI Premium P-SKUs are not Azure resources and therefore don't appear in the list. How it was built I built the cockpit together with an AI assistant and verified the behaviour on my own capacity. The code is plain text and deliberately simple, so please review it before you run it in an environment with stricter policies. Feedback welcome This is version 0.52, a tool for my own daily use that I think others with small pay-as-you-go capacities might find handy. Issues, ideas and pull requests on GitHub are very welcome. I'd also be interested to hear how you manage pause/resume and cost tracking for your own capacities: automation runbooks, Logic Apps, or something else entirely?The Hidden Cost of the Data Swamp: Fabric Capacity Guardrails
Introduction: The Double-Edged Sword of Fabric Flexibility Microsoft Fabric has fundamentally revolutionized how enterprise data teams operate. By unifying data engineering, data science, data warehousing and Power BI into a single Software-as-a-Service (SaaS) platform, it breaks down silos and lets business users move at lightning speed. However, this democratization of data comes with a massive hidden risk. When workspace creation is unchecked and pipelines run wild, speed quickly transforms into a costly “data swamp.” Unlike traditional infrastructure where compute and storage are rigidly partitioned, Fabric pools your processing power into Capacity Units (CUs). If you don’t govern those capacities, runaway queries, poorly optimized Spark jobs and unmanaged workspace sprawl will quietly drain your cloud budget before finance even sees the bill. 1. The Anatomy of a Fabric Cost Explosion Cause-and-effect visualization demonstrating how unmonitored workspace sprawl and orphaned background pipelines drive sudden spikes in Capacity Unit (CU) consumption. How Cloud Costs Spiral Out of Control In a consumption-based SaaS model, expenses aren’t driven just by storage – they are driven by active compute. Without strict guardrails, organizations frequently run into three major financial traps: The “Noisy Neighbor” Problem: A single inefficient, ad-hoc DAX query or an unoptimized PySpark notebook running in a shared capacity can consume 100% of the processing power, throttling critical executive dashboards and slowing down the entire organization. Orphaned Pipelines & Infinite Loops: Automated data factories and pipelines left running by developers who forgot to turn them off after testing, continuously burning CUs over weekends and holidays. Unmonitored Sprawl: Business units spinning up independent workspaces without designated capacity assignments, causing unpredictable spikes when heavy reporting cycles (like month-end financial closing) collide. 2. Real-World Challenges: Why Monitoring is Hard Real-world operational challenges illustrated through capacity metrics app warnings and automated performance bottleneck notifications. Blind Spots in the Enterprise Managing compute costs in Fabric is uniquely challenging because responsibility is decentralized. Decentralized Ownership: When business analysts build and manage their own workspaces, they rarely think about the underlying cluster compute footprint. They care about insights, not core optimization. The Delayed Billing Shock: Because usage metrics update dynamically, teams often don’t realize a workload has choked the capacity until after the performance degradation has already impacted end users. Lack of Throttling Transparency: Without proactive alert mechanisms, teams are caught entirely off guard when Fabric automatically pauses or throttles operations due to capacity exhaustion. 3. Best Practices for Fabric FinOps and Capacity Governance Actionable three-step checklist highlighting core FinOps best practices for establishing sustainable capacity guardrails in Fabric. Taking Back Control of Your Compute Budget To keep your cloud bill predictable and your performance lightning-fast, you need to embed FinOps principles directly into your governance strategy. Isolate Workloads by Capacity Assignment: Never mix heavy data engineering Spark jobs with executive Power BI semantic models on the exact same capacity tier. Separate your development, test and production workloads to protect critical business assets. Master the Fabric Capacity Metrics App: Make it a non-negotiable weekly habit for administrators to review the Microsoft Fabric Capacity Metrics app. Look closely at your Interactive vs. Background CU consumption spikes to pinpoint which specific semantic models or items are dragging down performance. Set Up Proactive Alerting and Guardrails: Use Azure Monitor or built-in notification hooks to alert your administrators when capacity utilization hits dangerous thresholds (e.g., crossing 80% sustained usage), allowing you to intervene before automatic throttling kicks in. Enforce Workspace Lifecycle Policies: Automatically archive or clean up abandoned workspaces and semantic models that haven’t been queried in over 90 days, saving both storage and compute metadata overhead. 4. Conclusion: Turning FinOps into a Competitive Advantage The ultimate goal of Fabric FinOps and Governance – transforming an unpredictable data swamp into a secure, high-performance and economically sustainable analytics powerhouse. Governance in Microsoft Fabric isn’t just about security clearance lists and data privacy – it is about economic sustainability. By treating your capacity units as a finite, precious corporate asset, you protect your cloud budget from unexpected waste. When you combine robust workspace structuring, active Purview data labeling and diligent FinOps capacity monitoring, you turn your Fabric tenant from an unpredictable financial black hole into a predictable, high-performance enterprise analytics powerhouse. What about you? How is your organization currently keeping runaway Capacity Unit (CU) spikes and “noisy neighbor” workloads under control in Microsoft Fabric? Drop your strategies or biggest cost-management challenges in the comments below!My first Fabric App with write-back (dive log)
This blog post is for anyone interested in starting with Fabric Apps but unsure where to begin. I understand the feeling! Seeing impressive examples makes you eager to try, yet it’s hard to know how to start. I’ll show you how I built a Fabric App that reads data from an existing semantic model (like a Power BI report) and writes it back to a database. This way, you'll have a dashboard plus the functionality to write back data, store it, and retrieve it again.An introduction to Fabric Apps
One of the shiny new items in Microsoft Fabric is Fabric Apps, and these open up a bunch of possibilities for what is possible in Fabric. Fabric Apps enabled functionality that previously would have needed to be custom workloads, which are a lot more complex to get up and running than Fabric Apps. What is a Fabric App? A Fabric app (built on the Rayfin SDK) is a Fabric item with two components, a backend service for data access and authentication, and a front end web app. When a Fabric App is created, Fabric automatically creates a SQL Database, an authentication server, and static content hosting for the front end web app. You provide data models for your application in TypeScript and Fabric Apps automatically creates a database schema and type-safe GraphQL API. Before you can create one, a tenant admin has to enable it. It's still in preview, so it needs to be explicitly enabled, and Fabric Apps are not available in all regions. Fabric Apps are currently available in the following regions (As of August 18th, 2026): US - Central US US - North Central US US - West US US - West US 2 Europe - West Europe France Central Italy North Norway East Switzerland North UAE North South Africa North Asia - East Asia Asia - Southeast Asia Australia East India - Central India Japan East Korea Central To enable the preview in your tenant: 1. Sign in to the Fabric admin portal (https://app.fabric.microsoft.com/admin-portal). 2. Go to Tenant settings. 3. Under Enable Fabric App Items (preview), toggle it to Enabled, scoped to your whole org or specific security groups. 4. Select Apply. Give it a few minutes to propagate. If you don't see App (preview) in your New item list, either this is why or your capacity is in an unsupported region. Part 1: Create and Deploy the Sample App Create the item in Fabric Creating the item itself is the same as any other Fabric item: 1. Open a workspace where you have contributor or higher access. 2. Select New item. 3. Search for App (preview), select it, give it a name, and select Create. This creates the item, and all the backend services I mentioned before. From here, you can select a blank app, or start with a sample To-Do App, or a sample Data App. For the sake of this post, I am going to select the To-Do App. Once selected, Fabric will start to deploy your app and present you with some instructions for getting the Rayfin CLI up and running. Create the project with npm From a terminal, run the command shown in the Fabric App: npm create Microsoft/rayfin@latest -- "<appitemname>" --template todoapp --workspace <workspacename> That one command creates a full project from the `todoapp` template and wires it to the workspace and item you just created, using the Rayfin CLI. Then change your working directory to the project directory that was just created cd <your project directory> Run it locally npm run dev This spins up the frontend and backend together against your Fabric backend, so you can test changes before anything goes live. By default it runs at `http://localhost:5173`. Deploy with npx npx rayfin up Under the hood, `rayfin up` does six things in order: 1. It creates (or reuses) the Fabric App item 2. It retrieves the publishable key 3. It syncs your `rayfin.yml` settings 4. It applies the database schema from your TypeScript models 5. It builds and deploys static content, 6. Finally, it writes the deployment details back to `rayfin.yml` and a `.env.fabric-<workspacename>` file. When it finishes, you get a live hosting URL, a Fabric portal link, and a deployment ID. Tip: Want to check what a deploy will do without actually running it? Use `npx rayfin up --dry-run`. To check current deployment state at any time, use `npx rayfin up status`. Part 2: The Database Objects Here's the part that surprised me the most coming from a data background: there's no SQL to write, and no separate database designer to open. Your data models are TypeScript classes, and Fabric Apps turns them directly into database tables. Defining an entity Entities or tables live in `rayfin/data/` and use the `@entity()` decorator from `@microsoft/rayfin-core`, as well as field decorators for each column: Each table needs to be defined in it's own typescript file. import { entity, uuid, text, boolean, date } from '@microsoft/rayfin-core'; @entity() export class Todo { @uuid() id!: string; text() title!: string; text({ optional: true }) description?: string; @boolean({ default: false }) isComplete!: boolean; date() createdAt!: Date; date() updatedAt!: Date; } Every entity gets a UUID `id` primary key. If you don't include it in your entity definition, Fabric will automatically add it. When records are inserted into your table, Fabric will generated a UUID server-side unless you supply your own. Composite keys and custom key names aren't supported. The full set of field decorators: `@uuid()`, `@text()`, `@int()`, `@decimal()`, `@boolean()`, `@date()`, `@email()`, and `@set()` for enumerated strings. Modifiers like `{ optional: true }`, `{ unique: true }`, `{ default: value }`, and `{ min, max }` add constraints to the columns. Note: The TypeScript `?` optional marker only affects the compile-time type. To actually make a database column nullable, you need `{ optional: true }` in the decorator itself. Relationships If your app has more than one table, use `@one()` and `@many()` to define relationships, and Fabric auto-generates the foreign key column for you following a `{property}_id` convention. One-to-many and many-to-one are supported; many-to-many is not, so model it with an explicit join table instead. Registering the schema Once every entity has been created, they then need to be added to `rayfin/data/schema.ts`: import { Todo } from './Todo.js'; export type TodoAppSchema = { Todo: Todo; }; export const schema = [Todo]; Applying schema changes Whenever you add or edit an entity: npx rayfin up db apply If a change would drop a column or rename a table, the CLI blocks it and warns you first. You can override with `--force`, but know that as soon as you add --force, you will be making a destructive change that cannot be undone. Warning: Using `--force` on a schema apply can cause data loss and cannot be undone. After being deployed, you are able to see the database in your workspace under the Fabric App. The SQL Database child item will allow you to access the Fabric SQL query editor where you can run SQL queries to read data. Don't change things in SQL here, as anything you change will be overwritten the next time you deploy the schema. Wrapping Up This post covers creating the sample app, deploying it, and how the database objects work. The full version, including how authentication (local email/password vs. Fabric SSO) and the front end (the RayfinClient data calls) work, is on the blog, linked below. Microsoft Learn references: Create your first Fabric app (https://learn.microsoft.com/en-us/fabric/apps/create-app) | Fabric Apps project structure (https://learn.microsoft.com/en-us/fabric/apps/project-structure) | Define data models for Fabric Apps (https://learn.microsoft.com/en-us/fabric/apps/data-models) | Deploy a Fabric app to Fabric (https://learn.microsoft.com/en-us/fabric/apps/deploy-app) Read more: Read the full post, including the Authentication and Front End sections, on the Fabric Field Notes blog: https://www.fabricfieldnotes.ca/blog/2026/08/18/an-introduction-to-fabric-appsBeyond the Basics: Deep Dive into Microsoft Fabric Row-Level Security (RLS) & Purview Labelling
“Securing your data isn’t about locking it away – it’s about ensuring the right people see the right insights without compromising the rest.” In our previous beginner’s guide, we explored how to establish baseline governance, structure your workspaces and set up your core Admin Portal guardrails. If you fancy reading the previous beginner blog, you can refer it here. But once your data estate is up and running, you inevitably run into a critical next challenge: How do you handle data when different people are allowed to see different subsets of information within the very same table? Moving from basic visibility to active, granular protection is the hallmark of Stage 2 on the Governance Maturity Curve. In this deep dive, we’ll explore how to implement Row-Level Security (RLS) and enforce Microsoft Purview sensitivity labels through a visual journey.
Microsoft Fabric Reservations: Understanding What They Are and How to Create Them
Overview Over the past year, I’ve had the incredible opportunity to help Microsoft customers unlock the potential of Microsoft Fabric Capacities (FSKUs) by transitioning from Power BI Premium Capacities (PSKUs) or as they embark on their Fabric journey. During these engagements, we’ve tackled not just technical features, architecture design, deployment patterns, capacity planning, but also business considerations such as reservation purchasing strategies and scoping options to demystify how reservations work. Common questions I’ve frequently encountered are how to confidently navigate the reservation purchasing process, understand the scoping flexibility, and calculate consumption units effectively to maximize both value and efficiency. My hope is that this article will make your voyage smoother, offer clarity on these decisions, and empower you to make the most of your reservations when stepping into the world of Microsoft Fabric capacity planning!Governing the Flow: A Beginner’s Guide to Microsoft Fabric
“Governance is not about restricting access; it’s about providing the right access to the right people at the right time, while ensuring the data remains accurate and secure.” In the world of data, speed is often the enemy of stability. Microsoft Fabric is a powerhouse that allows data to move seamlessly from ingestion to AI, but without structure, that speed can quickly turn into “data sprawl.” Governance is the safety net that allows your team to innovate faster without fearing a security breach or a broken pipeline.The Auditor’s Toolkit: Reporting on Your Tenant
Your boss walks by your desk on a Friday afternoon with the dreaded question: “Can you give me a full audit of who has access to what in our tenant? I need to know every workspace and exactly who is in it.” You look at the clock. It’s 4:30 PM. Your weekend plans are already set and spending the next 48 hours manually clicking through the Admin Portal, taking screenshots and copying data into Excel is not on the agenda. The good news? You don’t have to.Fabric Cost Analysis - Shine a light on your platform costs
Want to make sense of your Microsoft Fabric spending? Discover how the Fabric Cost Analysis (FCA) solution empowers you to monitor, optimize, and clearly understand your platform costs. Developed by FinOps and Data experts, FCA offers a community-driven approach for deep financial and operational insights, robust architecture, and flexible analytics all powered by the latest Fabric capabilities. Get the clarity you need and join a growing community focused on smarter data platform management!
