Exporting Paginated Report with EffectiveIdentity Fails for External User Not in Tenant

[Himanshu_G]

Hello Power BI Community,

I'm facing an issue while exporting a paginated report using the Power BI REST API. Here's the context:

• Report Type: Paginated (.rdl)
• Data Source: Azure SQL Database
• Authentication Method: Basic SQL Authentication
• Data Source Credentials: Stored within the RDL report
• DirectQuery: Enabled
• User Credential Requirement: The option "Report viewers can only access this data source with their own Power BI identities using DirectQuery" is disabled
• Service Principal: Used to generate embed tokens and call the ExportToFile API
• EffectiveIdentity: Set to a user who is not part of our Microsoft Entra ID (formerly Azure AD) tenant and does not have direct access to the Azure SQL Database

  Additional Details:

  Our primary requirement is to support external users who are not part of our tenant directory and do not have direct access to the data source. These users are represented in our database solely for filtering purposes. We use the effectiveIdentity parameter to pass the external user's identifier, which is then used within the report to apply Row-Level Security (RLS) filters.

  Behavior Observed:

  • Embedding the Report: Functions correctly. The report renders as expected, applying RLS based on the effectiveIdentity provided.
  • Exporting the Report: Fails when using the same effectiveIdentity.

    Objective:

    We aim to utilize effectiveIdentity exclusively for RLS filtering, without requiring the external user to exist in our tenant directory or have direct access to the data source. The data access should be handled by the stored credentials within the RDL report.

    Question:

    Why does the export operation fail under these conditions, even though embedding works correctly? Is there a way to configure the export process to utilize the stored credentials for data access while still applying RLS based on the effectiveIdentity, even when the user is external to our tenant?

    Any insights or guidance on this matter would be greatly appreciated.

    Thank you!

[v-pgoloju · Accepted solution]

Hi @Himanshu_G,

Thank you for reaching out to the Microsoft Fabric Forum Community.

Exporting a paginated report with effectiveIdentity fails for external users because Power BI requires the identity to be resolvable in Azure AD, even if stored credentials are used.

To support external users who aren't in your tenant:

Remove effectiveIdentity from the export call. Pass a custom parameter (e.g., @UserId) to the report. Implement RLS filtering inside the report or SQL using this parameter. This approach bypasses the identity validation issue while still enforcing user-specific Data access.

If you found this response helpful, please consider marking it as the accepted solution and giving it a thumbs-up to assist others in the community.

Thank you and best regards,
Prasanna Kumar

[v-pgoloju]

Hi @Himanshu_G,

Just a gentle reminder — has your issue been resolved? If so, we’d be grateful if you could mark the solution that worked as Accepted Solution, or feel free to share your own if you found a different fix.

This not only closes the loop on your query but also helps others in the community solve similar issues faster.

Thank you for your time and feedback!

Best,

Prasanna Kumar

[v-pgoloju]

Hi @Himanshu_G,

We wanted to kindly check in to see if everything is working as expected after trying the suggested solution. If there’s anything else we can assist with, please don’t hesitate to ask.

If the issue is resolved, we’d appreciate it if you could mark the helpful reply as Accepted Solution — it helps others who might face a similar issue.

Warm regards,

Prasanna Kumar

[Himanshu_G]

We are currently evaluating this for our use case.
Thank you for the suggestion — it was very helpful.

[v-pgoloju]

Hi @Himanshu_G,

Just following up to see if the solution provided was helpful in resolving your issue. Please feel free to let us know if you need any further assistance.

If the response addressed your query, kindly mark it as Accepted Solution and click Yes if you found it helpful — this will benefit others in the community as well.

Best regards,

Prasanna Kumar

[v-pgoloju · Accepted solution]

Hi @Himanshu_G,

Yes You can Pass Custom parameters.

To enforce Row-Level Security (RLS) in embedded paginated reports—especially for external users not in Azure AD—you can pass a custom parameter like @UserId instead of using effectiveIdentity.

Use stored credentials in the RDL so the report doesn't rely on the user's identity for data access. During embedding, pass the user's identifier as a report parameter, which the report or SQL uses to filter data.

Example:

{
"parameters": [
{ "name": "UserId", "value": "external_user_123" }
]
}

This works for both internal and external users:

External: pass their custom ID.

Internal: pass mapped ID (e.g., email or UPN).

This keeps the report secure and RLS dynamic without needing Azure AD resolution.

If you found this response helpful, please consider marking it as the accepted solution and giving it a thumbs-up to help others in the community.

Thank you & regards,
Prasanna Kumar

[Himanshu_G]

Thank you, @v-pgoloju . That makes sense for export scenarios.

Quick follow-up — how should we handle RLS for external and internal users in an embedding scenario (especially when we can't rely on effectiveIdentity due to the same Azure AD resolution issue)?
Can we still pass custom parameters like @UserId to enforce RLS, or is there a recommended approach for embedding paginated reports securely for external as well as internal users?

Looking forward to your insights!

[v-pgoloju · Accepted solution]

Hi @Himanshu_G,

Thank you for reaching out to the Microsoft Fabric Forum Community.

Exporting a paginated report with effectiveIdentity fails for external users because Power BI requires the identity to be resolvable in Azure AD, even if stored credentials are used.

To support external users who aren't in your tenant:

Remove effectiveIdentity from the export call. Pass a custom parameter (e.g., @UserId) to the report. Implement RLS filtering inside the report or SQL using this parameter. This approach bypasses the identity validation issue while still enforcing user-specific Data access.

If you found this response helpful, please consider marking it as the accepted solution and giving it a thumbs-up to assist others in the community.

Thank you and best regards,
Prasanna Kumar