Note 15 · Microsoft Fabric (6/11)

OneLake Shortcuts: Should Shortcuts Stay Bronze-Only?

Argue that bronze should be a contract of OneLake shortcuts and clean views, not a second physical copy of upstream gold and silver.

2 June 2026 9 min read

Key takeaways

  • Bronze is shortcuts plus thin cleans for OneLake-published Delta; physical land only for external or non-OneLake sources.
  • A versioned shortcut inventory is the bronze contract in Git.
  • No clean or transformed bronze object without a registered backing source.
  • Heavy logic belongs in silver or upstream, never as a silent bronze rewrite.
  • CI validates shortcuts and critical view schemas on promote.
  • Ownership of target Delta is named next to each shortcut entry.

Medallion diagrams still tempt teams to land a physical bronze copy of everything upstream. When the upstream domain already publishes curated Delta in OneLake, that copy is not prudence. It is a second warehouse with a friendlier name.

Bronze can be a contract of shortcuts and thin clean views. Ownership stays with the publisher. Freshness follows the source. Your CI/CD list becomes the shortcut set, not a shadow catalog of cloned tables.

Named model: bronze as a shortcut contract

  • Publisher Delta: curated silver or gold already in OneLake; the publisher owns grain and keys.
  • Shortcut inventory: versioned paths, targets, and expected grain in Git; CI validates on promote.
  • Thin clean views: rename, cast, and project for downstream silver; always backed by a registered shortcut or raw.
  • Contract: if OneLake already holds the curated Delta, bronze references it. Heavy logic stays in silver or moves upstream.

Named model: publisher Delta, shortcut inventory, thin cleans, then silver

Figure 1. Bronze as a shortcut contract. Reference curated Delta. Do not invent a second warehouse of clones.

Context and constraint

A common failure: bronze looks busy and still lies about ownership. Pipelines copy silver and gold from sibling domains overnight. On-call owns the copy. Nobody owns the drift when the publisher changes a key.

Physical ingest still matters for raw files, CDC dumps, and systems outside OneLake. It does not matter for "we already trust this Delta table next door." Shortcuts plus thin clean views beat copy-then-clean for cost, freshness, and clarity about who fixes a broken grain. Orphan clean views with no shortcut behind them are fiction. Drop them or back them.

Figure 2 is the Learn surface for connecting a shortcut to another location. The platform already holds the bytes. Prefer a pointer over a nightly clone.

OneLake shortcut connecting to another location in Microsoft Fabric

Figure 2. Bronze can be a pointer surface. Prefer OneLake shortcuts over copying bytes the platform already holds. Source: Microsoft Learn: OneLake shortcuts.

Design

1. Separate external raw from internal curated

Two bronze stories live in one word. External raw needs land-and-register: files, extracts, API dumps. Internal curated is another domain's published Delta. Treat them differently in docs and pipelines. The second story is shortcuts, not Spark writes that replay someone else's silver.

Figure 3 is the fork that stops teams treating every upstream table like an extract that must land again.

External raw needs physical land; internal curated OneLake Delta should be shortcuts

Figure 3. Two bronze stories. Physical land for external and non-OneLake sources. Shortcuts for curated Delta you already trust next door.

2. Shortcut set is the bronze contract

List every shortcut path, target workspace or lakehouse, and expected grain in the repo the same way you list API contracts. Promotion and review should ask whether the shortcut set changed, not whether a copy job ran green. When a publisher renames a table, the contract breaks in one place you can find.

3. Thin clean views, not a second transform layer

Clean views on shortcuts handle renames, type nudges, and column picks for downstream silver. They should not become a parallel medallion. If the view needs heavy business logic, you are sneaking silver into bronze. Push that conversation upstream or own a real silver transform with a reason.

4. Kill orphan cleans

A "clean" or "transformed" view with no shortcut (or no registered raw) is a table someone invented because a notebook was open. Either attach it to a real source or delete it. Orphans confuse join keys, docs, and newcomers who assume every bronze object is backed.

Figure 4 is the review gate: thin stays, costume moves, orphans die.

Thin cleans rename cast and project; costume cleans belong in silver; orphan cleans must be attached or deleted

Figure 4. Thin cleans stay in bronze when they are backed. Costume cleans move to named silver. Orphans get attached or deleted.

5. Keep join keys boring

Once bronze stops inventing parallel physical tables, keys stay the publisher's keys. Your silver joins on documented business keys instead of "our copy's surrogate that drifted last Tuesday." Naming stays simple when you are not maintaining alias tables for the same entity.

6. Document CI/CD around the shortcut map

Deployment notes should include shortcut recreate or validate steps. A lakehouse that promotes without shortcuts is an empty promise. Pair the map with ownership: which team owns the target Delta, which team owns the consumer views.

What "thin" means in review

A clean view that renames columns, casts types already decided upstream, and projects the columns silver needs is thin. A clean view that recalculates business status, invents surrogate keys, or filters to a preferred subset without documenting why is silver in costume. Reviewers should reject costume cleans or demand they move to a named silver transform with tests. Shortcuts-only bronze fails if every team sneaks logic into the clean layer because "it was right there."

Common mistakes

Copy for comfort. "We might need it offline" becomes permanent dual maintenance. You pay storage and reconciliation forever.

Clean views that rewrite grain. Thin becomes thick. Suddenly bronze owns business rules the publisher never signed.

Silent republish of upstream gold as local bronze. Consumers think your workspace is the system of record. Support tickets bounce forever.

Shortcut sprawl without a list. Twenty shortcuts, no contract file, one broken path in prod. Same failure mode as undocumented APIs.

Assuming freshness equals pipeline success. Your copy job can succeed on yesterday while the publisher already fixed today. Shortcuts inherit truth; copies invent lag.

Use as-is or adapt

Use as-is

  • Bronze is shortcuts plus thin cleans for OneLake-published Delta; physical land only for external or non-OneLake sources.
  • A versioned shortcut inventory is the bronze contract in Git.
  • No clean or transformed bronze object without a registered backing source.
  • Heavy logic belongs in silver or upstream, never as a silent bronze rewrite.
  • CI validates shortcuts and critical view schemas on promote.
  • Ownership of target Delta is named next to each shortcut entry.

Adapt before you use

Shortcuts couple you to publisher availability and permissions. That is the point. If you need an air-gapped snapshot for a regulated extract, say so and land a deliberate copy with retention rules. Do not pretend every table needs that posture.

Cross-workspace shortcuts need identity and sharing hygiene. Teams that cannot share Delta should not fake integration with nightly clones either. Fix the sharing model or accept a formal interface table the publisher owns.

Thin views still need testing when types change upstream. You trade copy lag for contract monitoring. Put schema checks on the shortcut targets you care about.

Primary references: OneLake shortcuts, Lakehouse overview, and Lakehouse schemas.

If your bronze folder is a museum of clones, shrink it to a shortcut contract and thin views. Cost, freshness, and ownership get honest in the same move.