Forum Discussion
New, consistent refresh failures
yamyam1 The suggestions so far all come back to re-entering the credentials, and your first sentence already says you did that across all four spreadsheets and the error persisted. I'd treat that as information rather than something to repeat, because a credential prompt can only fix a credential, and there's a documented way to break a file-based source that no amount of re-authenticating will touch.
Microsoft's data refresh doc says this about files hosted on OneDrive or SharePoint Online: "You can move the file to another location (using drag and drop, for example) and refresh will continue to work because Power BI still knows the file's item ID. However, if you copy that file to another location, a new instance of the file and new item ID is created. Therefore, your Power BI file reference is no longer valid and refresh will fail." That distinction is sharper than it looks, and it's the reverse of what most people check. Moving a spreadsheet is safe. Copying one is not.
So the question isn't whether the files moved, it's whether any of the four quietly stopped being the same file. A Save As over the top, a new version uploaded rather than edited in place, a restore from the recycle bin or a backup, a library or site migration, someone rebuilding the sheet and re-uploading it. Every one of those produces a new item ID sitting at the same path, so it looks completely normal in the browser while Power BI is still holding a reference to something that no longer exists.
Two things worth pinning down before you change anything else. Which of the four is actually failing? With four spreadsheets it's easy to spend an afternoon re-authenticating three that were never broken. And your own title says new and consistent, which is a useful detail rather than a throwaway one, because a token or throttling problem tends to come and go, while a reference pointing at a file that no longer exists fails every single time in exactly the same way. Consistent fits the second one better than the first.
When did the first failure land, and does that date line up with anything being re-uploaded, restored or migrated on the SharePoint or OneDrive side of things?
yamyam1 The suggestions so far all come back to re-entering the credentials, and your first sentence already says you did that across all four spreadsheets and the error persisted. I'd treat that as information rather than something to repeat, because a credential prompt can only fix a credential, and there's a documented way to break a file-based source that no amount of re-authenticating will touch.
Microsoft's data refresh doc says this about files hosted on OneDrive or SharePoint Online: "You can move the file to another location (using drag and drop, for example) and refresh will continue to work because Power BI still knows the file's item ID. However, if you copy that file to another location, a new instance of the file and new item ID is created. Therefore, your Power BI file reference is no longer valid and refresh will fail." That distinction is sharper than it looks, and it's the reverse of what most people check. Moving a spreadsheet is safe. Copying one is not.
So the question isn't whether the files moved, it's whether any of the four quietly stopped being the same file. A Save As over the top, a new version uploaded rather than edited in place, a restore from the recycle bin or a backup, a library or site migration, someone rebuilding the sheet and re-uploading it. Every one of those produces a new item ID sitting at the same path, so it looks completely normal in the browser while Power BI is still holding a reference to something that no longer exists.
Two things worth pinning down before you change anything else. Which of the four is actually failing? With four spreadsheets it's easy to spend an afternoon re-authenticating three that were never broken. And your own title says new and consistent, which is a useful detail rather than a throwaway one, because a token or throttling problem tends to come and go, while a reference pointing at a file that no longer exists fails every single time in exactly the same way. Consistent fits the second one better than the first.
When did the first failure land, and does that date line up with anything being re-uploaded, restored or migrated on the SharePoint or OneDrive side of things?
Someone moved a source spreadsheet and moved it back. How do I fix this?
yamyam1 Worth knowing up front that what you've described shouldn't have broken anything, going by Microsoft's own wording. The refresh doc is explicit that a move is safe: "You can move the file to another location (using drag and drop, for example) and refresh will continue to work because Power BI still knows the file's item ID." It's the copy that kills it, because "a new instance of the file and new item ID is created."
That's not me dismissing what you found, it's the useful part. It narrows the question from "did it move" to "was it actually a move", and those two look identical afterwards. A drag and drop inside the same library is a real move and keeps the item ID. Anything that went out and came back a different way, so download and re-upload, Save As, a restore from the recycle bin or from a backup, a Move To across libraries or sites, creates a new file object with a new item ID even when the name and the path end up exactly where they started. Somebody putting a file back "where it was" is honestly more likely to have done one of those than a clean drag.
There's a free way to tell which happened and it takes about ten seconds. Open the file in SharePoint and look at Version history. Move To carries the history with it, in Microsoft's words "When you use Move to, the history of the document is copied to the new destination", whereas "When you use Copy to with documents that have version history, only the latest version is copied." So:
If the history runs continuously back past the day this happened, it's the same file with the same item ID, the move isn't your cause, and I'd stop there and look elsewhere.
If the history starts fresh at version 1.0 dated around the incident, it's a new file wearing the old one's name. That's your answer, and it also explains the two things that must be baffling you: why moving it back didn't fix it, and why re-authenticating all four spreadsheets got you nowhere. The credential was never the problem. The thing the model is pointed at stopped existing.
If it's the second one, the repair is on the Power BI side rather than the SharePoint side. Open the model in Desktop, go into Power Query, and look at the Source step for that one spreadsheet. If the URL has sourcedoc= followed by a GUID in it, that GUID is the old file's identity and it's the thing that stopped resolving, so re-navigate to the file through Get Data rather than editing the URL by hand and let it pick up the new identity properly. If the URL is instead a plain folder and filename path with no GUID in it, then this isn't your problem, and it's worth knowing that before you spend an afternoon on it.
One thing that saves time either way: you don't have to guess which of the four it is. Open the semantic model's refresh history in the service and look at the error detail on the failed run, it names the data source it choked on. That's the only one you need to touch.
