Automation and Scheduled Jobs

Use Windows Task Scheduler or your enterprise job runner to start PowerShell scripts. The module provides commands and transfer tools; it has no built-in scheduler or file watcher.

For managed file movement or processing after file arrival, first check the integration decision guide and Automations documentation. Agent and Automation workflows can handle jobs that would otherwise need a custom script, according to their configuration.

Prepare the Scheduled Account

Use a dedicated Files.com identity with only the site, Workspace and permissions the job needs. Store its API key in a secret vault, as Authentication describes. The scheduled Windows account must be able to retrieve it without an interactive unlock or sign-in prompt.

Install the module for that Windows account, or make the approved installation available to it. A CurrentUser installation under your own account may not be available to the scheduled account. Test with the same supported PowerShell version, identity and vault configuration as the job. Use absolute paths for scripts, inputs, outputs and checkpoint files, and prevent overlapping runs that could modify the same files.

Run an Unattended Transfer

The installed Send-FilesNightlyExport.ps1 uploads files directly inside a local folder, with parallel parts within a shared budget; it does not recurse into subfolders. It reports each file's outcome and checks remote checksums when upload completion is uncertain. Use Send-FilesDirectory for a whole tree.

A small job script can retrieve the credential and call that complete example:

C:\Jobs\NightlyFilesExport.ps1

$ErrorActionPreference = 'Stop'
Import-Module FilesCom.PowerShell
$examples = Join-Path (Get-Module FilesCom.PowerShell).ModuleBase 'examples'

$results = & (Join-Path $examples 'Send-FilesNightlyExport.ps1') `
    -ApiKey (Get-Secret -Name FilesComApiKey) `
    -BaseUrl https://mysite.files.com `
    -LocalFolder D:\exports `
    -RemoteFolder exports/nightly

$results | ConvertTo-Json -Depth 4
if (@($results | Where-Object { $_.Status -in 'Failed', 'Uncertain' }).Count) {
    exit 1
}
exit 0

Point the scheduler at the same pwsh executable you tested, with arguments such as:

-NoProfile -NonInteractive -File C:\Jobs\NightlyFilesExport.ps1

-NonInteractive makes prompts fail instead of waiting for input. Keep secrets out of those arguments. A job must also respect the organization's script execution policy. Decide confirmation choices in the reviewed script: -Confirm:$false suppresses a chosen mutation's prompt; it is not a dry run. The nightly example already uses it for its uploads and disconnect.

Bound Commands and Report Failures

Set Connect-FilesAccount -OperationTimeout (New-TimeSpan -Minutes 30) to bound each command using that connection. Network read/write timeouts detect stalls rather than limiting a whole command. The nightly example uses a two-hour operation timeout; a job with several commands also needs its scheduler's overall time limit.

Use -ErrorAction Stop or $ErrorActionPreference = 'Stop' to make command errors stop the script or reach your catch. Outcome objects also need inspection:

Outcome	Caller action
Provisioning `Failed` or `Skipped`	Record the row and decide whether the batch should fail. The provisioning example continues to later rows.
Transfer `Uploaded`	Upload completed.
`Uploaded (confirmed by checksum)`	The nightly example confirmed matching remote bytes after losing the completion answer.
Transfer `Failed` or `Uncertain`	Report an unsuccessful job; investigate before another attempt.

The nightly example exits with code 1 for failed or uncertain files. If another script invokes it, that caller must also check outcomes and propagate failure, as above. Retain structured results for monitoring; a script reaching its last line is not proof that every row or file succeeded.

Recover a Stopped Transfer

Use the checkpoint options in Send-FilesFile, Receive-FilesFile and the directory commands to continue supported stopped transfers. Keep checkpoint state private and persistent between job runs; see File Transfers. The nightly example itself does not create checkpoints.

If an upload's final answer is lost, the remote file may already be complete. The nightly example checks its checksum and reports Uncertain when it cannot establish matching bytes. It never automatically uploads that file again. Check the remote outcome before replaying a whole upload; increasing retries or rerunning the job does not resolve an unknown completion.