Forum Discussion
Schedule Refersh fails
I'm a guest user from Company A, working in Company B's tenant (they own the data/server). I created a dataflow (using gateway, since the SQL server is on a private endpoint), then built a report in Desktop and published it back to Tenant B.
Problem:
Scheduled refresh fails, but if I do an on-demand refresh right after re-entering OAuth2 credentials, it works fine.
Any idea why the scheduled refresh doesn't retain the token? How can I make this stable? ( i have Pro licence, created gen1 dataflow)
here is the error:
Expression.Error: The key didn't match any rows in the table.. Microsoft.Data.Mashup.ErrorCode = 10061. Key = [workspaceId = "d0e9076d-5f07-4146-a855-9271cbcf0411"]. Table = #table({"workspaceId", "workspaceType", "Data", "workspaceName", "Tags", "ItemKind", "ItemName", "IsLeaf"}, {}). ;The key didn't match any rows in the table.. The exception was raised by the IDbCommand interface. Table: Claim.
Thanks
Hi Pal_S
You're encountering a common but nuanced issue related to token persistence and workspace access permissions for guest users in Power BI, particularly when using OAuth2 authentication with dataflows in a cross-tenant setup. As a guest user from Company A working in Company B's tenant, the credentials you provide during an on-demand refresh are tied to an interactive session—meaning Power BI temporarily caches your OAuth2 token to complete the refresh. However, in a scheduled refresh, Power BI relies on stored credentials or service-level authentication that must be persistently valid without user interaction. Unfortunately, for guest users, OAuth2 tokens often expire or fail to persist properly for background service refreshes, especially in Gen1 dataflows where credential caching isn't as robust and multi-tenant authentication can break silently.
The error you're seeing — The key didn't match any rows in the table — is misleading but commonly surfaces when Power BI cannot authenticate properly or access the workspace/dataflow metadata, often due to invalid or expired credentials rather than a real schema issue.
To resolve this, you can try the following:
Ensure you re-enter credentials in the dataflow settings under "Edit Credentials" in the Power BI Service (not just Power BI Desktop) and choose Organizational Account + OAuth2 as the authentication method.
Consider switching from a Gen1 to a Gen2 dataflow, which offers better support for enterprise data gateway integration and more resilient credential management.
If possible, request that a native user in Company B’s tenant (not a guest) owns the dataflow and sets up the scheduled refresh. As a guest, you may lack certain hidden permissions that the Power BI service expects during unattended execution.
If the data source is behind a private endpoint, ensure that the gateway is correctly configured and accessible to the Power BI Service under your guest context—sometimes guest users are not permitted to execute through gateways for scheduled operations due to tenant security policies.
Lastly, reach out to Company B's Power BI admin to verify that cross-tenant access and OAuth token persistence for guests are allowed in Azure Active Directory settings. Some tenants restrict token caching or have conditional access policies that block background OAuth flows for guest accounts.
Ultimately, the most stable solution—if allowed—is to have a native user in Company B’s tenant manage the dataflow or use a service principal with proper gateway and data source credentials configured, which avoids these token volatility issues entirely.
9 Replies
v-sdhruvCommunity Support
Hi Pal_S ,
Just wanted to check if you had the opportunity to review the suggestions provided?
Thank you rohit1991 and Poojara_D12 for such detailed explaination and suggestions to fix the issue.
The solutions provided correctly addresses the issue.
If any of the responses has addressed your query, please accept it as a solution so other members can easily find it.
Thank You- collinq
Super User
Hi Pal_S ,
This could be a permissions error... if it is working for you when you do it on demand but does not do it when it is scheduled can you confirm that the Data Source is set up in the Gateway? You should probably get a service account or service principal to run the refresh and that way it won't be a token being issued for each refresh.
You might also want to set the Data Source to "Organizational" as that might get you around the token issue - but that might only be for a while. Thanks for reply
The other company is reluctant to provide a member account due to security policies. As for the service principal option,I believe that requires Premium capacity, and I currently only have a Pro license.
workflow:sql server --> (via gateway)dataflow---> semantic model
I generally keep the gateway option off-- so on demand refresh works via personal cloud connect.- v-sdhruv
Hi Pal_S ,
The error message ---- Expression.Error: The key didn't match any rows in the table-----suggests a mismatch or invalid reference during scheduled refresh, likely due to token expiration or workspace context loss.
Try Switching to organizational data source because switching the data source to “Organizational” in Power BI service as suggested by collinq or
you can even create a shared workspace within your tenant and export data from Company B.
Hope this helps!
If the response has addressed your query, please accept it as a solution so that other members can easily find it.
Thank you. Hi,
I’m already using the “Organizational” data source, so that piece looks correct, i guess?
Exporting the data to my own tenant would still require a daily re-publish, which doesn’t solve the scheduled-refresh issue.I remain a guest in Company B’s tenant. I suspected this was the blocker, but Company B created a new guest test account and its scheduled refresh ran successfully, so they’re not keen to promote my account to a member.
Are there any other settings or permissions that could explain why the refresh fails only for my account?
Also, any suggestion, how token expiration issue can be resolved?Thanks!
- rohit1991
Hi Pal_S
Microsoft’s guidance is that OAuth2 data sources used from the Power BI Service must be in the same tenant as the service; multi-tenant OAuth2 isn’t supported. In cross-tenant (guest) scenarios, the service can’t reliably renew the OAuth token during scheduled refresh manual refresh works because you re-authenticate interactively.
Fixes that work:
- Own the refresh with a native identity in Company B (member account or service principal). Make it the owner of the dataflow + dataset, then re-enter credentials.
- Avoid OAuth2 for the SQL source: use the Enterprise Gateway in Company B with SQL/Windows/Basic creds (stored on the gateway).
- Keep the dataset and dataflow in the same tenant/workspace and give the refresh identity Build permission.
Quick check: in Dataset settings >> Data source credentials, the account should show Organization: Company B for every OAuth source. If it shows your home (Company A) context anywhere, scheduled refresh will keep failing.
Reference: https://learn.microsoft.com/en-us/power-bi/connect-data/refresh-scheduled-refresh - Poojara_D12
Hi Pal_S
You're encountering a common but nuanced issue related to token persistence and workspace access permissions for guest users in Power BI, particularly when using OAuth2 authentication with dataflows in a cross-tenant setup. As a guest user from Company A working in Company B's tenant, the credentials you provide during an on-demand refresh are tied to an interactive session—meaning Power BI temporarily caches your OAuth2 token to complete the refresh. However, in a scheduled refresh, Power BI relies on stored credentials or service-level authentication that must be persistently valid without user interaction. Unfortunately, for guest users, OAuth2 tokens often expire or fail to persist properly for background service refreshes, especially in Gen1 dataflows where credential caching isn't as robust and multi-tenant authentication can break silently.
The error you're seeing — The key didn't match any rows in the table — is misleading but commonly surfaces when Power BI cannot authenticate properly or access the workspace/dataflow metadata, often due to invalid or expired credentials rather than a real schema issue.
To resolve this, you can try the following:
Ensure you re-enter credentials in the dataflow settings under "Edit Credentials" in the Power BI Service (not just Power BI Desktop) and choose Organizational Account + OAuth2 as the authentication method.
Consider switching from a Gen1 to a Gen2 dataflow, which offers better support for enterprise data gateway integration and more resilient credential management.
If possible, request that a native user in Company B’s tenant (not a guest) owns the dataflow and sets up the scheduled refresh. As a guest, you may lack certain hidden permissions that the Power BI service expects during unattended execution.
If the data source is behind a private endpoint, ensure that the gateway is correctly configured and accessible to the Power BI Service under your guest context—sometimes guest users are not permitted to execute through gateways for scheduled operations due to tenant security policies.
Lastly, reach out to Company B's Power BI admin to verify that cross-tenant access and OAuth token persistence for guests are allowed in Azure Active Directory settings. Some tenants restrict token caching or have conditional access policies that block background OAuth flows for guest accounts.
Ultimately, the most stable solution—if allowed—is to have a native user in Company B’s tenant manage the dataflow or use a service principal with proper gateway and data source credentials configured, which avoids these token volatility issues entirely.
