Forum Discussion
We cannot process the request as we encountered a transient issue when trying to determine user
Problem solved,
The issue was that I had workspaces within different regions. To move it I have used Tabular Editor 3, after deploying model, I need to change a shared connection string to point to the lakehouse already created within target workspace.
Best,
Jacek
The error you're seeing: "We cannot process the request as we encountered a transient issue when trying to determine user permissions defined in OneLake" with code PFE_UNIVERSAL_SECURITY_TRANSIENT_ERROR—typically means the Microsoft Fabric service had a temporary problem checking the OneLake permissions required by your semantic model or associated lakehouse/shortcut. This is a short-lived platform or security resolution issue, so simply retrying the operation after several minutes usually resolves it.
Best Practices for Moving Semantic Models (Using Microsoft Tools Only)
Deployment Pipelines: Use Fabric deployment pipelines when moving semantic models between workspaces in the same tenant, provided both workspaces are on Premium or Fabric capacity. This is the official, supported method for migrating semantic models along with data and partitions.
Power BI REST APIs: For large models or CI/CD scenarios, export from one workspace using the Export API, then import to the target workspace with the Import API. This method preserves model data, and is ideal for Fabric and large Direct Lake models.
SSMS/XMLA Endpoints: You can use SQL Server Management Studio (SSMS) to connect to the XMLA endpoint of the target workspace and restore the model using TMSL. This is recommended for exact copies within the same tenant for models too large for PBIX export/import.
ALM Toolkit or PBIP Structure: For small models or metadata-only moves, you can use ALM Toolkit or PBIP deployments, though these won't copy lake or import model data. Avoid .pbix direct publishing for large Direct Lake models.
Troubleshooting Tips
Confirm both source and target workspaces are in the same region/capacity and that necessary permissions on OneLake items are granted and propagated for the service principal or user.
If using TE3 or third-party tooling, transient errors are more likely; using Microsoft-native methods (pipelines, REST APIs, SSMS) makes failures less frequent.
For repeated errors, review OneLake security settings, check for capacity assignment issues, and make sure no recent platform outages are impacting the region.
Retry first, and if the problem persists, use deployment pipelines or REST API export/import for the most robust and supported migrationn path.