powerbi-report-management

Resolve the target workspace ID, decide whether to publish the local semantic model or connect to an existing workspace model, then rebind definition.pbir from byPath to byConnection with the resolved semanticModelId. Base64-encode all PBIR parts and POST to the Fabric reports API, polling the long-running operation to completion.

Call POST getDefinition with ?format=PBIR on the report using az rest with the Fabric API audience. The call often returns 202 Accepted, so capture the x-ms-operation-id header with --verbose and poll until completion, then base64-decode each definition part to local files.

No, this workflow only supports the modern PBIR format. Always pass ?format=PBIR on getDefinition, and if a report returns PBIR-Legacy, it cannot be read or updated through this approach.

Empty visuals usually mean PBIR entity bindings do not match the target semantic model's table and column names. Download the model's TMDL, compare all Entity, queryRef, and filter references, and remap mismatched bindings before republishing.

Duplicates occur when a create POST is retried after receiving a 202 Accepted response, since the operation is already processing server-side. Never retry the POST; instead capture the x-ms-operation-id and poll the operation, then delete any duplicates with the Delete Report API.

Report management handles transport: listing, creating, downloading, uploading, and deleting report items and PBIR definitions via the Fabric API. Report authoring handles the PBIR content itself, such as pages, visuals, filters, themes, and formatting, which belongs to the powerbi-report-authoring skill.