Which items and settings a deployment copies or leaves alone, and how data source and parameter rules point each stage at its own data.
From Ultra Transcenders DP-600 by Tony Rough (coming December 2026)
A deployment copies metadata, not data, and it deliberately leaves some settings in each stage alone. Deployment rules then change what’s copied so each stage can point at its own data sources.
| Copied (overwrites the target) | Not copied (stays as it is in the target) |
|---|---|
| Data sources (rules supported) | Data: only metadata is deployed |
| Parameters (rules supported) | URL and ID |
| Report pages and visuals, dashboard tiles | Permissions on the workspace or an item |
| Model metadata | Workspace settings (each stage has its own workspace) |
| Item relationships | App content and settings (update each stage’s app yourself) |
| Folder hierarchy of deployed items | Personal bookmarks |
| Sensitivity labels, only for new items or empty stages, or when the source label has protection and the target doesn’t (with consent) | Semantic model role assignments, refresh schedule, data source credentials, query caching settings and endorsement |
For incremental refresh, the policy is copied and the target’s data and partitions are kept, but renaming a table or non-calculated column in a table with incremental refresh makes the deployment fail. Gateway mapping isn’t automatic after the first deployment; configure it in the target item’s settings.
Common trap: Expecting the refresh schedule, data source credentials, RLS role membership or endorsement to arrive with the deployed semantic model - none of these are copied, so set them in each stage.
| Item | Data source rule | Parameter rule | Default lakehouse rule |
|---|---|---|---|
| Dataflow Gen1 | Yes | Yes | No |
| Semantic model | Yes | Yes | No |
| Paginated report | Yes | No | No |
| Mirrored database | Yes | No | No |
| Notebook | No | No | Yes |
Rules to remember:
Common trap: Planning deployment rules for Dataflow Gen2 - rules are listed only for Dataflow Gen1, semantic models, paginated reports, mirrored databases and notebooks; Dataflow Gen2 and other Fabric items use parameters or variable libraries instead.
Most semantic models automatically bind to the paired item in the target stage. A Direct Lake semantic model doesn’t: after deployment it still points at the lakehouse in the source stage. Add a data source rule in the target stage to rebind it to that stage’s lakehouse or warehouse.
Common trap: Deploying a lakehouse and its Direct Lake semantic model together and assuming the model now reads the Test lakehouse - Direct Lake models don’t autobind, so without a data source rule the Test model keeps reading Development data.
A variable library is a workspace item holding variables (basic types such as strings, integers, numbers, booleans, date-times and GUIDs, or item and connection references) with one value set per environment, of which one is active in each workspace. Pipelines, lakehouse shortcuts, notebooks, Dataflow Gen2 and Copy job can consume them, and they work with both Git integration and deployment pipelines; after deployment to an empty stage the Default value set is active until you change it.
This note is one section of Ultra Transcenders DP-600: Implementing Analytics Solutions Using Microsoft Fabric, an independent study guide that explains every topic the exam covers by technology, with comparison tables, diagrams and the common traps, plus a glossary linked to Microsoft Learn.
Due on Amazon in December 2026, in Kindle and paperback editions.
About the book · DP-600 terms in the glossary · All DP-600 study notes
How the two Direct Lake flavours differ in table discovery, permission checks, fallback and unsupported cases, and which one to choose.
When each table storage mode fits a semantic model, based on data size, latency, source security and capacity.
What each Fabric workspace role can do across Power BI, data engineering, warehousing and real-time items.
How data type, team skills, write needs and transactions decide between Fabric's lakehouse, warehouse, eventhouse and other stores.
What the Warehouse can do that a lakehouse's read-only SQL analytics endpoint can't, and when to use each.
The three many-to-many scenarios in a semantic model and the bridge-table or relationship design each one needs.
How data volume, transformation needs, skills and latency decide which Fabric tool should copy data into OneLake.