Data Engineering Community Blog articles

Reassigning a Workspace in the Microsoft Fabric Admin Portal

abiola_david — Thu, 10 Sep 2026 13:38:41 GMT

Reassigning a Workspace in the Microsoft Fabric Admin Portal

When working with Microsoft Fabric, workspaces are an important part of organising and managing analytics content. A workspace can contain items such as Lakehouses, Warehouses, Notebooks, Data Pipelines, semantic models, and Power BI reports.

Depending on how a workspace is configured, it can be assigned to different types of capacity. There may be situations where a workspace that was originally running on a Power BI Pro shared environment needs to be moved to a Microsoft Fabric Capacity.

In this article, I'll show how to reassign a workspace to a Fabric Capacity using the Microsoft Fabric Admin Portal.

For this demonstration, I have a workspace named task wk, which is currently assigned to the Power BI Pro workspace type.

Current Workspace Configuration

I have already created the following workspace:

Workspace Name: task wk Workspace Type: Power BI Pro

At the moment, task wk is not assigned to my Fabric Capacity.

The objective is to move this same workspace from its current Power BI Pro setup and assign it to a Fabric Capacity.

Rather than creating a new workspace, I can simply reassign the existing workspace.

Open the Fabric Admin Portal

The first step is to open the Microsoft Fabric Admin Portal.

From the Fabric interface, open the settings menu and select Admin portal.

The Admin Portal provides administrators with tenant-level management capabilities, including the ability to manage workspaces and their capacity assignments.

For this task, I need to work with the Workspaces section.

Go to the Workspaces Tab

Inside the Fabric Admin Portal, select Workspaces.

This section provides a view of the workspaces available within the Fabric tenant.

I can search for my workspace by name rather than scrolling through the entire list.

In my case, I'm looking for:

task wk

Once I locate the workspace, I can see its current configuration.

The workspace is currently associated with the Power BI Pro workspace type.

Select Reassign Workspace

To change the capacity assignment, I select the ellipsis (...) next to task wk.

This opens a menu containing actions that can be performed on the workspace.

From the menu, I select:

Reassign workspace

This is the option I need to change the workspace's capacity assignment.

Select the Fabric Capacity

After selecting Reassign workspace, Fabric presents the available capacity options.

From here, I select the Fabric Capacity that I want to assign to the workspace.

The important thing is to make sure I select the correct capacity, particularly if the organisation has multiple Fabric capacities.

Once the appropriate Fabric Capacity has been selected, I confirm the reassignment.

Fabric then updates the workspace's capacity assignment.

Verifying the Workspace

After completing the reassignment, I can return to the Workspaces section in the Admin Portal and check task wk again.

The workspace should now show that it is assigned to the selected Fabric Capacity rather than its previous Power BI Pro setup.

The workspace itself has not been recreated. The existing workspace and its contents remain in place; what has changed is the capacity to which the workspace is assigned.

This is useful because I don't need to migrate all the workspace items into a new workspace simply because I want to change the capacity.

Why Reassign a Workspace?

There are several reasons why an organisation might want to reassign a workspace to Fabric Capacity.

One common reason is to make Fabric capabilities available to the workspace.

For example, an organisation may start with a traditional Power BI workspace and later adopt Microsoft Fabric. Moving the workspace to an appropriate Fabric Capacity can be part of that transition.

Capacity assignment can also be useful when an organisation wants to manage workloads using dedicated capacity rather than relying on shared capacity.

A Simple Before and After

In this example, the change can be summarised as:

Before task wk --> Power BI Pro

After the reassignment:

After task wk --> Fabric Capacity

The workspace name remains the same, and I don't have to create another workspace just to make the change.

Things to Consider

Before reassigning a workspace, it is worth checking that you have the appropriate administrative permissions and that the target Fabric Capacity is available.

It is also important to understand the implications of moving a workspace between capacity types, especially in an organisation where capacity usage, governance, and licensing are carefully managed.

The exact options available in the Admin Portal can also depend on the tenant configuration and the permissions of the administrator.

Switching Lakehouses in a Microsoft Fabric Notebook

abiola_david — Thu, 03 Sep 2026 14:06:26 GMT

When working with Microsoft Fabric Notebooks, it is common to work with data that lives in more than one Lakehouse. Instead of creating a separate Notebook for every Lakehouse, Microsoft Fabric allows you to attach multiple Lakehouses to the same Notebook and switch between them when needed.

In this article, I’ll demonstrate this using two Lakehouses: Sales and Marketing. The Sales Lakehouse contains a dbo.sales_analytics table, while the Marketing Lakehouse contains a dbo.marketing_analytics table.

Connecting Multiple Lakehouses to a Notebook

I started by creating a Fabric Notebook and attaching both the Sales and Marketing Lakehouses to it.

Once both Lakehouses are connected, they become available within the Notebook environment. This means I can work with data from either Lakehouse without having to create separate Notebooks.

For example, the Sales Lakehouse contains:

dbo.sales_analytics

while the Marketing Lakehouse contains:

dbo.marketing_analytics

The important part here is that both Lakehouses are connected to the same Notebook.

Switching Between Lakehouses

One useful feature of Fabric Notebooks is the ability to switch the active Lakehouse from within the Notebook interface.

Marketing Lakehouse is the current Lakehouse with pin indicator. If I intend to switch, I can select the Sales Lakehouse as the active Lakehouse and work with the sales_analytics table. To switch, right-click on the Sales Lakehouse (or click on the ellipsis). Then, I can click Select as default lakehouse

As seen below, the Sales Lakehouse has been promoted to the top of the Marketing Lakehouse.

I can also switch the active Sales Lakehouse back to Marketing and work with the marketing_analytics table, all within the same Notebook.

This can be particularly useful when building data engineering or analytics workflows where data is distributed across multiple Lakehouses.

Working with the Sales Lakehouse

After switching the active Lakehouse to Sales, I can access the sales data from the Notebook.

For example:

df = spark.sql("SELECT * FROM Sales.dbo.sales_analytics LIMIT 10")

display(df)

Because Sales is the active Lakehouse, the table can be referenced directly using its table name.

I don't need to create another Notebook just to work with the Sales Lakehouse.

Query Marketing Analytics Table

Note, I don't necessary need to switch to the Marketing Lakehouse before I can query the inherent marketing_analytics table!

For example, I can simply author the SparkSQL code shown before to read the data from the marketing_analytics

df = spark.sql("SELECT * FROM Marketing.dbo.marketing_analytics LIMIT 10")

display(df)

Being able to switch Lakehouses makes the Notebook much more flexible because I can move between different Lakehouse environments without leaving the Notebook or creating additional Notebooks.

Why Switching Lakehouses Is Useful

At first, this might seem like a small feature, but it can be very useful when designing Fabric data engineering solutions.

For example, imagine an organisation has separate Lakehouses for different business domains:

Sales Lakehouse └── dbo.sales_analytics Marketing Lakehouse └── dbo.marketing_analytics

A single Notebook can be connected to both Lakehouses. Depending on the task I'm performing, I can switch between them and work with the appropriate data.

This can help reduce the number of Notebooks required in a Fabric workspace and make development more convenient.

It can also be useful when demonstrating Fabric capabilities, developing data transformation logic, or working with multiple business-domain Lakehouses.

One Notebook, Multiple Lakehouses

The key takeaway is that a Fabric Notebook doesn't necessarily have to be tied to just one Lakehouse.

By connecting multiple Lakehouses and switching the active Lakehouse when required, I can use a single Notebook to work with data across different Lakehouse environments.

In this example, I started with the Sales Lakehouse, queried dbo.sales_analytics, switched to the Marketing Lakehouse, and then queried dbo.marketing_analytics — all from the same Fabric Notebook.

This provides a simple and convenient way to work across multiple Lakehouses while keeping related development activities within a single Notebook.

From ADF Inventory to a Fabric Operating Model: A Practical Migration Playbook (Part 2)

ssrithar — Mon, 24 Aug 2026 13:45:19 GMT

A practical guide to building a portable, metadata-driven ingestion framework for Microsoft Fabric. Learn how JSON configuration, Pipelines or Airflow orchestration, watermarks, retries, and audit tables work together to make data ingestion scalable and safe.

From ADF Inventory to a Fabric Operating Model: A Practical Migration Playbook

ssrithar — Tue, 11 Aug 2026 13:47:18 GMT

Migrating from Azure Data Factory to Microsoft Fabric is not a one-for-one conversion. This practical playbook helps you assess existing workloads, choose the right Fabric pattern—Mirroring, Copy jobs, Pipelines, or Notebooks—and validate the move safely through metadata-driven design, reconciliation, and phased cutover.

Understanding SHOWPLAN_ALL in Fabric SQL

abiola_david — Mon, 03 Aug 2026 19:00:00 GMT

As data engineers, we spend a significant amount of time writing SQL queries to ingest, transform, and analyze data. However, producing the correct result is only half the story. Equally important is understanding how the SQL Server Query Optimizer executes our queries.

One of the most effective ways to inspect the optimizer's decisions is by using SHOWPLAN_ALL.

In this article, I'll demonstrate how to use SHOWPLAN_ALL in SQL Server and Microsoft Fabric SQL Database, explain what it does, discuss a common pitfall, and show you how to resolve it.

What is SHOWPLAN_ALL?

SHOWPLAN_ALL is a session-level SQL Server setting that instructs the query optimizer to return the estimated execution plan instead of executing the query.

Rather than returning data, SQL Server provides detailed information about the physical operators it intends to use, allowing us to understand how the query will be processed before it runs.

This is particularly useful when:

Investigating slow-running queries.
Understanding optimizer decisions.
Identifying expensive operations such as sorts and scans.
Comparing different query implementations.
Tuning SQL for better performance.

Unlike PostgreSQL, MySQL, Oracle, or Databricks SQL, which support variations of the EXPLAIN command, SQL Server relies on SHOWPLAN_ALL and graphical execution plans.

Orders Table

For this walkthrough, I'll use anorders table in Fabric SQL

CREATE TABLE orders
(
    order_id INT PRIMARY KEY NOT NULL,
    order_date DATE NOT NULL,
    customer VARCHAR(20) NOT NULL,
    amount INT NOT NULL
);

After populating the table with data, I'll calculate a running total using a window function.

Sample Query

SELECT
    order_id,
    order_date,
    customer,
    amount,
    SUM(amount) OVER
    (
        ORDER BY order_date, order_id
    ) AS running_total
FROM orders
ORDER BY customer, order_date, order_id;

Without any execution plan settings enabled, SQL Server executes the query normally and returns the dataset.

Viewing the Estimated Execution Plan

To inspect how SQL Server intends to execute the query, enable SHOWPLAN_ALL.

SET SHOWPLAN_ALL ON;
GO

SELECT
    order_id,
    order_date,
    customer,
    amount,
    SUM(amount) OVER
    (
        ORDER BY order_date, order_id
    ) AS running_total
FROM orders
ORDER BY customer, order_date, order_id;
GO

Instead of returning rows from the orders table, SQL Server returns an estimated execution plan describing the physical operations that would be performed.

Although the exact operators depend on the optimizer and available indexes, the execution plan typically resembles the following sequence:

Read the data from the orders table.
Perform any required sorting for the window function.
Compute the running total using the Window Aggregate operator.
Apply the final ORDER BY.
Return the results.

This visibility into the optimizer's decision-making process is invaluable when diagnosing performance issues.

A Common Pitfall

One of the most common mistakes developers make is assuming that SHOWPLAN_ALL only affects the next query.

It doesn't.

SHOWPLAN_ALL is a session-level setting.

Once enabled, every subsequent query in the same session returns an execution plan instead of executing.

For example, after running:

SET SHOWPLAN_ALL ON;
GO

Even a simple query such as:

SELECT *
FROM orders;

returns the execution plan rather than the table data as seen below

If you're unaware that SHOWPLAN_ALL is still enabled, it can be quite confusing because every query appears to "stop working."

The Solution

The fix is straightforward.

Disable the session setting.

SET SHOWPLAN_ALL OFF;
GO

After turning it off, SQL Server immediately resumes normal execution.

Running the same query again returns the expected dataset.

Why This Happens

Many SQL Server settings persist for the duration of the current session.

SHOWPLAN_ALL is one of them.

Other commonly used session-level settings include:

SHOWPLAN_XML
STATISTICS IO
STATISTICS TIME
NOCOUNT

Understanding session scope is important when troubleshooting unexpected SQL Server behavior, particularly during performance tuning.

As data volumes continue to grow, query performance becomes increasingly important.

Execution plans provide insights that cannot be obtained simply by reading the SQL statement.

They help answer questions such as:

Is SQL Server performing a Table Scan or an Index Seek?
Is an unnecessary Sort operation occurring?
Which operator consumes the highest estimated cost?
Is the optimizer using a Window Aggregate efficiently?
Can the query be rewritten to reduce resource consumption?

These are exactly the questions that distinguish writing SQL from engineering performant SQL solutions.

Key Takeaways

If you regularly work with SQL Server or Microsoft Fabric SQL Database, keep the following in mind:

SHOWPLAN_ALL returns the estimated execution plan without executing the query.
It is a session-level setting, not a one-time command.
Every query continues returning execution plans until the setting is explicitly disabled.
Use SET SHOWPLAN_ALL OFF to restore normal query execution.
Learning to interpret execution plans is an essential performance tuning skill for data engineers and database professionals.

Final Thoughts

Window functions, Common Table Expressions (CTEs), and complex analytical queries are becoming increasingly common in modern data platforms. While writing these queries correctly is important, understanding how the SQL Server Query Optimizer executes them is what enables us to build scalable and efficient data solutions.

SHOWPLAN_ALL offers a simple yet powerful way to inspect the optimizer's strategy before a query is executed. Combined with graphical execution plans and tools such as STATISTICS IO and STATISTICS TIME, it forms an essential part of every data engineer's SQL performance tuning toolkit.

The next time you're optimizing a query, don't just verify that it returns the correct result—take a few minutes to examine how SQL Server plans to execute it. The insights you gain can often reveal opportunities for significant performance improvements.

Microsoft Fabric Just Made Quick Data Explorer Much Easier

Murtaza_Ghafoor — Mon, 03 Aug 2026 14:11:34 GMT

Tired of creating temporary notebooks just to troubleshoot a pipeline or check a table? Meet the Lakehouse Query Explorer—Microsoft Fabric’s new lightweight Spark SQL editor built for rapid exploratory work.

Choosing the Right Way to Run Python in Microsoft Fabric

apturlov — Tue, 21 Jul 2026 13:45:43 GMT

Fabric gives us several ways to run Python, and at first they can look overlapping.
In this post, I share the practical decision model I use to choose the right option based on execution mode, compute engine, and data access path. If you are code-first and want fewer wrong turns when moving from exploration to production, this guide is for you.

Breaking Barriers: Azure Databricks Unity Catalog Tables Can Now Be Stored Directly in OneLake

Srisakthi — Mon, 22 Jun 2026 14:09:32 GMT

Seamlessly Read & Write data to OneLake from Azure Databricks with Unity Catalog governance in place!

Playing the Zork game in Fabric as a Fabric App

svelde — Mon, 08 Jun 2026 13:39:19 GMT

Whether you are a pro-coder or a software maker, the new Fabric Apps feature offers an easy and powerful way to vibe code custom software applications and host them within Fabric.

Although Fabric is a very serious SaaS platform, I now have the tools to play the Zork game within Fabric!

I just deployed the Fabric App Hello World template and asked GitHub Copilot to merge the Visual Zorker into the Fabric App. Then, I only had to deploy it again. All in five minutes tops.

Let's check out how this is done.

Direct Lake Is Changing the Lakehouse vs Warehouse Debate in Microsoft Fabric

Tamanchu — Mon, 01 Jun 2026 13:55:33 GMT

Most Fabric discussions still focus on Lakehouse versus Warehouse.

I believe that's increasingly the wrong question.

Thanks to Direct Lake, many organizations can now go directly from Lakehouse to Power BI without introducing a Warehouse layer. But there are important trade-offs and hidden performance considerations that every Fabric architect should understand before making that choice.

Let's dive into what really drives the decision.

The Fabric Admin Trap: Scaling Your Cleanup

Pragati11 — Wed, 27 May 2026 13:41:05 GMT

We’ve all been there. It’s Friday afternoon, and you’re looking at your Microsoft Fabric tenant. It’s cluttered with dozens of abandoned test workspaces, half-finished projects, and “oops, I forgot to delete this” environments. You open the portal. You click. You wait for the page to refresh. You click again. You feel the rage slowly building. As admins, we are supposed to be power users, but we often spend more time navigating UI menus than actually managing our data. I decided enough was enough and turned to the Microsoft Fabric CLI (fab) to take back control. But the path to automation wasn’t a straight line.

A reference architecture for private API access from Microsoft Fabric

dimkalamaras — Fri, 22 May 2026 15:12:10 GMT

Calling private APIs from Microsoft Fabric — a reference architecture with Managed Private Endpoints and Azure Functions

Fabric Data Agents - The Orchestration Playbook for M365 or Teams experience

hasrikak — Wed, 20 May 2026 18:27:45 GMT

You’ve built a Fabric Data Agent - now where should users interact with it? This post compares the major orchestration paths across the native Fabric experience, Microsoft 365 Copilot, and Teams bot orchestration, with a practical lens on fit, identity, and user experience

Materialized Lake Views in Microsoft Fabric: Making Engineering Work Easier

Murtaza_Ghafoor — Mon, 18 May 2026 14:40:57 GMT

Managing data does not have to be painful. Learn how Materialized Lake Views in Microsoft Fabric combine simple SQL with automated updates to keep your data ready and your costs at lower levels.

Medallion to Magic — Manufacturing Intelligence Platform on Microsoft Fabric

sharvu — Wed, 15 Jul 2026 14:33:24 GMT

Microsoft Fabric brings Data Engineers, Data Analysts, and Business Users onto a single platform. Data Engineers build the ingestion, Lakehouse, Warehouse, and dbt transformation layers that move raw factory data through the Bronze → Silver → Gold Medallion layers. Data Analysts design the DirectLake Semantic Model, author the DAX measure library, and build the Power BI reports that surface production readiness intelligence.

Business Users (manufacturing operations, supply chain managers, and executives) consume those insights through Power BI, the Inventory Insights data agent, and M365 Copilot, asking questions in natural language without ever opening Fabric. Inspired by the Data Factory & Data Integration Community Challenge. I built and end-to-end analytical solution on Microsoft Fabric, integrating batch-exported operational data from four U.S. factories, transforming it through the Medallion pattern, and surfacing the results through Power BI and an AI data agent.

Automating Materialized Lake Views in Fabric with PySpark

Lozovskyi — Mon, 11 May 2026 14:53:20 GMT

A configuration-driven PySpark wrapper for Microsoft Fabric Materialized Lake Views (MLVs). Enables idempotent deployments, automated state tracking via Delta properties, and event-driven pipeline orchestration.

MaskIQ (Smarter PII and PHI de-identification)

ashishprmodi — Wed, 06 May 2026 16:07:49 GMT

Sensitive data is everywhere, employee records, customer files, operational exports, analytics datasets. The hard part isn't finding PII or PHI. It's de-identifying it in a way that still keeps the data useful for development, testing, analytics, and collaboration.

Dataflow Gen2 vs Fabric Notebook: The Decision Framework

Tamanchu — Fri, 01 May 2026 14:27:00 GMT

Everyone asks "Dataflow Gen2 or Fabric Notebook?" and gets vague answers. This article gives you a concrete decision tree, real CU cost numbers, and 4 scenario deep-dives so you can make the right call every time.

OneLake Security + Shortcuts: The RLS Architecture That Actually Holds Up in Production

Tamanchu — Fri, 24 Apr 2026 13:43:45 GMT

You configure row-level security on your gold Lakehouse. You test it rows filter correctly. You ship it. Two weeks later, another team creates a shortcut from their workspace and discovers they see every row. This isn't a Fabric bug. It's the consequence of conflating Power BI RLS, SQL endpoint security policies, and OneLake Security and assuming they propagate through shortcuts the same way. They don't. This article is the reference I wish I'd had.

How to Build and Test the Gold Layer Using dbt and GitHub

techies — Thu, 16 Apr 2026 13:44:07 GMT

The Gold layer is built using dbt and is version-controlled through GitHub. It is validated through automated testing and serves as a contract between the data team and the business.