Power Automate: SharePoint - List folder Action

SharePoint is fantastic at everything related to files, so having Power Automate automating things in the background is even better. Today we'll check on the SharePoint List folder action and how we can use it to help us deal with files and folders if they exist.

So let's look at it in more detail.

Where to find it?

To find it, you can search for the "List folder" action or check on the "Standard" tab:

Pick "SharePoint"

You'll get the list of all SharePoint actions.

Scroll down and you'll find the "List folder" action.

Here's what it looks like:

Usage

To use it, you only need to define the SharePoint site where it's pointing and the file identifier. Those two are the whole configuration, and both are required. There are no advanced options hiding anywhere.

Site Address

The site that contains the folder. Pick it from the dropdown when it's there, or use the "Enter custom value" option and paste the site URL when you're working against a sub-site that doesn't show up in the list.

File Identifier

The folder you want to list. There are two essential things to keep in mind here:

1. The "File" is misleading since we're looking at folders. You'll understand below why this is.
2. It expects the folder "Identifier" and not its "Path". It's a common mistake, so please keep this in mind.

Microsoft is inconsistent here too. The field is labeled "File Identifier", but the connector reference describes it as the "unique identifier of the folder". So the label is wrong and the description is right.

If you don't know the identifier, don't try to build it by hand. Microsoft's own recommendation is to call the "Get folder metadata using path" action first, feed it the path you do know, and take the "Id" it returns straight into this field.

When it runs, we'll get the list of everything in that folder, with the following information:

1. "Id" - This is the identifier that we need to use in other actions.
2. "Name" - The name that you see in the folder view (when you see the file in your computer's file system, for example), including the extension.
3. "DisplayName" - This is the name that is displayed in the "list view" (when you browse the SharePoint site and see the file as an item in a list).
4. "Path" - The full path where the object is located.
5. "LastModified" - When the file was last changed, including when it was created.
6. "Size" - The size of the file in bytes.
7. "MediaType" - The media type can be quite cryptic, but it's a convention that identifies the type of file. For example, an Excel file is represented as "application/vnd.openxmlformats-officedocument.spreadsheetml.sheet"
8. "IsFolder" - One of the most valuable flags, it indicates whether an item is a folder. Therefore, it's handy for filtering purposes. Also, I think this is why the action says "File Identifier" and not "Folder Identifier".
9. "ETag" - The version token SharePoint keeps for the item. A few actions, like "Set content approval status", ask for it so they can confirm you're acting on the version you think you are.
10. "FileLocator" - An internal reference to the item. The connector reference doesn't explain what it's for, so I'd leave it alone unless something specifically asks you for it.

It's a lot of information, but notice that we don't get the file's data. To fetch it, you need to use the "Get file content" action.

Non-intuitive behaviors

It returns folders too, not only files

The official description says the action "returns files contained in a SharePoint folder", but that's not the whole story. Folders come back in the same array, flagged with "IsFolder" set to true. Microsoft's own walkthrough of this action is built around that flag, so it's safe to rely on it.

It only goes one level deep

You get the immediate children of the folder you pointed at, and nothing else. There is no "include subfolders" switch, and there never was one on the SharePoint side. Microsoft documents the workaround on that same page: check "IsFolder" on each item with a "Condition" action, call "Get folder metadata using path" for the ones that are folders, then run "List folder" again with the identifier you get back. One call per level, so plan for it if your structure is deep. If that gets unwieldy, the "Send an HTTP request to SharePoint" action is the usual escape hatch.

The results don't plug straight into the column actions

This one catches people. "List folder" returns a "BlobMetadata" object, while the metadata actions like "Get file metadata" return an "SPBlobMetadataResponse", which carries one extra field: "ItemId". That integer is what the library column actions ("Get file properties", "Update file properties") need, and "List folder" never gives it to you. So take the "Id" or the "Path" into a metadata action first, and use the "ItemId" from there.

There's no "last modified by"

The SharePoint schema is narrower than you might expect. You get "LastModified", so you know when, but there's nothing telling you who. If your flow needs the person, you'll have to fetch it separately.

Limitations

It doesn't reach OneDrive

Although there's a similarly named action for OneDrive, we can't use this one to fetch files from there. It's not quite a limitation, but since OneDrive sits on SharePoint underneath, you'd expect it to work, and it doesn't. The OneDrive for Business connector has its own "List files in folder" action for that job.

There's no paging

The action hands back a plain array. There's no "Top Count" parameter and no continuation token in the response, so everything in the folder comes back in a single call. The OneDrive equivalent does return a page object with a "nextLink", but SharePoint's version never got that treatment. For big folders, the thing to plan around is what happens downstream, since the Power Automate loop and pagination limits depend on your performance profile.

Throttling

The SharePoint connector allows 600 API calls per connection every 60 seconds. That budget is counted per connection, not per flow, so if you're looping over a large folder and calling SharePoint once per item, this is the number to keep an eye on.

Only generic lists and libraries

Flows for lists are supported only in generic lists and generic document libraries. Custom list and library templates are not supported, so things like Announcements, Contacts, Events and Tasks are out.

Troubleshooting Common Errors

The site or folder dropdown comes up empty

Cause: when there's a lot to fetch, the dropdown times out after 35 seconds and loads nothing at all. It looks like a permissions problem, but it's usually just slow.

Solution: use the "Enter custom value" option on the field and paste the site URL, or the identifier you already have. If you don't have the identifier yet, get it with "Get folder metadata using path" and pass it in.

Nothing loads and you're signed in as a guest

Cause: guest user accounts can't view or retrieve dropdown information in connector operations. Conditional access policies, such as multi-factor authentication or device compliance rules, can also block the connector entirely.

Solution: use "Enter custom value" for both fields so you're not depending on the pickers, or run the flow with a connection from an account that isn't a guest.

Recommendations

Here are some things to keep in mind.

Avoid static IDs as much as possible

You should have an excellent reason to have static IDs in the "List folder" action. However, it's dangerous, since SharePoint controls those IDs. It can generate silent errors and a lot of problems. Instead, pick the item from the UI or use an ID from a previous action to ensure it exists and it's future-proof.

Name it correctly

The name is super important in this case since we're defining the folder but only getting its name and not the full path. Always build the name so that other people can understand what you are using without opening the action and checking the details.

Always add a comment

Adding a comment will also help avoid mistakes. Indicate why we're looking at this folder and what you'll do with the data. Also, indicate if you're interested only in the folders or files (or both). It's essential to enable faster debugging when something goes wrong.

Always deal with errors

Have your Flow fail gracefully and notify someone that something failed. It's horrible to have failing Flows in Power Automate since they may go unnoticed for a while or generate even worse errors. I have a template that you can use to help you make your Flow resistant to issues. You can check all details here.

Final Thoughts

"List folder" is a simple action that does one job well, as long as we remember what that job is. It gives us one level of a folder, files and folders together, with just enough metadata to decide what to do next. Point it at the right identifier, check "IsFolder" before you act, and it will serve you nicely.

Back to the Power Automate Action Reference.

Photo by Jubal Kenneth Bernal on Unsplash