Get Filelist

Use this step to retrieve a list of files from a directory.

Last published at: March 31st, 2026

getFiles Step

Description:

The GetFiles workflow step retrieves a list of files from a specified folder. It allows the workflow to specify the folder path, optionally define a file scope, optionally include subfolders, and store the resulting file list XML in a Variable or Global variable.

The step is categorized under File System and is displayed in the FlowWright designer as Get Filelist. It is implemented as a Process step with two incoming and two outgoing connections.

The step supports:

  • Specifying the folder from which to retrieve files.
  • Defining an optional file scope.
  • Including or excluding sub-folders.
  • Storing the resulting file list as XML.
  • Reusing the file-list result in subsequent workflow steps.
  • Using the retrieved file information as input to additional file-processing activities.
  • Returning a True or False result for subsequent workflow processing.

 

Inputs

  • folderPath – The physical path of the folder from which the files are to be downloaded. Ex: - C:\Folder1
  • fileScope – File Scope (e.g., *.png)
  • selectSubFolders – Selection of subfolders which are displayed in the main folder. Ex: - /folder1/folder2
  • variableToStore - Variable to store the list of files in XML downloaded from the directory 
 

 

Returns

  • True – the True return path can be connected to the next workflow activity when the file-list operation succeeds.
  • False – the False return path can be used for an alternative or error-handling workflow path when the operation does not succeed.
 

 

Usage:

The Get Filelist step is typically placed after a workflow determines the folder to examine.

The step retrieves the files from the specified folder and stores the result as XML in the configured Variable/Global.

A typical workflow pattern is:

Determine Folder → Get Filelist → Process File List

You can then pass the resulting XML to subsequent workflow activities for additional processing.

For example:

Get Folder Path → GetFiles → Read/Process XML → Process Files

This approach separates file discovery from file processing, allowing the same retrieved file list to be used by multiple downstream activities.

The reference page's documentation style similarly places the processing step after the required source information has been collected, then stores the resulting value for subsequent activities.

 

Typical Workflow Suggestions:

Retrieve Files from a Folder

Use GetFiles when a workflow needs to discover the files currently available in a particular folder.

Example:

Determine Folder → Get Filelist → Continue Processing

The resulting XML can be stored in a Variable/Global for later use.

 

Process Files from an Input Folder

Use the step as the first stage of a file-processing workflow.

Example:

Get Filelist → Read File List → Process Files

This is useful when a workflow needs to discover files before deciding what processing to perform.

 

Process Files from a Sub-Folder Structure

Enable Select sub-folders when the workflow needs to include files from sub-folders.

Example:

Select Root Folder → GetFiles → Process Retrieved File List

This allows the workflow to work with a folder structure rather than limiting the operation to the selected folder.

The exact behavior of sub-folder traversal should be validated against the FlowWright implementation and environment configuration.

 

Retrieve Files Using a File Scope

Use the File scope property when the workflow needs to restrict the files considered by the operation.

Example:

Get Folder → GetFiles (File Scope) → Process Matching Files

The XML identifies File Scope as an optional string property but does not define its supported syntax.

 

Build a File-Processing Pipeline

The file list can serve as an intermediate result between file discovery and downstream processing.

Example:

GetFiles → Parse File List → Read File → Transform File → Store Result

This clearly separates finding files from working on them.

 

Prepare Files for Document Processing

Use GetFiles to discover documents that need to be processed by subsequent workflow activities.

Example:

Document Folder → GetFiles → Document Processing

Possible downstream processing could include reading, transforming, moving, or otherwise handling files according to the business process.

 

Automate Folder-Based Intake

Use the step when a workflow operates on files placed into an input or staging folder.

Example:

Input Folder → Get Filelist → Process New Files → Move/Archive Files

This provides a workflow pattern for folder-based file intake.

The exact mechanism used to determine whether a file is new or has already been processed should be implemented separately; the GetFiles XML only defines the file-list retrieval inputs and XML result destination.

 

Store the File List for Multiple Downstream Activities

The variableToStore property allows the retrieved file-list XML to be retained in a Variable/Global.

Example:

GetFiles → Store XML → Activity A
→ Activity B
→ Activity C

This can be useful when several workflow activities need access to the same file-list information.

 

Combine File Discovery with XML Processing

Because the result destination is explicitly described as storing XML, the step can be used as the file-discovery stage of an XML-processing workflow.

Example:

GetFiles → Get XML Node/Value → Process File Information

Design the downstream XML-processing logic around the structure produced by the FlowWright implementation.

 

Add Conditional Handling for File Retrieval

Use the True and False connections to control what happens after the file-list operation.

Example:

GetFiles

→ True: Continue file processing
→ False: Handle alternate condition

This is useful when the workflow needs a defined path for an unsuccessful operation.

 

Example:

Let’s build and execute the “getFilesDef” example.          

  • Create a new process definition named “getFilesDef” and open it in Designer mode. 
  • Drag a “getFiles” step to the canvas.
  • Connect the dots between the “Start” step and “getFiles” steps, as shown above. 
  • Select the line between the steps to configure the “Connection Properties”. The default property values are “None, True, False, Error, and Evaluate”. Depending on the step’s purpose, you can configure additional values.
  • Define a variable or a global to store the result. 
  • Click the “getFiles” step to configure its “Required” properties. Provide a name for the step. Provide the folder path to download from. Provide a variable or global reference to store the file list in XML format after execution. Click the Save button. Note: Click the "AI Predict" button to have the Copilot add new process steps that match your process description. 

 

  • Click the “getFiles” step to configure its “Optional” properties. Provide the file scope (wildcard for filtering). Select “Yes” to download files from subfolders. Click the Save button. 

 

  • The “Logging” configuration is necessary for documentation and also measures workflow progress and percent complete. Configure the step state and percent fields individually, as shown below. Configure the “Logging” using the following properties.

 

  • Save the process definition, create a new workflow instance, and execute it. Render the process instance and click the Get Filelist step to inspect its properties and execution. When the workflow reaches the step, FlowWright processes the configured folder and file-scope settings and stores the resulting file-list XML in the specified Variable/Global. The reference documentation follows the same execution pattern: save the definition, create and execute an instance, render the instance, and inspect the step when execution reaches it. During testing, verify the resulting Variable/Global to confirm that the expected file-list information was produced.

 

Tips:

  • Use a valid folder path. The Path to the folder property is required. 
  • Use a meaningful result Variable/Global. Names such as varFileListXml, FileListXml, or InputFilesXml make downstream workflow configuration easier to understand.
  • Test with a folder containing known files. This makes it easier to verify that the retrieved result corresponds to the expected folder contents.
  • Test sub-folder behavior separately. Run one test with sub-folders disabled and another with sub-folders enabled so that the resulting behavior can be verified.
  • Use File Scope carefully. Keep the scope specific enough to prevent unintended files from entering subsequent processing.
  • Verify the XML result. The property is explicitly intended to store the file list as XML. Inspect the actual XML generated by your FlowWright environment before building complex downstream XML processing around its structure. 
  • Use a dedicated Variable/Global for the result. Avoid overwriting unrelated workflow data with the file-list XML.
  • Consider downstream error handling. Connect the False path to an appropriate handling activity when file retrieval failure needs to be addressed.
  • Test empty-folder scenarios. Verify how the workflow behaves when the selected folder does not contain files that meet the configured criteria.
  • Test with and without sub-folders. This is particularly important when workflows operate against nested folder structures.
  • Test the configured File Scope with representative file names. The XML does not define the matching syntax, so verify the expected behavior in the FlowWright environment.
  • Keep file-processing logic separate from file-discovery logic. A pattern such as GetFiles → Process File List → Process Files makes the workflow easier to understand and maintain.
  • Avoid assuming recursive behavior. Selecting sub-folders indicates that sub-folders can be configured for the operation, but the XML does not document the exact traversal behavior.
  • Do not assume a particular XML schema. The XML definition identifies the destination as a Variable/Global to store the XML, but it does not document the individual XML elements or attributes returned.
  • Do not assume File Scope supports a particular wildcard or regular-expression syntax unless that behavior is confirmed in the FlowWright implementation.
  • Use realistic test folders. Include files with different names, extensions, and locations when validating file-scope and sub-folder behavior.
  • Verify the stored result before downstream processing. This helps isolate whether a problem originates in file retrieval or in a later workflow activity.

 

Definition Sample:

You may create or download a sample process definition containing the Get Filelist step and import it into the FlowWright Process Definition page.

After importing a sample, verify and complete any missing configuration, including:

  • Path to the folder.
  • File scope, if required.
  • Select sub-folders setting.
  • Variable/Global used to store the XML.
  • Workflow Variable references.
  • Environment-specific folder paths.
  • Downstream True and False workflow paths.

Click here to download the sample file.