Frequently asked questions about the Fabric lifecycle management tools

Lifecycle management has two parts, integration and deployment. To understand what integration is in Fabric, refer to the Git integration overview. To understand what deployment pipelines is in Fabric, refer to the deployment pipelines overview.

For a short explanation of Git integration, see the Git integration overview.A multiline or formatted answer to the question. Use any Markdown formatting you want, provided that you maintain the indent on the lines after the | characters.

For a short explanation of deployment pipelines, see the deployment pipelines overview.

For information on licenses, see Fabric licenses.

All workspaces must be assigned to a Fabric license. However, you can use different capacity types for different workspaces.

For information on capacity types, see Capacity and SKUs.

The deployment pipelines permissions model is described the permissions section.

To configure deployment rules in deployment pipelines, you must be the owner of the semantic model.

If the workspace capacity is in one geographic location while the Azure DevOps repo is in another location, the Fabric admin can decide whether to enable cross-geo exports. For more information, see Users can export items to Git repositories in other geographical locations.

Get started with Git integration using the get started instructions.

There could be several reasons why an item was removed from the workspace.

• If the item wasn't committed and you selected it in an undo action, the item is removed from the workspace.
• If the item was committed, it could get removed if you switch branches and the item doesn't exist in the new branch.

The following considerations are important to keep in mind:

• Deployment rule limitations
• Supported data sources for dataflow and semantic model rules
• Incremental refresh
• Automation

You can either assign one workspace to your pipeline and deploy it across the pipeline, or assign a different workspace to each pipeline stage. For more information, see assign a workspace to a deployment pipeline.

Datasets that use DirectQuery or Composite connectivity mode and have variation or auto date/time tables aren't supported in deployment pipelines. If your deployment fails and you think it's because you have a dataset with a variation table, you can look for the variations property in your table's columns. You can use one of the following methods to edit your semantic model so that it works in deployment pipelines.

• In your dataset, instead of using DirectQuery or Composite mode, use import mode.

• Remove the auto date/time tables from your semantic model. If necessary, delete any remaining variations from all the columns in your tables. Deleting a variation can invalidate user authored measures, calculated columns, and calculated tables. Use this method only if you understand how your semantic model model works as it can result in data corruption in your visuals.

When you pin a tile to a dashboard, if the tile relies on an unsupported item (any item not on this list is unsupported), or on an item that you don't have permissions to deploy, after deploying the dashboard the tile doesn't render. For example, if you create a tile from a report that relies on a semantic model you're not an admin on, when deploying the report you get an error warning. However, when deploying the dashboard with the tile, you don't an error message, the deployment will succeed, but the tile won't display any information.

For a short explanation of deployment plans, see the deployment plan overview.

The deployment plan item type appears only after a Fabric admin turns on the tenant setting. In the admin portal, under Tenant settings > Microsoft Fabric, enable Users can create deployment plan (preview) items, set Apply to either the whole organization or a security group, and select Apply.

Until this setting is on, the item type stays hidden in every workspace.

The deployment falls back to its default behavior. Items deploy without a declared order and without pre-deploy or post-deploy actions. Any dependency the plan was protecting, such as a warehouse view that reads a lakehouse table populated by a notebook, fails again.

A correctly ordered plan deploys item metadata in the order you declare, but deploying a lakehouse doesn't put rows into its tables. A warehouse view that reads a lakehouse table fails to bind unless a notebook or data pipeline produced that table first. Add a post-deploy action between the lakehouse and the warehouse that produces the table. An action reports completion when the action itself ends, not when the services it feeds have caught up, so put any readiness check in the last cell of the notebook, or the last activity of the data pipeline. For an example, see deployment plan samples.

A notebook's default lakehouse field holds IDs that point at a specific lakehouse in a specific workspace. After the notebook lands in a new workspace through Git, those IDs can still point at the original workspace. Either set the default lakehouse for the target environment in the notebook settings before the run, or have the notebook resolve its lakehouse at runtime. For more information, see Notebook source control and deployment.

Run output is visible from the deployment in the portal. Action runs link back to the underlying item's run history for logs and step details.

A failed deployment doesn't roll back completed item deployments or changes made by actions. For recovery guidance, see The deployment stopped partway through.

Not directly. Trigger Update from Git from an external scheduler such as Azure Pipelines or GitHub Actions, and the attached plan runs as part of that deployment.

Yes, if the pipeline drives the deployment through a Fabric API that supports attaching a plan, such as the Git sync API, the deployment pipelines deploy API, or the batch import API. A deployment driven by the Fabric CLI, the Terraform provider for Fabric, or the fabric-cicd Python library can't attach a plan.

No. A plan governs the items in a deployment and the actions that run around them. Workspace-level configuration isn't part of a deployment, so settings such as the workspace identity, Spark settings, and the Git connection aren't created or updated by a plan.

Configure these in the target workspace before you deploy. An item that depends on workspace-level configuration, such as a notebook that authenticates through the workspace identity, fails at run time if the target workspace isn't configured the same way as the source.

No. A deployment plan follows the standard Fabric workspace role model. For more information, see deployment plan permissions.

The owner of a deployed paginated report is the user who deployed the report. When you're deploying a paginated report for the first time, you become the owner of the report.

If you're deploying a paginated report to a stage that already contains a copy of that paginated report, you overwrite the previous report and become its owner, instead of the previous owner. In such cases, you need credentials to the underlying data source, so that the data can be used in the paginated report.

Paginated report subreports are kept in the same folder that holds your paginated report. To avoid rendering problems, when you're using selective copy to copy a paginated report with subreports, select both the parent report and the subreports.

Paginated report rules can be created if you want to point the paginated report to the semantic model in the same stage. When creating a deployment rule for a paginated report, you need to select a database and a server.

If you're setting a deployment rule for a paginated report that doesn't have a Fabric semantic model, because the target data source is external, you need to specify both the server and the database.

However, paginated reports that use a Fabric semantic model use an internal semantic model. In such cases, you can't rely on the data source name to identify the Fabric semantic model you're connecting to. The data source name doesn't change when you update it in the target stage, by creating a data source rule or by calling the update datasource API. When you set a deployment rule, you need to keep the database format and replace the semantic model object ID in the database field. As the semantic model is internal, the server stays the same.

• Database - The database format for a paginated report with a Fabric semantic model, is sobe_wowvirtualserver-<dataset ID>. For example, sobe_wowvirtualserver-d51fd26e-9124-467f-919c-0c48a99a1d63. Replace the <dataset ID> with your dataset's ID. You can get the dataset ID from the URL, by selecting the GUID that comes after datasets/ and before the next forward slash.

  

• Server - The server that hosts your database. Keep the existing server as is.

After a deployment, if you download the RDL of the paginated report, it might not be updated with the latest version that you can see in Power BI service.

When you have a dataflow that contains semantic models that are configured with incremental refresh, the refresh policy isn't copied or overwritten during deployment. After deploying a dataflow that includes a semantic model with incremental refresh to a stage that doesn't include this dataflow, if you have a refresh policy you'll need to reconfigure it in the target stage. If you're deploying a dataflow with incremental refresh to a stage where it already resides, the incremental refresh policy isn't copied. In such cases, if you wish to update the refresh policy in the target stage, you need to do it manually.

Related content

• Get started with Git integration
• Get started with deployment pipelines