Automating Fabric feature workspace setup with OneLake shortcuts

A few weeks ago I ran into an annoying problem with Microsoft Fabric.

Every time I created a new feature workspace and branched it from my main Git branch, all the metadata came across perfectly (Lakehouse, Warehouse, schemas, tables, notebooks, pipelines, etc.), but... no data.

That meant every developer had to manually:

1. Create a shortcut to the PROD Warehouse
2. Copy some production data
3. Delete the shortcut
4. Finally start developing

So I automated it.

Now a single notebook:

1. Detects the current workspace automatically
2. Creates a temporary shortcut from DEV Lakehouse to PROD Warehouse storage
3. Discovers all schemas and tables (no hardcoding)
4. Reads a configurable number of records from each PROD table
5. Copies a configurable number of rows into the DEV Warehouse using Spark + synapsesql()
6. Deletes the shortcut when it's done

The important detail is that the DEV workspace already contains the complete metadata structure because it was created from the PROD Git branch. The notebook only seeds the data.

The workflow is now:

Create new workspace
        |
        v
Create Git branch from main
        |
        v
Run bootstrap notebook
        |
        v
DEV workspace ready for development

How does it work?

The notebook uses the OneLake DFS endpoint called by the Fabric UI when creating and deleting shortcuts.

The API calls used are:

Create shortcut:

POST https://onelake.dfs.fabric.microsoft.com/v2.0/workspaces/{workspaceId}/artifacts/{lakehouseId}/shortcuts/batchCreate

Delete shortcut:

DELETE https://onelake.dfs.fabric.microsoft.com/v2.0/workspaces/{workspaceId}/artifacts/{lakehouseId}/shortcuts/Tables/{shortcutName}

The authentication is handled using the Fabric notebook identity:

notebookutils.credentials.getToken(
    "https://storage.azure.com/"
)

The shortcut is only temporary. It is created to expose the PROD Warehouse storage layer, Spark reads the underlying Delta files, the data is written into the DEV Warehouse, and then the shortcut is removed.

And yes, I considered keeping permanent shortcuts, but that does not fit my workflow. I need the freedom to play around with data without depending on PROD. The shortcut is only a temporary bridge to seed DEV data and is removed afterward.

So, the final result:

PROD Warehouse
|
| OneLake DFS shortcut endpoint
v
Temporary shortcut in DEV Lakehouse
|
| Spark reads underlying Delta files
v
Existing DEV Warehouse tables
|
v
Shortcut removed

The notebook does not create new tables. It relies on the metadata already synchronized through Git and only inserts sample data into the matching DEV tables.

A few things to consider:

• The amount of copied data is configurable.
• The user running the notebook needs access to both environments.
• Data governance rules should still be applied because this process moves PROD data into DEV.

The biggest benefit for me is that a new feature workspace can now go from "empty metadata" to "ready for development" with a single notebook execution.

I'm curious how other Fabric teams handle this today. Do you:

• copy data using pipelines?
• create the shortcut manually and keep them permanently?
• use another workspace provisioning approach?