Seven days to the person
who actually knows how Fabric fits together.

You already did the thing this whole platform is built around, and it probably felt routine: a notebook wrote a Delta table into a lakehouse. Here's what actually happened. That table landed in OneLake — one storage account for the entire tenant — as open Delta/Parquet files. The moment it landed, it became queryable by every other engine in Fabric without being copied: T-SQL through the lakehouse's SQL analytics endpoint, DAX through a Direct Lake semantic model, Spark from any other notebook, and external tools through the OneLake APIs.

That is the whole pitch. Traditional stacks copy data between a lake, a warehouse, and a BI model — three copies, three refresh windows, three chances to disagree. Fabric separates storage (OneLake, one copy, open format) from compute (Spark, T-SQL, KQL, DAX, Power Query). Every Fabric item you see in the portal is one of those engines pointed at that store, or something that orchestrates them.

The item zoo, grouped so it stops being noise

Do this — 4 minutes

• Open the lakehouse you already built. Switch the top-right selector from Lakehouse to SQL analytics endpoint and run SELECT TOP 10 * FROM your_table. Same bytes, different engine, zero copies.
• In the lakehouse explorer, note the path: Tables/ vs Files/. Tables is the managed Delta area the SQL endpoint sees; Files is raw storage it doesn't.
• Install OneLake File Explorer (or open the item's OneLake path) and see your table as actual Parquet files in folders. Demystifies the whole thing.
• Say out loud which engine each of these uses: a Power BI report, a SQL endpoint query, your notebook, a Dataflow Gen2. If you hesitate on any, re-read the diagram above.
• Write down, in one sentence, the difference between an item and a workspace. You'll need this vocabulary all week.

Most people's instinct is "write a pipeline to copy it in." In Fabric that should be your third instinct. The first question is always: do I need a copy at all? Every copy you avoid is a schedule you don't maintain, a latency you don't explain, and storage you don't pay for.

The ladder — work down it, stop at the first one that fits

A rule that holds up in review meetings: shortcut what you can, mirror what you must, pipeline what you have to transform, and only use a dataflow when Power Query is genuinely the right tool. "Notebook everything" is as wrong as "dataflow everything" — the skill is matching the tool to the shape of the source and to who has to maintain it after you.

Do this — 5 minutes

• In a second lakehouse, create a shortcut to the Delta table you already built. Query it. Notice you didn't schedule anything and the data isn't duplicated.
• Open the New shortcut dialog and read the full source list — ADLS, S3, GCS, Dataverse, OneLake. Knowing what's on that list changes what you propose at work.
• Open Mirroring and read the supported sources, even if you can't set one up. This is the answer to "can we get the ERP data without a nightly extract?"
• Take one existing copy job in your org and ask honestly: could this be a shortcut or a mirror instead?
• Note the ownership question: a shortcut means someone else controls that data's lifecycle. Decide whether that's a feature or a risk in your case.

Four things in Fabric hold tables. They are not interchangeable, and picking correctly is most of what "architecture" means day to day.

The honest heuristic: Lakehouse if your team writes Python, Warehouse if your team writes SQL, Eventhouse if the data is events, SQL database if an application needs to write. All four end up as Delta in OneLake, so the choice is about the authoring experience and the write pattern — not about where the bytes go.

What Delta actually is — the 90-second version

A Delta table is a folder of Parquet files plus a transaction log (_delta_log) recording every commit. That log is what gives you ACID transactions, time travel, and safe concurrent writes on plain cloud storage. Consequences you actually feel:

• Small files kill you. Thousands of tiny Parquet files from frequent appends make every read slow. OPTIMIZE compacts them.
• Deletes aren't immediate. Old files linger for time travel until VACUUM removes them — which also sets how far back you can look.
• V-Order is Fabric's write optimisation that makes Parquet dramatically faster to read from VertiPaq/Direct Lake. On by default; worth knowing the name.
• Time travel is now available from the SQL analytics endpoint too, using a TIMESTAMP clause — query the table as it looked before last night's load.
• Don't partition small tables. Under a few GB, partitioning usually makes things worse by creating exactly the small-file problem above.

# in your notebook — run these on the table you already built
spark.sql("DESCRIBE HISTORY your_table").show(10, truncate=False)   # every commit
spark.sql("OPTIMIZE your_table")                                  # compact small files
spark.sql("DESCRIBE DETAIL your_table").show(truncate=False)      # file count & size

# read it as it was 3 versions ago
df = spark.read.format("delta").option("versionAsOf", 3).table("your_table")

Do this — 5 minutes

• Run DESCRIBE HISTORY on your table. Read the operation column — that's your table's audit trail, free.
• Run DESCRIBE DETAIL and look at numFiles versus sizeInBytes. That ratio is the small-file problem, quantified.
• Run OPTIMIZE, then DESCRIBE DETAIL again and compare. You just did performance tuning.
• Read your table at an earlier version with versionAsOf. This is the answer to "what did the report say on Tuesday?"
• Create a Warehouse in the same workspace. Note you can write to it with plain INSERT — the thing the lakehouse endpoint won't let you do.
• Decide which of the four stores your org's main use case should sit in, and be able to say why in one sentence.

Your notebook works. The gap between that and a notebook that runs unattended at 3am is four things: where its dependencies come from, how it gets its inputs, how it loads data the second time, and what it costs.

1. Environments — stop installing libraries in cell one

An Environment is a Fabric item holding your Spark runtime version, libraries, and Spark configuration, attachable to notebooks and Spark job definitions. It's how you stop %pip install at the top of every notebook and get reproducible runs. It's also the honest answer to "why did it work yesterday?"

2. Parameters — the toggle cell that makes it callable

Mark a cell as the parameter cell (cell menu → Toggle parameter cell). Values declared there are overridden when a pipeline or another notebook calls it. This is the single change that turns a script into a component.

# parameter cell — defaults for interactive runs, overridden by the caller
load_date = "2026-08-01"
source_system = "sap"
full_reload = False

# elsewhere: chain notebooks and read pipeline values
import notebookutils
notebookutils.notebook.run("transform_silver", 300, {"load_date": load_date})
notebookutils.notebook.exit("success")   # returned to the calling pipeline

3. Incremental loads — MERGE, not overwrite

The move from beginner to practitioner is loading changes rather than rewriting the table. Delta's MERGE does upserts in one atomic commit:

from delta.tables import DeltaTable

target = DeltaTable.forName(spark, "silver_customer")
(target.alias("t")
  .merge(updates.alias("s"), "t.customer_id = s.customer_id")
  .whenMatchedUpdateAll()
  .whenNotMatchedInsertAll()
  .execute())

Add .option("mergeSchema", "true") on writes when upstream columns legitimately change — but know that you've just made schema drift silent. Most teams want it on in bronze and off in gold.

4. Cost — because someone will ask

Everything in Fabric consumes Capacity Units from one shared pool: Spark, SQL, pipelines, Power BI, all of it. Spark sessions are the classic silent burner — an idle attached session still holds resources. Autoscale billing for Spark lets Spark jobs bill serverlessly rather than competing for the capacity, which is worth knowing exists when a Spark job starts throttling everyone's reports.

Do this — 6 minutes

• Create an Environment, attach it to your notebook, and move any %pip install into it.
• Add a parameter cell to your existing notebook with a date parameter.
• Create a data pipeline with one notebook activity, pass the date parameter in, and run it. That's your first orchestrated job.
• Rewrite one overwrite write as a MERGE. This is the most transferable skill this week.
• Open the Fabric Capacity Metrics app and find what consumed the most CUs in the last day. Even on a trial.
• Stop your Spark session manually when you finish. Then notice how rarely anyone does.

Medallion architecture is three layers, and the value is entirely in the discipline of not skipping one:

• Bronze — raw, as it arrived. No cleaning, no business logic. Append-only, with the load timestamp and source. You keep it so you can rebuild everything downstream without going back to the source system.
• Silver — cleaned and conformed. Types fixed, duplicates resolved, keys standardised, entities from different systems reconciled into one shape. Still fairly granular.
• Gold — shaped for consumption. Business-ready, aggregated where it makes sense, and modelled as a star schema: fact tables of numbers, dimension tables of the things you slice by.

Why star schema, still, in 2026? Because VertiPaq — the engine behind every Power BI semantic model — is built for it. One wide flat table looks simpler and performs worse: it compresses badly, it makes measures ambiguous, and it makes every filter scan more data. If your organisation is on Power BI, gold being a star schema is not a stylistic preference, it's the difference between a report that returns instantly and one that doesn't.

Materialized lake views — the layer that automates the layers

Rather than hand-orchestrating bronze→silver→gold refreshes, materialized lake views let you declare the transformation and let Fabric manage materialisation and lineage. As of mid-2026 lineage extends across layers and workspaces: define one refresh schedule on your gold lakehouse and it cascades back through silver and bronze automatically. That's a meaningful reduction in pipeline plumbing — and a very current thing to be able to name.

Direct Lake — and the trap that will bite you

A Direct Lake semantic model reads Delta files from OneLake straight into memory. No import refresh, no DirectQuery round-trip — import-like speed on data that's current as of the last commit. It's the reason gold-layer modelling matters so much.

Knowing that one paragraph puts you ahead of most people who use Fabric daily. It is the most common invisible performance regression in the platform.

Do this — 6 minutes

• Sketch your org's current reporting flow on one page and label each step bronze, silver or gold. Note which layer is missing — there's almost always one.
• Take the Delta table you built. Which layer is it? Be honest — most first tables are bronze wearing a gold badge.
• Create a Direct Lake semantic model over a lakehouse table and open it in Power BI. Note there's no refresh to schedule.
• Check an existing semantic model in your org for views feeding a Direct Lake model — the trap above.
• Read the materialized lake views docs page. Ten minutes of reading, permanently useful vocabulary.
• Write down one fact table and three dimensions for your main subject area. That's a gold-layer design.

You've connected a workspace to GitHub, which is further than most Fabric users ever get. Here's the shape of the full lifecycle, and specifically what Git doesn't solve.

The three pieces

• Git integration — source of truth for item definitions. Notebooks, pipelines, semantic models, reports serialise to files you can branch, review and revert. Use branch out to a new workspace to get an isolated dev sandbox per feature instead of everyone editing one workspace.
• Deployment pipelines — promoting items between dev, test and prod workspaces, with deployment rules to swap connections and parameters per stage.
• Variable libraries — the newer piece, and the one that makes the other two usable. A workspace item holding values per stage: connection strings, item references, lakehouse IDs. Pipelines, notebooks and shortcuts read from it, so nothing is hardcoded and deployment stops rewriting IDs by hand. Recent releases added connection and item reference types, so a pipeline can bind dynamically to a lakehouse or connection per environment.

What Git does not capture — the part people learn painfully

• Data. Obviously, but worth saying: Git versions definitions, not table contents.
• Shortcuts. Not carried by deployment pipelines — recreate per workspace or automate them.
• Bindings to specific items. A notebook's default lakehouse or a pipeline's connection points at a specific ID that differs per environment — exactly what variable libraries exist to solve.
• Capacity and workspace settings. Assignment, permissions and capacity settings live outside the repo.

For automation beyond the UI there's the Fabric REST API, the Fabric CLI, and the fabric-cicd Python library for deploying items from a repo in a build pipeline. You don't need these on day one, but knowing they exist is what separates "we click Deploy" from "we have a release process."

Do this — 6 minutes

• In your Git-connected workspace, use branch out to a new workspace and watch a full isolated dev environment appear from a branch.
• Open the repo and look at how a notebook and a pipeline are actually serialised. That's what you'll be reviewing in PRs.
• Create a variable library with one variable — a lakehouse name or a connection — and reference it from a pipeline.
• Create a deployment pipeline with dev and test stages, even with one item, so you've seen the promotion flow.
• List everything in your workspace that would break on promotion because it names a specific environment. That list is your CI/CD backlog.
• Skim the Fabric CLI docs for five minutes. Enough to say "we could automate this" credibly.

A pipeline nobody consumes is a cost centre. Fabric has five distinct ways to serve what you've built, and knowing all five means you can answer "how would people use this?" before someone asks.

• Semantic model + report — the default. Direct Lake over your gold layer.
• SQL analytics endpoint — anyone with SQL or Excel can query it directly. Wildly underused; often the fastest way to make analysts happy.
• Data agents — a natural-language agent grounded in your data. Buildable over lakehouses, warehouses, semantic models, eventhouses, SQL and mirrored databases; publishing and sharing is generally available, and they now support Git integration and deployment pipelines like any other item. The quality depends almost entirely on how well-modelled and well-named your gold layer is — which makes your modelling work suddenly very visible.
• Activator — rules on streams or report visuals that fire a Teams message, email or Power Automate flow when a condition holds. This is how data becomes an action instead of a dashboard nobody opens.
• Fabric Apps — new in 2026, a first-class item for building real web applications on Fabric data with Entra auth built in. Covered on its own page.

Governance, briefly, because it's what makes any of it trustworthy

• Domains group workspaces by business area, with their own admins — how you avoid one flat list of 400 workspaces.
• OneLake catalog is where people find data, and endorsement (Promoted / Certified) is how they know which copy to trust.
• Purview integration brings sensitivity labels and lineage across the estate.
• Workspace roles (Admin/Member/Contributor/Viewer) plus OneLake security decide who sees what — and mirrored data can now carry security that follows it through shortcuts downstream.

Do this — 6 minutes

• Connect Excel to your lakehouse's SQL endpoint. Watch a finance colleague's face when you show them.
• Create a data agent over your table and ask it a question in English. Note where it gets confused — that's a modelling or naming problem, not an AI problem.
• Set an Activator alert on a report visual so a threshold breach messages you in Teams.
• Open the OneLake catalog and see what's discoverable in your tenant. Usually revealing.
• Check whether your org uses domains and endorsement. If not, that's a concrete, low-risk proposal you can own.
• Pick which of the five serving routes fits your org's biggest current pain, and write one sentence on why.