Automating Fabric feature workspace setup with OneLake shortcuts

Prince0011 
Yeah, definitely. I mentioned PROD as the source, but it could just as easily be DEV, QA, or any other workspace.

It really depends on how your team works. In my case, the goal was to automate the whole process of creating a new feature workspace, bringing in a representative dataset from another workspace, and getting everything ready for development with a single notebook.

The notebook simply creates a temporary shortcut, copies a configurable amount of data into the new workspace's warehouse, and then removes the shortcut. So the source environment is completely flexible.

Hi nathaliapuglisi  , 

Great solution! Using a temporary OneLake shortcut as a bootstrap mechanism is a clever way to keep the development workspace independent after the initial data seeding.

I've seen a few other approaches that works, depending on their governance and operational requirements:

• Fabric Data Pipelines – Copy a curated subset of data into the DEV workspace. This is a common enterprise approach because it provides monitoring, scheduling, and operational visibility.
• Notebook-based seeding – Similar to your solution, but reading directly from a source Lakehouse or Warehouse and writing into the DEV environment without creating temporary shortcuts.
• Permanent OneLake shortcuts – Some teams keep shortcuts permanently for read-only development or analytics scenarios to avoid duplicating data, although this isn't ideal if developers need complete isolation.
• Sanitized or masked datasets – Instead of copying production data, some organizations maintain a QA or masked dataset as the source for developer workspaces, which helps address governance and compliance requirements.
• Automated workspace provisioning – Combining Git integration with Fabric REST APIs or deployment automation so that workspace creation, permission assignment, metadata deployment, and data seeding all happen as part of a single provisioning workflow.

I like your approach because it cleanly separates metadata deployment (Git) from data provisioning, and the temporary shortcut minimizes long-term dependencies between environments. The only additional consideration I'd suggest is ensuring the source data is appropriately governed or masked if production data is being used.

Thanks for sharing—it's always interesting to see different provisioning patterns emerging as Fabric matures

If this post helps, then please appreciate giving a Kudos or accepting as a Solution to help the other members find it more quickly.