Introduction
When you are deciding how to organise Microsoft Fabric workspaces, you are also deciding who owns the data, who can change it and how teams will depend on one another. A workspace per team gives you a clear place for that ownership. The next question is how to keep their work connected as they start sharing data.
Suppose you run Finance's Warehouse. Your team owns its tables and its schedule, but your sales analysis reads a customer table maintained centrally. That customer load fails. Which of your tables are affected? Once the central team repairs it, what should you reload?
You need answers at both levels: the central team needs to see the reach of the failure, and you need to recover Finance's work on your own schedule. Keeping separate projects should make ownership clearer, not leave you reconstructing the connections during an incident.
1. Self-service data and the coordination problem
If you are organising Fabric for self-service data, this arrangement may look familiar:
- A central team owns the Bronze Lakehouse in one workspace.
- Another team owns the Silver Lakehouse and Gold Warehouse in a second.
- Shared semantic models live in a third.
- Forty or fifty business areas own workspaces of their own. They read central data and occasionally one another's.
A central scheduler can coordinate those loads; separate schedules let teams choose when to run. Either way, Finance still needs to know whether its last successful load used the latest central data. Looking only at Finance's job history will not answer that question.
Keep the teams' ownership, then connect the dependency and load records they already need. That gives you a way to investigate one team's work or coordinate a wider recovery, without making every change go through a shared project.
2. What Fabric already provides
You can build on two things Fabric already gives you: identifiable items and objects, and OneLake connections between workspaces. The data can stay where its team owns it.
2.1 Qualify the object you mean
When someone says CustomerSales failed, you need to know which team's table they mean. For this Warehouse table, the workspace, item type, item name, schema and object name give you that context. A Folder uses a path instead of a schema; a model or Report is an item in its own right.
Finance's shortcut already names the central source it reads. Give Weaver the participating catalogues and it matches that source to the central team's recorded installation. You can follow the connection without maintaining another cross-team map.
2.2 OneLake shares data across workspaces
Every Fabric tenant comes with a single OneLake instance (Microsoft 2026a). Its shortcuts let an item in one workspace read data held by an item in another, including a Lakehouse reading a Warehouse, without copying it (Microsoft 2026b).
In this experiment, Spark addressed tables in other workspaces directly by four-part name. A Warehouse's T-SQL reached only items in its own workspace, so each business team brought central Gold tables into its workspace through shortcuts in a small bridge Lakehouse and read them through that Lakehouse's SQL analytics endpoint.
Fabric also supplies item lineage and impact analysis, including downstream items in other workspaces. The question here is more specific: how do the managed tables and loads depend on one another, which recorded operations need attention, and what should run next?
3. The two missing pieces
To answer Finance's recovery question, you need to connect two records: what each table reads, and what happened when it last loaded.
3.1 Connect the recorded dependencies
Finance's shortcut already identifies the central item and path it reads. Given both catalogues, Weaver matches that source to the central team's installed table and connects the recorded dependencies. The teams do not need to maintain the same connection again in a second map.
3.2 Follow the load results
A successful Finance load can still be behind: the central customer table may have been repaired since it ran. Compare Finance's load record with the source's state and you can distinguish a failed step from work that simply needs catching up. You can also trace the central failure through the tables and models that depend on it.
Each team keeps its own catalogue. Choose the catalogues to include, and Weaver connects their recorded dependencies for the investigation or run. You can inspect a pair of teams or bring the participating catalogues together for a wider view.
3.3 A bonus: concurrency
Those same connections let you run independent teams' work together. Each reader waits for the source it needs, including a SQL endpoint refresh or OneLake publication between engines; unrelated branches can continue. The performance guide explains how that scheduling works within a project.
4. Experimental setup
Here is a concrete test of that arrangement: 50 real Fabric workspaces on an FTL64 trial capacity in Australia East. Each represented a team with its own catalogue, project and configuration, initialised, built and loaded separately. These are simulated teams, with results from the 7 November 2026 run.
| Team | Workspaces | Each holds |
|---|---|---|
| Bronze | 1 | Bronze Lakehouse with Python tables run in Spark |
| Central | 1 | Silver Lakehouse with shortcuts into Bronze; Gold Warehouse |
| Semantic | 1 | Bridge Lakehouse over Gold; Direct Lake semantic model |
| Marts | 29 | Bridge Lakehouse over Gold; Warehouse with two SQL tables |
| Models | 10 | Bridge Lakehouse over Gold; Direct Lake semantic model |
| Lakehouses | 4 | Lakehouse with a shortcut to Gold and a Python table |
| Thin reports | 4 | A report bound to the central semantic model in another workspace |
Two simulated business teams read each other's summaries, deliberately forming a dependency cycle across workspaces.
The experiment then introduced a failure into the central Bronze table BRZ.Customer, and tested what each team could see and do.
5. The implementation: Weaver
With Weaver, each team keeps those records in its own Fabric Warehouse catalogue. Build records the objects and dependencies; Load and Test record what ran. To investigate connected work, you bring the relevant catalogues together. The teams keep their projects where they are.
5.1 The Weaver CLI
For Team 05, catching up after the central repair is one command. From its configured project, name its own work and include the central catalogues that explain its upstream state:
$ weaver load SPREAD_TEAM_05 --workspace SPREAD_TEAM_05 --stale \
--catalogue SPREAD_TEAM_05/Warehouse/Catalogue \
--catalogue SPREAD_BRONZE/Warehouse/Catalogue \
--catalogue SPREAD_CENTRAL/Warehouse/CatalogueThe central catalogues provide context; only Team 05's work is selected to run. Select several teams when you want a coordinated run instead. Weaver orders that selection and records each result in its owner's catalogue. The across-catalogue guide covers the setup, selectors and required permissions.
5.2 The Catalogue Dashboard
If you would rather explore the connections in Power BI, open the Catalogue Dashboard. Select Team 05 in Workspaces, follow the teams that supply it, then use Health and Orchestration to investigate the failed load. You can narrow the same pages to your workspace, item or object.
The snapshot below lets you explore ten of the experiment's catalogues. For the full set, deploy the Dashboard in Import mode and refresh it to read new records; Direct Lake supports up to ten catalogues.
6. Results
Now return to the failed customer load. What could you see as the central team, what could you do as Team 05, and what happened when the remaining work ran together?
| Who asks | Question | Answer | Time |
|---|---|---|---|
| The organisation | Which managed work depends on the failed table? | 77 managed tables and semantic models in 45 downstream workspaces, each traced to BRZ.Customer. | 82 seconds |
| Team 05 | Which of our tables need attention, and why? | Both Mart tables, with the failed BRZ.Customer load named as the cause. | 11 seconds |
| The central team | Can we repair our selected work first? | Six central objects reloaded across Bronze, Silver/Gold and the shared model. | 2 minutes 18 seconds |
| Team 05 | The upstream is repaired. What should we reload? | Its two stale Mart tables. | 5 seconds to check, 15 seconds to reload |
| The organisation | Recover the remaining selected work. | 71 object loads plus 41 readiness steps. The combined run spanned 43 workspaces. | 4 minutes 16 seconds |
| The organisation | Coordinate a run using all 50 participating catalogues. | 125 steps: 80 loads, 41 endpoint refreshes and four publication waits. All succeeded under one workflow ID. | 5 minutes 15 seconds end to end |
The coordinated run's end-to-end time includes catalogue reads, planning, Spark startup, execution and recording. The test used small tables on the FTL64 trial capacity to measure coordination across workspaces. For data-volume results, see the performance guide.
6.1 Knowing the impact of a failure
As the central team, you could trace the failed Bronze load to 61 Warehouse tables, five Lakehouse tables and 11 semantic models across 45 downstream workspaces. As a business team, you could narrow that view to your own work and see the same failed source named as the cause. You did not need to ask every team to inspect its job history separately.
The four thin-report workspaces read the central semantic model, so their data recovery follows that model's upstream recovery.
6.2 Each team recovers on its own terms
The central team reloaded six objects across Bronze, Silver/Gold and the shared semantic model. Weaver ordered the work and waited for the publications and endpoint refreshes its readers needed. Business teams retained control of when to reload their own tables.
For Team 05, the next decision was small: check its two Mart tables and reload them. The check took five seconds and the reload took 15. Its project and schedule stayed its own; recovering those tables did not require waiting for every other business team's run.
6.3 Teams that read one another's data
Teams 01 and 02 read each other's summaries. Weaver reported that cycle and ran its members once in a consistent order. Where a dependency closed the loop, the consumer could use the result available from an earlier run. Health continued to report failures, pending work and overdue loads. The cycle guide explains the execution and assessment rules.
6.4 Coordination when the organisation needs it
When you need a wider recovery, select the workspaces or items together and supply their catalogues. Use --stale to narrow that selection to work whose recorded state needs another load.
In this run, that meant coordinating work across the participating projects using their existing dependencies. You can choose this for an organisation-wide recovery while leaving everyday scheduling with each team.
7. Team ownership, coordinated operation
You can give teams control of their Fabric work without losing the ability to operate across it. Keep each team's project, catalogue and schedule; use the recorded connections when a shared failure or coordinated run needs a wider view.
- When you own a shared source:See which teams depend on it and coordinate the selected recovery.
- When your team consumes that source:Understand what held up your work and catch it up when you are ready.
The useful result is that choice. The same records support a team's local decision and an organisation-wide run. You can coordinate when it helps, without turning independent teams into one shared deployment.
See how Weaver works, then the documentation.
References
Microsoft (2026a). OneLake, the unified data lake. Microsoft Learn. Accessed 8 November 2026.
Microsoft (2026b). Unify data sources with OneLake shortcuts. Microsoft Learn. Accessed 8 November 2026.