Best Practices and Known Issues

XMLA Restrictions Semantic Model/Report and Policy Lifecycle Management

XMLA Restrictions and Model Management

Summary: The Impact of XMLA Write Operations

Enabling XMLA write operations unlocks powerful capabilities for Power BI models, but it fundamentally changes how those models interact with the Power BI Service. The most significant change is that you generally cannot download the semantic model back to a standard .pbix file once an external tool has modified it

Impact Analysis: What Changes with XMLA

The following table outlines the operational changes, user impacts, and necessary remediations when utilizing XMLA write capabilities

Area of Impact	Operational Change	User Impact & Awareness	Remediation / Preventative Action
File Downloadability	The "full" PBIX (report + data) typically cannot be downloaded from the Service.	Microsoft warns that XMLA writes often block model downloading.	Crucial: Maintain your original PBIX/PBIP in source control (Git/DevOps). - Always keep a master copy (PBIP/PBIX + metadata) outside of the Power BI Service. After every publish/republish of the new version from Source control ensure Policies are deployed to keep the security in place.
Report Connection	Reports may only download as "Live Connected" files.	You will lose the "report + data" download option; you will only receive a "thin" PBIX.	Rely on source control for the master file rather than the Service.
Refresh Operations	XMLA refresh behavior differs from the standard Service refresh.	XMLA refreshes are not limited to 48 times/day and have different timeout rules.	No action needed; this is a capability benefit.
Audit Logs	Refresh history tracks XMLA transactions.	You can verify XMLA write transactions directly in the Refresh history.	Monitor history to validate external tool operations.
Model Features	Advanced artifacts (Calculation Groups, Translations) can be created.	Be cautious of "round-tripping" (overwriting) these features if you publish them via Desktop.	If you re-publish a semantic model with these features, you must redeploy the associated policies.
Storage Format	"Large semantic model storage format" is often required.	Microsoft recommends this format for XMLA write performance, but it impacts portability.	If memory issues occur, switch the model storage setting to "Large semantic model storage format."
General Blockers	Download limits exist regardless of XMLA status.	Features like Incremental Refresh and Automatic Aggregations can also block downloads.	Review the detailed limitations section below.

Operational Best Practices

To manage these restrictions effectively, adopt the following "Be Aware" checklist:

• Maintain a Golden Copy: Always keep a master copy (PBIP/PBIX + metadata) outside of the Power BI Service

• Shift Mentalities: Treat model edits as Application Lifecycle Management (ALM)—using source control and controlled deployment—rather than a "download-edit-republish" workflow

• Expect "Thin" Files: Assume that report downloads will be "thin" (live connection only) once the model is XMLA-modified

Downloading Guidelines

Can you download the report after an XMLA change?

Generally, NO, or only with significant restrictions

The Alternative Method: Downloading the Semantic Model

If you need to access functionality (such as viewing data, RLS, or editing measures), attempt to download the Semantic Model file specifically, rather than the report

• How to do it: Navigate to the workspace, select the ellipses (...) next to the semantic model, and select "Download this file"

• If successful: You will receive a file allowing you to view table data , view roles/RLS , edit columns/measures , and republish to the Service.

Limitations: When You Cannot Download

The "Download this file" option is unavailable if any of the following apply:

• Role Security: You are not at least a Contributor in the workspace.

• Model Features: The model uses Incremental Refresh or Automatic Aggregations.

  • Note: To download a model with automatic aggregations, you must disable the training and delete the aggregation tables first.

• Source Origin: The model was migrated from Azure Analysis Services or imported from OneDrive for Work/School.

• Architecture: The model uses Direct Lake mode.

• Size Constraints: The model exceeds the capacity SKU limit or 10GB.

• Storage Settings: Models enabled for Large Semantic Model Storage Format generally cannot be downloaded via REST APIs , though the Service may allow it unless errors occur.

• ALM Pipelines: Downloading is not supported for files deployed via deployment pipelines.

Official Documentation for reference: https://learn.microsoft.com/en-us/power-bi/create-reports/service-export-to-pbix#limitations-when-downloading-a-semantic-model-pbix-file

Potential Workaround

If you are blocked from downloading, the community has identified a potential workaround using Tabular Editor: https://docs.tabulareditor.com/te3/powerbi-xmla-pbix-workaround.html

• This involves using Tabular Editor to reverse-process a .PBIP file into a .PBIX file

• Note: This is an advanced method and may not suit all use cases

Power BI Model/Report and Policy Lifecycle Management Best Practices

Summary

TrustLogix outlines the end-to-end semantic model workflow lifecycle management for Power BI in environments governed by TrustLogix security policies and backed by Snowflake/Databricks or any other data sources as the data platform.

It defines the required personas, responsibilities, access levels, and validation checkpoints necessary to ensure that semantic models are developed, tested, deployed, and operated in a secure, compliant, and controlled manner across Development, Test, and Production environments.

As semantic models evolve through the lifecycle — from initial development to production consumption — they must consistently enforce row-level security (RLS), object-level security (OLS), and policy-driven access controls without disrupting report usability or user experience.

This requires close coordination between Power BI developers, report owners, security and governance teams, TrustLogix policy administrators, IAM teams, and platform administrators, supported by robust source control and CI/CD practices.

This lifecycle framework establishes:

• Clear ownership and accountability at each stage of the workflow

• Standardized pre- and post-deployment validation checks

• A Golden Copy approach using PBIP/PBIX artifacts for reliable deployments

• Controlled policy deployment and re-deployment through TrustLogix using XMLA

• Consistent entitlement access patterns between Power BI and Snowflake

By following this structured lifecycle approach, organizations can ensure that semantic model changes are predictable, auditable, and secure, while maintaining business agility and minimizing the risk of unintended data exposure in Power BI.

Personas, Responsibilities & Access Matrix

Persona	Primary Responsibilities	Power BI Access Level	Snowflake Access Level	CI/CD / Tooling Access
IAM / Azure AD Team	- Manage security groups & Service Principals - Grant required API permissions (e.g., Group.Read) - Maintain access lifecycle (joiners/movers/leavers)	No workspace access required	No Snowflake access	Azure AD / Entra admin
Power BI Platform / Fabric Admin	- Workspace governance and lifecycle management - Manage deployment pipelines - Validate pipeline health and target environments - Manage Service Principals & permissions	Admin (Tenant & key workspaces)	No business data access required	CI/CD admin
Power BI Developer	- Develop PBIX/PBIP reports and semantic models- Implement data model, measures, relationships - Validate report functionality in Dev - Ensure PBIP/PBIX is checked into source control (Golden Copy) - Support RLS/OLS validation during testing	Contributor (Dev & Test workspaces)(No Admin in Prod)	Read access to required source tables/viewsNo access to entitlement view directly	Repo read/write (Dev branch)CI pipeline read
Security / Data Governance Team	- Review RLS/OLS & Validate compliance and define data protection rules - Review TrustLogix policy logic for data protection and compliance adherence - Approve security sign-off before Prod deployment	Member / Viewer (Prod workspace)(Viewer recommended)	Review access to policy DB & entitlement metadata (read-only)	Repo read-only
TrustLogix Policy Administrator	- Create and manage TrustLogix policies (RBAC / ABAC) - Deploy policies to Test and Prod via XMLA - Re-deploy policies after report/model republish - Validate entitlement view push to semantic models	Admin (Dev/Test/Prod as required)(to push policies via XMLA)	Admin / Power role on: TLX_POLICY_DB- TLX_ENTITLEMENT_VIEW	Policy repo read/write XMLA endpoint access
CI/CD Pipeline (Service Principal)	- Deploy PBIP/PBIX artifacts across environments - Trigger model refresh where applicable - Trigger policy redeployment as needed	Contributor (target workspace)(Admin only if required)	Uses delegated Snowflake role via Power BI	Pipeline execution
Report Owner (Business / Data Owner)	- Own reporting requirements and data correctness- Review and approve intended security behavior (“who sees what”) - Validate reports against business expectations - Approve readiness for Test / Prod	Admin (Prod workspace)Contributor (Dev/Test)	No direct Snowflake access required (optional read-only)	Repo read-only
End Users / Report Consumers	- Consume reports and dashboards- Download reports where permitted	Viewer	No Snowflake access	None

Workflow Lifecycle Management

Development Phase

Before policy deployment checks (Dev → Test / Dev → Prod)

• Source control (Golden Copy): Power BI Developer

  • Confirm the latest PBIP/PBIX + policy scripts are checked in and are the exact artifacts that CI/CD will deploy. (PBIP is designed for project-based workflows and source control.)

• Review process: Object/Report Owner

  • Ensure report owners have reviewed the reporting requirements and the intended security behavior (RLS/OLS expectations, “who should see what”).

• Security validation in lower environment (TrustLogix policy deployment): TrustLogix Policy Administrator and Security Governance Team

  • Validate RLS logic on the test model (or Dev workspace model) using:

    • Service “Test as role” on the semantic model Security page (recommended for service behavior).

  • Confirm the team understands RLS only restricts Viewer users (Admins/Members/Contributors aren’t restricted).

• CI/CD readiness: Power BI Platform/Fabric Admin

  • Confirm the pipeline is targeting the correct environment/stage and that required dependencies are healthy (connections, parameters, deployment rules if used). Deployment pipelines are the recommended structured promotion mechanism.

• Entitlement View Access from Power BI: Snowflake Platform team

  • Each semantic model must have entitlement view access from Power BI

  • TrustLogix recommended approach

    • Create a dedicated Power BI Access Role with required permissions on the entitlement view

    • Assign this role to all functional roles connecting to Snowflake from Power BI

After policy deployment checks (in Test) (Data Governance Team/ Report Owner)

• Refresh transaction succeeded

  • Trigger/confirm a refresh as required and validate via Refresh history; this is the primary troubleshooting surface for refresh failures and for confirming XMLA-driven refresh/write activity

  • Since TrustLogix pushes the entitlement view to the semantic models, a refresh might be useful to validate the connections are live

• Security validation

  • Re-test “Test as role” and validate representative user personas (viewer-level) for expected row filtering

• Report connectivity / usability

  • Open downstream reports and confirm visuals render correctly and performance is acceptable.

Production Phase

Before policy deployment checks (Prod publish readiness) (Report Owner)

• Prod report owner responsibilities

  • Confirm the report owner has:

    • Established the prod source connection (and validated credentials/gateway where applicable)

    • Performed local testing in the Desktop against prod-equivalent sources (as per your standard)

  • Ensure the PBIX/PBIP is checked in as the deployable Golden Copy.

• Review + approvals

  • Ensure required approvers have signed off (security + data correctness + compliance).

• Deployment pipeline status (CI/CD Pipeline Admin)

  • Confirm CD pipeline is healthy and that the correct prod target is selected

• Entitlement View Access from Power BI: (Snowflake Platform team)

  • Each semantic model must have entitlement view access from Power BI

  • TrustLogix recommended approach

    • Create a dedicated Power BI Access Role with required permissions on the entitlement view

    • Assign this role to all functional roles connecting to Snowflake from Power BI

After policy deployment checks (in Production) (Data Governance Team / Report Owner)

• Successful refresh + monitoring

  • Validate Refresh history for success and capture failure details if any (credentials/timeouts/data source errors are common root causes)

  • Since TrustLogix pushes the entitlement view to the semantic models, a refresh might be useful to validate the connections are live

• Security validation (viewer behavior)

  • Test with representative prod users/roles; confirm expected behavior for Viewer users (and document that workspace elevated roles bypass RLS)

• Report connection and consumer experience

  • Confirm key reports load correctly and users can access expected content.

  • Add a note for consumers: downloads from the Service may be thin/live-connected depending on model configuration and governance.

Note: if there is a change to the underlying semantic model in the future, please follow all the above steps for re deploying the TrustLogix Security Policy

Version Control and CI/CD Pipeline Maintenance (CI/CD Pipeline team / Report Owner / Data Governance team)

The most effective best practice is to have proper change management via data governance processes and treat the semantic model as a software application, requiring an ALM workflow. Publish PBIX/PBIP Files to Version Control

• Initial Commit: Commit the master PBIX/PBIP file to a Git repository to establish the Golden Copy.

• Deployment of Policies: After every successful deployment or update (especially those involving advanced features created via XMLA), you must redeploy the associated policies to ensure they remain in place.

• Metadata Focus: In an ALM workflow, focus on versioning the model metadata (the PBIP folder structure) rather than the PBIX file itself. This is better suited for Git's file-based tracking.

Maintain CI/CD Pipelines

A robust Continuous Integration/Continuous Delivery (CI/CD) pipeline automates the model and policy deployment process:

1. Continuous Integration (CI):

   1. Trigger: Developer commits changes to the Git repository (e.g., adding a new measure, modifying an RLS role).

   2. Action: A build pipeline automatically verifies the model metadata using tools like ALM Toolkit or pbi-tools for schema validation.

2. Approvals:

   1. Necessary approvals are required to push the file changes to version control.

3. Continuous Delivery (CD):

   1. Action: The CD pipeline uses the XMLA endpoint to programmatically deploy the verified metadata and/or policy updates to the Test workspace.

   2. Self-Healing Policy: After every publish/republish of the new version from Source control, ensure the CD pipeline automatically deploys policies (RLS, etc.) to keep security in place.

   3. Promotion: Once verified in Test, the same CD pipeline promotes the changes to the Production workspace.