“The HTTP request to SharePoint keeps giving me the ‘list not found’ error, but the list exists, why can’t Power Automate find it?”
When using HTTP requests to SharePoint to extend the Power Automate possibilities, you often reference the list by its name. I’ve been doing the same in most of the articles, even in the HTTP requests cheat sheet.
While it’s an easier approach, it has a downside – if you or somebody else rename the list, the request will stop working. It’ll search for a list with a specific name, it won’t find it, the flow will fail – list not found. How do you then build more future-proof solution?
Use the list GUID instead of the name
Let’s take as an example a url to update a single SharePoint column.
_api/web/lists/GetByTitle('<ListName>')/items(<ItemID>)/validateUpdateListItemAs you might guess, the GetByTitle(…) is where it’s looking for the list by the name. That’s the part you want to get rid of, no searching by the title.
Take the list directly using its unique id.
_api/web/lists('<listID>')/items(<ItemID>)/validateUpdateListItem
As the list id is unique and unchanging, such http request will work as long as the list exists. It doesn’t matter whether anybody changes the list name, id will stay the same.
Summary
When building flows, it’s a good idea to reference the unchanging identifiers of everything. That’s why all the filters, queries, and expands use the column internal names – they don’t change. The same approach makes sense when referencing SharePoint lists. If you search by list title, something many users can change, there’s a chance that your Power Automate flow will fail – http request will return the ‘list not found’ error. To avoid this potential issue use the list guid instead of the name. It might be more effort to find the id and it’ll make the flow a bit harder to read (always document your flows!), but it’ll be more reliable in the long term.