Description:

The Remove File workflow step removes a specified file from the file system during workflow execution.

The step supports:

• Specifying the file to remove.
• Supplying the file path as a string value.
• Dynamically determining the file path during workflow execution.
• Removing temporary or no-longer-required files as part of workflow processing.
• Performing file cleanup after another workflow activity has completed.
• Returning a True or False result for subsequent workflow processing.

Usage:

The Remove File step is typically placed after a workflow has created, generated, copied, or otherwise used a file that is no longer required.

The workflow supplies the path of the file to be removed through the File to remove property.

A typical workflow pattern is:

Create/Generate File → Process File → Remove File → Continue Process

This makes the step useful for file-cleanup activities within workflow automation.

The file path can be supplied as a workflow-generated string, allowing the same process definition to remove different files during different workflow executions.

Typical Workflow Suggestions:

Remove a Temporary File

Use the step to clean up a temporary file after the workflow has finished using it.

Example:

Generate Temporary File → Process File → Remove File → Continue Process

The generated file path can be supplied to the File property to remove.

Clean Up an Intermediate File

Use Remove File after an intermediate file has been consumed by another workflow activity.

Example:

Create File → Read/Process File → Remove File → Continue

This pattern helps keep intermediate files from remaining in the file system after processing is complete.

Remove a Generated Output After Processing

Use the step when a generated file is only required temporarily.

Example:

Generate Report → Process Report → Remove File

The workflow can provide the path to the generated report to the removal step once the report has been processed.

Use a Dynamic File Path

The filePath property uses the string data type, allowing the path to be supplied dynamically.

Example:

Determine File Path → Remove File → Continue Process

This allows the same workflow to operate on different files for different workflow instances.

Remove a File After an Integration

Use the step to clean up a file after another workflow activity or integration has consumed it.

Example:

Create Integration File → External Processing → Remove File → Complete

This is useful when a file serves as an intermediate input or output for an integration.

Clean Up Files After Document Processing

Use Remove File after a workflow has finished processing a file.

Example:

Retrieve File → Process Document → Remove File → Continue Process

The file can be removed once the workflow no longer needs it at that stage.

Remove Files Created During Workflow Execution

Use the step as part of a workflow that dynamically generates files.

Example:

Build File → Save File → Process File → Remove File

This can provide a cleanup stage after the file has served its purpose.

Route Processing After File Removal

Use the True and False return paths to control what happens after the step executes.

Example:

Remove File

→ True: Continue Process

→ False: Handle Removal Result

The step provides both True and False return values.

Handle a False Result

Connect the False return path to an appropriate workflow activity when the expected removal result is not obtained.

Example:

Remove File → False → Handle File Cleanup

This gives the workflow an explicit path for the non-True result.

Perform File Cleanup at the End of a Workflow

Use Remove File near the end of a workflow when a file is no longer needed.

Example:

Complete File Processing → Remove File → End

This is a straightforward pattern for workflows that generate or consume temporary files.

Clean Up Multiple Files

Multiple Remove File steps can be used when a workflow has several separate files that need to be removed.

Example:

Process File A → Remove File A → Process File B → Remove File B → Complete

Each step can be configured with the appropriate file path.

Separate File Processing From File Cleanup

Use Remove File as a distinct cleanup stage after the primary processing activity.

Example:

Retrieve Data → Generate File → Process File → Remove File → Finalize

This makes the lifecycle of the temporary file explicit within the workflow.

Example:

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

• Create a new process definition called “removeFileDef” and open it in Designer mode.
• Drag a “removeFile” step to the canvas.
• Connect the dots between the “Start” and “removeFile” 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, additional values are available for configuration.
• Click the “removeFile” step to configure its “Required” properties. Provide a name for the step, then 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 “removeFile” step to configure its “Optional” properties. Enter a file path to remove. Then click the Save button. 

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

• Save the process definition, create a new instance, and execute it. Render the process instance and click the process step to view its properties. When the workflow reaches the Remove File step, FlowWright uses the configured File to remove value to identify the file to remove. The step is explicitly defined as “Removes a file from the file system.” The workflow can then follow the True-or-False return path defined for the step.

• Click the process step to view its properties. The step should permanently delete the file from the server. Verify the file exists at the specified path on the application server. 

Tips:

• Verify that filePath contains the intended file path before the step executes.
• Use a meaningful workflow Variable when storing a dynamically generated file path.
• Test the workflow with representative files before deploying it.
• Verify that preceding workflow activities correctly generate or identify the target file.
• Avoid hard-coding file paths when the target file changes between workflow instances or environments.
• Make sure the workflow has completed all processing that depends on the file before removing it.
• Consider placing Remove File after the final activity that consumes the file.
• Consider connecting both the True and False return paths to appropriate subsequent workflow activities.
• Provide appropriate handling for a False result.
• Use Logging to document file-cleanup activity when the operation needs to be traceable.
• Test the workflow when the supplied file path is missing or invalid.
• Test scenarios in which the target file is unavailable when the step executes.
• Verify that the workflow does not need the file in a downstream activity before removing it.
• Use a consistent file-location convention for temporary files used by workflows.
• Keep dynamically generated file paths maintainable and easy to identify.
• Exercise care when dynamically constructing paths to avoid targeting an unintended file.
• Consider environment-specific file locations when moving a workflow between environments.
• Test the workflow with paths containing spaces and other characters used by the target file system.
• Do not assume that the step removes directories or other file-system objects; the XML describes the operation specifically as removing a file.
• Do not assume that the False return value represents a particular error condition unless confirmed by the FlowWright implementation.
• Do not assume additional behavior such as recursive deletion, recovery, or retention unless confirmed by the FlowWright implementation.
• Because filePath is defined as optional in the XML; verify the step's behavior when no path is supplied rather than assuming how FlowWright handles that situation. 

Notes:

• The Remove File step is defined in the File System category with the internal name removefile, label “Removes a file from the file system,” namespace FlowWright.Workflow.RemoveFile, and display name “Remove File.”
• The step is implemented by FlowWright.Workflow.RemoveFile in FlowWright.Workflow.dll and is defined as a Process step with 2 incoming connections and 2 outgoing connections.
• The step defines one property:
  • filePath – File to remove. 
• The filePath property uses the string data type and is implemented by FlowWright.DataTypes.ClsTextBox in FlowWright.DataTypes.dll.
• Unlike the required inputs in the reference Search Replace String step, the XML marks filePath as required="false".
• The step provides two return values:
  • False
  • True

Definition Sample:

You may provide a sample definition for the Remove File step for download and later import it into the FlowWright Process Definition XML page.

Note: Verify and complete any missing configuration after importing the sample, including:

• File path.
• Variable or workflow value containing the file path.
• Workflow Variable references.
• Environment-specific file locations.
• Target file.
• Downstream True and False workflow paths.
• Logging configuration.
• Downstream activities that may depend on the file.

After verifying the configuration, save the Process Definition before execution.

Click here to download the sample file.