Medallion Architecture in Microsoft Fabric

How to go from raw data to data that’s ready for Power BI

If you’ve been working with data for a while, you’ve probably heard the term Medallion. And if you haven’t implemented it in Microsoft Fabric yet, this article is for you. Don’t worry, I’ll also tell you when you shouldn’t implement it, because yes, sometimes you don’t need a sledgehammer to crack a nut.

Have I told you how much I love this show?

Poor data quality, not being able to follow where data gets transformed, data coming from 12 different sources, nobody knowing which version is the right one, and the business team distrusting what shows up in Power BI because “the numbers never add up”, plus a pile of other reasons, can make your data project fail. Medallion Architecture helps solve exactly that. It’s the Marie Kondo of data architecture… before having kids, at least.

The data junk room, the problem nobody likes to admit*

*Any resemblance to reality is purely coincidental

Picture a mid-sized company. It has data in Salesforce, in a legacy ERP, in Excel files someone updates every Monday, and in an external vendor’s API that changes the schema without warning.

What happens when you try to build a sales report? Someone writes a query that joins all of that, adds a WHERE that “kind of works”, and the result lives in an Excel tab that only that person knows how to read. When they go on holiday, the business stops.

The Medallion architecture offers a solution: instead of transforming the data all at once, you refine it in progressive layers. Each layer has a responsibility and a place inside Microsoft Fabric.

---

AFC Richmond and a coach from Kansas

Before getting into code and Lakehouses, let me take you to my show of the moment. Because it turns out Ted Lasso, without knowing it, built a Medallion architecture with his football team. Without needing to know what a Lakehouse was or understanding how offside works, just with biscuits.

What a wonderful character

• Phase 1. The signing and arriving at the dressing room. First day of preseason at an English football club. Ted has just landed from the US and finds the following: a star striker with a Champions League ego, a veteran who has been at the club so long he’s part of the furniture, a player with an optimism that defies physics, and a kid nobody knows why he’s in the top flight. Ted doesn’t change anyone. He doesn’t tell anyone to stop being who they are. He records them as they are: with their egos, their injuries, their quirks, and that “what’s an American going to teach me” attitude. He accepts them raw. That’s Bronze.
• Phase 2. Training and the dressing room. This is where the real work begins. Tactics are designed. Dressing room rules are set. The team dynamic gets cleaned up: they learn that passing exists, discover you can be a leader without breaking someone’s shin, and understand that not everything is solved with enthusiasm. You no longer have a group of chaotic individuals. You have a team. They’re not winning the Premier League yet, but they train together; it’s something reliable and recognizable. That’s Silver.
• Phase 3. Match day. Now it’s for real: full stadium, every stakeholder watching. They take the pitch with a clear formation, defined roles and rehearsed plays. Every player knows exactly what’s expected of them. The team no longer needs the coach to explain the tactics; they know them. The crowd sees the final result: goals, assists, wins. They don’t need to know that a player ran 200 sprints in training or that stress almost made someone retire. They see the finished product. That’s Gold.

The beautiful part of the process: the original signings are still on record. If something goes wrong in a match, Ted goes back to training (Silver) or even reviews the scouting reports (Bronze). He can rebuild the process from any phase.

And one more thing: nobody in their right mind puts a newly signed player straight into a Premier League match without a single training session. A mistake I see every day in data projects. As Ted would say: “That’s like putting ketchup on a biscuit. Technically possible, fundamentally wrong.” ⚽

Bronze Layer. Welcome to the new signings’ dressing room (and why you shouldn’t touch anything)

Same as when you land a new project where everything is still to be done

The Bronze layer is your landing zone, your starting point. And the key here is DON’T TOUCH ANYTHING.

Here you ingest data in its original form: JSON from an API, CSVs from an external system, tables replicated from a SQL Server, log files. Everything goes in, nothing comes out modified. Like Ted welcoming players on day one: you accept them with their flaws, their contradictions and that column someone named Fld_007 thinking it was temporary.

Why is it important not to transform in Bronze?

Because when something breaks, and something always breaks, you need to be able to go back to the source. If you transform at ingestion time and there’s a bug in your logic, you’ve lost the original data. Bronze is your insurance, your history, the backup you should never need but that one day saves your life.

In Microsoft Fabric, Bronze lives in a Lakehouse. Usually in the Lakehouse Files folder, where you can store any file format without imposing a schema.

Lakehouse: Bronze
└── Files/
    ├── salesforce/
    │   ├── 2024-01-15/accounts.json
    │   └── 2024-01-15/opportunities.json
    ├── erp/
    │   └── 2024-01-15/ventas_export.csv
    └── api_proveedor/
        └── 2024-01-15/productos_raw.parquet

Like the scout who brings the player to the club, its mission ends at the dressing room door. A Fabric Data Pipeline or Eventstream takes care of moving the data, nothing else. Its job ends when the file is saved.

What Bronze contains

• Uncleaned data, with duplicates, nulls and wrong types
• Schemas exactly as the source sent them
• Partitioned by ingestion date
• Long retention: this is your history

Silver Layer. Where things start to make sense.

This is where the action begins. The Silver layer takes the data from Bronze and turns it into something you can start working with.

In Silver you apply:

• Data cleaning: removing duplicates, handling nulls, fixing types.
• Standardization: ISO dates, amounts in the same currency, consistent column names. The whole team speaking the same tactical language.
• Basic enrichment: joins between tables that make sense technically (not business-wise). Linking the player to their scoring record, not deciding whether they start.
• Validations: records that don’t meet quality rules are flagged or moved to a quarantine table. Like when a player is pulled from training because they haven’t slept and smell suspiciously of pub.

In Microsoft Fabric, Silver also lives in a Lakehouse, but now in the Tables section: structured data in Delta Lake format, with a defined and versioned schema.

A Fabric Notebook orchestrated by a Pipeline is the perfect weapon for this job. If you prefer something no-code, a Dataflow Gen2 does the same transformation with a visual interface.

What Silver contains

• Clean, correctly typed data
• Simple relational models (no complex business logic, pretty please)
• Tables reusable by multiple use cases
• Change history thanks to Delta Lake

Gold Layer. Match day (and for the business to make decisions)

The Gold layer is where the business lives. Here tables stop being what matters and the questions they answer start to matter.

What’s the revenue by region in Q4? Which customers are at risk of churn? What’s the margin by product line? Gold answers those questions.

In Gold you build

• Fact and dimension tables (star or snowflake schema). The starting line-up and the match stats.
• Pre-calculated aggregations to improve dashboard performance. The match highlights, already edited.
• Feature stores for Machine Learning models. The data the performance analyst uses to predict injuries.
• Semantic views tailored to each business area.

In Microsoft Fabric, Gold can live in a Lakehouse (for consumption with Spark or Direct Lake in Power BI) or directly in a Fabric Warehouse if the team prefers pure SQL.

The Gold layer is the one you connect straight to Power BI using Direct Lake mode: no import, no data duplication, with Analysis Services performance and Lakehouse freshness. That combination is one of the gems of Microsoft Fabric.

What Gold contains

• Dimensional models optimized for querying
• Business semantics applied (no technical IDs, but understandable names)
• Aggregated or pre-calculated data where it makes sense
• Domain-specific tables (gold_ventas, gold_finanzas, gold_rrhh)

---

The 4 most common mistakes when implementing Medallion

The ones you’ve fallen into, the ones we’ve all fallen into at some point.

1. Doing transformations in Bronze

I’ve seen this one in loads of projects. And it’s always the same story: someone wanted to “save a step”. But they didn’t save it; they multiplied it by ten when something broke three months later and there was no way back to the original data. Bronze is sacred. Resist the temptation.

2. Putting business logic in Silver

Silver standardizes, it doesn’t decide. If a field has two possible definitions depending on the department, and it always does, that belongs in Gold or in the Power BI semantic layer. If you bring that discussion into Silver, you’re picking a side in a war that isn’t yours.

3. Building a single Gold layer for the whole company

A monolithic Gold trying to serve Sales, Finance, HR and Operations at the same time ends up looking like a Frankenstein that serves nobody. The most practical approach is Gold domains: gold_ventas, gold_finanzas, gold_operaciones. Each team has its own Gold, and they all share the same Silver.

4. Not versioning Bronze data

Always partition by ingestion date. Six months from now you’ll be glad you did. Twelve months from now you’ll make someone who was about to make this mistake read this.

---

When NOT to use Medallion Architecture (yes, that moment exists)

Everything above assumes Medallion is the right answer. And most of the time it is. But there are scenarios where implementing it is using a sledgehammer to crack a nut, and it’s worth recognizing them before you start creating Lakehouses and Workspaces like there’s no tomorrow.

When the data volume is small and stable.
If your company has three data sources, two analysts and a Power BI report that already works, adding three Lakehouse layers doesn’t give you structure, it gives you bureaucracy. Medallion shines when there’s complexity: multiple sources, multiple consumers, multiple teams. If you don’t have that yet, a well-built Dataflow Gen2 and a clean Power BI semantic model may be enough.

When you need results in days, not weeks.
Medallion is a medium-term investment. If you have a project due in two weeks and the client wants to see numbers, it’s not the time to design a three-layer architecture. Do the exploratory analysis, deliver value fast, and leave the architecture for the consolidation phase.

That’s what Ted did: first he got to know the players and earned their trust. He didn’t start day one drawing a 4–3–3 on the whiteboard. Medallion isn’t the first thing you build; it’s what holds up when the project grows.

When the data isn’t going to be reused.
The real ROI of Silver is that multiple use cases consume the same clean tables. If you’re building a one-shot pipeline for a migration, a one-off analysis or a report that will be used once and never again, the architecture overhead doesn’t pay off. Build the minimum you need and document it well. That’s it.

When the team can’t maintain it.
A poorly maintained Medallion architecture is worse than not having one. If Bronze starts piling up unpartitioned files, Silver ends up with tables nobody knows who created, and Gold has queries that “kind of work”, you’ve built the same data junk room as before, just with three folders. Medallion requires team discipline. If that discipline doesn’t exist yet, first you have to build it and then scale the architecture.

The rule of thumb: if you can’t clearly answer who is going to consume Silver and what for, you probably don’t need Medallion yet. Start smaller and scale when the pain justifies it. The perfect architecture that nobody maintains is worth exactly the same as the Monday Excel file.

---

Conclusion

The original signing, with their flaws and their potential, is the starting point. In Microsoft Fabric you have Lakehouses, Notebooks, Dataflows and Power BI’s Direct Lake designed to work exactly like that, layer by layer.

As Ted would say: “Be curious, not judgmental.” And that applies to data as much as to the people who work with it. ⚽

---

Are you implementing Medallion Architecture in Microsoft Fabric? Tell me in the comments which design decisions were the hardest for you. Real cases are the ones we learn the most from. BELIEVE.