For Each File/Folder suddenly ignoring "Include Subfolders = False" since 22/23 August, no package changes

Help Activities
, , ,
1

Summary

Hi community,

A dispatcher process of mine that has run unchanged since May 2026 started returning files from subfolders on the first run after the weekend of 22/23 August 2026, despite Include Subfolders being set to False. Nothing was republished, nothing changed in SharePoint, and all our virtual machines (and my local development machine) show the same results. Looking for confirmation from anyone seeing the same, and ideally from UiPath on whether the enumeration strategy inside this activity is controlled server side.

Environment

  • Studio 25.10.13 LTS, Windows target framework, project type Process
  • UiPath.MicrosoftOffice365.Activities 3.7.10
  • UiPath.IntegrationService.Activities [1.24.0] (strict)
  • UiPath.System.Activities 26.2.4
  • Orchestrator Cloud, unattended Windows robots
  • Activity: For Each File/Folder - UiPath.MicrosoftOffice365.Activities.Files.ForEachFileFolderConnections

What the process does

A “cleaner” runs hourly. It checks Orchestrator for Running or Pending jobs of a performer process. If any exist it exits. If not, it waits 5 minutes (to cover the event trigger polling interval), re-checks, and then loops over three dedicated SharePoint folders. For every .txt file found it starts a performer job, passing the folder name and file name as input arguments. It exists as a safety net for files the O365 event trigger occasionally misses.

Each of the three For Each File/Folder activities is configured identically:

Include Subfolders  = False
What to return      = Files
Filter (advanced)   = FileExtension Equals "txt"
Item selection mode = ItemUrl

Each dedicated folder contains a done subfolder used as an archive, holding several months of processed files.

Intended vs actual

Intended: the loop returns only the loose .txt files sitting in the root of each dedicated folder, not picked up by the event triggers in Orchestrator, typically 0 to 4 per day.

Actual since 24 August: the loop returns everything below the folder as well, including the done archive. One run found 206 files across the three folders and queued 206 performer jobs. The performer then failed to find each file in the folder root and exited, so no data damage, but 200+ wasted runtimes regardless.

Timeline

All times UTC. Runtime is a clean proxy here, since the workflow does nothing but the 5 minute wait when it finds no files.

Fri 21 Aug 19:30   05m24s   last good run
Mon 24 Aug 04:30   24m37s   first bad run, 206 files
Mon 24 Aug 05:30   25m28s
Mon 24 Aug 06:30   24m59s

Every run from 18 to 21 August took ~5m25s. The break is between Friday evening and Monday morning. Logs for one good and one bad run are attached.

What we have already ruled out

  • Package change. The process package was published 26 May 2026 and is still the live version, no changes were published on our end recently.
  • Workflow misconfiguration. The XAML was re-read line by line. All three loops still carry IncludeSubfolders="False" and WhatToReturn=Files.
  • SharePoint changes. The folder structure is untouched. One of the three folders is a dormant test folder that has not been modified in months and it is affected too.
  • Files having been moved. The performer logs a download error for each file, proving the files are still physically in the done subfolder and the loop is genuinely recursing.
  • Deprecated dependencies. The dependency is declared as 3.7.10, however the issue persists on a newer version, I tested and got the same result on 3.11.10 on a completely separate dummy/testing process. Also reproduces the same result on an older version, 2.9.10.
  • A single bad robot. Four unattended robots are in the pool. One of them ran the job successfully on Friday afternoon and incorrectly on Monday morning. All are affected.

What we found inside the activity package

Inspecting UiPath.MicrosoftOffice365.dll from 3.7.10, the activity appears to have two enumeration paths, and which one it takes is decided at runtime:

GetEntitiesAsyncIteratorUsingSearchApi
SupportsSearchApiAsync
SearchApiLocationAndBelowFilterTemplate
SearchApiFilesOnlyTemplate

The scoping template is named LocationAndBelow, which is recursive by definition. On that path Include Subfolders = False cannot be expressed in the query and would have to be applied client side afterwards.

The same assembly also ships a feature flag client with updatable flags:

FeatureFlagClient`1+<GetSnapshotAsync>
FeatureFlagsUrlFormat
SetUpdatableFlags

That would explain a behaviour change across every robot at once, overnight, with no deployment on our side. This is inference rather than something we can verify, hence the post.

Questions

  1. Has anyone else seen a filtered For Each File/Folder start including subfolders since roughly 22/23 August 2026?
  2. Is the Search API code path in this activity gated by a server side feature flag or by connector capability negotiation? If so, was anything rolled out this past weekend?
  3. Is Include Subfolders = False intended to be honoured on the Search API path, or is it only enforced on the plain children listing path? If the latter, that looks like a bug rather than a configuration issue.
  4. As a workaround, does removing the advanced filter and filtering the extension inside the loop body reliably keep the activity on the non recursive children listing? That is what we plan to test.

Any confirmation or pointers appreciated. Happy to provide more detail or raise a support ticket with the full traces. I’ve included the exported logs of a ‘happy path’ and a ‘bad run’ as well.

robot-logs-2026-08-24-09-29-26-460-767611.zip (897 Bytes)
robot-logs-2026-08-24-09-28-31-937-767608.zip (8.7 KB)

2

Thank you for the report. We will have a look!

In the meantime, could you please test one thing for us:

  1. Remove the advanced filter (the FileExtension Equals “txt” condition).
  2. Leave the Search field empty as well.
  3. Filter the extension inside the loop body instead, e.g., an If on CurrentItem.Extension = “.txt”.

Apart from that, could you also share your folder structure? (It doesn’t have to have real names; it’s the hierarchy that matters.)

3

Heya, thanks for picking this up.

Have been testing around to see what works, and I can confirm your assumption:
with the advanced filter removed and the search field left empty, the activity behaves correctly.
It returns only direct children and subfolders are ignored. I’m currently rewiring the process to filter the extension within the loop, as well as an extra check on the parent folder just to be sure.

One finding that could help narrow this down for you: the trigger of this issue is the presence of ANY query, not the content of the filter. I tested all four input modes against the same folder:

  Advanced search (FileExtension Equals "txt")   -> returns subfolder files
  Simple search   ("txt")                        -> returns subfolder files
  Query Filter    ("filetype:txt")               -> returns subfolder files
  Free Text Filter                               -> returns subfolder files
  No query at all                                -> correct, direct children only

Folder structure as requested:

Team Site
└── Documents
    └── Overarching Folder
        └── Overarching Folder
            ├── Key Folder A        <- First folder being monitored
            │   ├── 1 Done
            │   └── 99 Failed
            ├── Key Folder B        <- Second folder being monitored
            │   ├── 1 Done
            │   └── 99 Failed
            └── Key Folder C        <- Third folder being monitored
                ├── 1 Done
                └── 99 Failed

Files to process sit directly in Key Folder A/B/C. Processed files are moved one level down into the archive subfolders.

Thinking the folder structure is not the cause though, if I create a dummy work flow with a blank ‘for each file’ activity on just the base ‘Documents’ folder of any SP Teams site with any filter, it returns data from subfolders as well.

Happy to fetch you more data / tests if needed. :slight_smile:

4

Hi @HERRYGERS_Wouter,

This definitely looks more like a potential activity/connector behavior change than a workflow configuration issue, especially since you reproduced it across multiple package versions and robots without any deployment changes.

Your investigation around the Search API path and the LocationAndBelow query is particularly interesting. If that path is being enabled dynamically, Include Subfolders = False should still ideally be enforced by the activity, even if additional client-side filtering is required.

As a temporary workaround, I would suggest testing the activity without the Advanced Filter and then filtering the .txt extension inside the loop. You could also add an additional validation comparing the item’s parent folder/path with the expected root folder before starting the performer job. This would prevent archived files from being processed even if recursive results are returned unexpectedly.

Since the behavior changed simultaneously across different robots and package versions, raising a UiPath Support ticket with the logs and your reproduction details would probably be the best next step.

Great investigation and detailed analysis!

5

Hi @MayureshOfficial_45,

Thanks! And yes, that is indeed the kind of temporary workaround I went for.

Instead of the advanced filter the search query is now empty (no simple, advanced, query or free text filter)

I moved the filtering into the loop with the following nested condition:

  CurrentItem.Extension.ToLower = "txt" AndAlso
  CurrentItem.ParentUri.ToLower.EndsWith("/foldername")

That way I can retain the filtering on .txt files as desired and ensure files from any subfolders are not being taken into account.

The parent folder Uri check is redundant in the current setup, as the for each file activity correctly returns only the direct children and nothing from subfolders when we’re not using any filters in the activity.
I kept it deliberately as a guard in case I switch back to using a filter query.

Can verify that the workaround does the intended job, so the process in production can carry on. Thanks for your suggestion as well!

Interested in the follow-up from UiPath’s side to see if there’s anything going on activity/connector level, so I’ll keep the topic open for now. :slight_smile:

6

Hi @HERRYGERS_Wouter,

That’s great to hear! :blush: Glad the workaround is working as intended and that the production process can continue safely.

The additional ParentUri validation is also a good defensive check, especially if you decide to use a filter query again in the future.

Thanks for sharing the exact workaround and confirming the results. It will definitely be helpful for anyone else facing the same issue. Hopefully, we will get some clarification from UiPath regarding the activity/connector behavior.

Thanks again for the detailed update!

7

Hi @HERRYGERS_Wouter,

Glad to hear that the workaround helped and that the process is now working correctly! :blush:

If this solution/workaround resolved your issue, could you please mark the relevant reply as the Solution? It may also help other community members facing the same problem.

Thanks!

8

Hi @HERRYGERS_Wouter,

Thank you for marking my reply as the solution! :blush: I’m glad the suggested workaround helped and that your production process is now running correctly.

Also, thank you for sharing the detailed implementation and confirming the results—it will definitely help other community members facing a similar issue. Hopefully, UiPath will provide further clarification on the underlying behavior as well.

Thanks again!

9

All good!

@loginerror I marked the above response as a temporary solution, since it is for this particular process.

Would be happy to know if there’s anything you’ve noticed on your end in terms of the behaviour of this activity (or package/dependency as a whole), as I’m sure there will be others impacted should indeed something have changed in how it works. I’ve got plenty of other workflows that use it and I’m pretty sure this will reproduce on every one of them if they use an O365 activity with a filter/query.

Can also confirm this happens on the UiPath.MicrosoftOffice365.Activities.Files.GetFileListConnections activity, so it’s not limited to the For Each File activity. :face_with_monocle:

Update 27/08/2026.

UiPath have confirmed that they were able to replicate the issue on their end. Their development team is looking at it and will hopefully provide a fix soon. :slight_smile:

image
image1114×726 45.5 KB