An Automation trigger defines when an Automation runs. After selecting an Automation type like Copy Files, Move Files, Import Files, or Run Sync, you choose a trigger that determines how the Automation starts.

Triggers let organizations automate managed file transfer workflows on a schedule, respond to real-time file activity, support manual operations, and integrate with external systems. Files.com supports both scheduled and event-based triggers.

Scheduled Triggers

Scheduled triggers run Automations at specific times without requiring user action or file system events. Organizations use scheduled triggers to automate recurring file movement, system integrations, archival processes, and retention-based cleanup. Scheduled triggers give you control over execution timing, including time of day, time zones, and holiday calendars.

Interval-Based Triggers

Interval triggers run Automations daily, weekly, monthly, quarterly, or yearly. Interval-based Automations also accept one or more times of day and a time zone. Without them, the Automation runs at midnight UTC. For example, a Move Files Automation can run on day 2 of every month at 6:30 PM Pacific Time.

A daily schedule needs no day, because it already runs every day. The others need at least one, and allow several. A semi-monthly payroll or invoicing job is one Automation on days 1 and 15 rather than one Automation per date.

Day numbers count from the start of the interval, so the same number means different things:

Weekly days run 1 through 7, where day 1 is Sunday and day 7 is Saturday.
Monthly days are calendar dates, 1 through 31.
Quarterly days count from the first day of the quarter, so day 1 is January 1, April 1, July 1, and October 1.
Yearly days count from January 1 through day 365, or 366 for a leap year.

A day that a period does not contain is skipped rather than moved to the nearest real date. A monthly Automation on day 31 does not run in February, April, June, September, or November, and a yearly Automation on day 366 runs only in leap years. If the Automation exists to deliver a file before the month closes, day 31 misses five months a year. Schedule the run at the end of the period instead.

An interval can instead run at the end of the period. No day numbers are needed and it runs once, on the last day. An end-of-month Automation runs on the 28th, 29th, 30th, or 31st, whichever the month has.

Interval schedules support both individual times and time ranges. When you define a time range, the Automation runs once per hour during that window. This helps you schedule recurring Automations during off-peak hours and control execution windows for connected systems. Times apply to every day in the schedule, so three days and two times of day produce six runs per interval.

Custom Scheduled Triggers

Custom scheduled triggers run an Automation on specific days of the week, at exact times of day, with more than one run allowed in the same day. Custom schedules run based on the selected time zone. An interval schedule can do the same weekdays and times, and also days inside a month, quarter, or year, so a custom schedule is the narrower of the two.

Custom schedules support workflows that align with business hours or operational shifts. For example, an Import Files Automation can run every weekday at 06:00 UTC and again at 15:00 UTC, or a sync task can run after each production shift completes.

Custom schedules also support time ranges. Instead of defining multiple individual start times, you can define a continuous execution window. For example, instead of specifying individual start times at 01:00, 02:00, 03:00, 04:00, and 05:00 UTC, you can define a single time range of 01:00 through 05:00 UTC. The Automation then runs once per hour during that window.

Running Automations within defined time ranges helps protect connected systems during peak usage periods. When a workflow interacts with a remote server that experiences heavy traffic during business hours, scheduling execution during lower usage windows reduces contention and avoids impacting active users.

A custom schedule belongs to the one Automation that defines it. When the same days and times govern other Automations or syncs as well, a Saved Schedule holds that timing once for all of them.

Time Zones and Holidays

All scheduled Automations run based on the selected time zone so execution aligns with local operational expectations.

A Holiday Region prevents Automations from running on the days it covers. The Automation skips scheduled runs on those days, which avoids unintended file processing or delivery when teams are unavailable.

The Holiday Region setting takes either a built-in region or a Holiday Calendar your Site Administrators define. Files.com's built-in regions carry the public holidays of a country or territory. A Holiday Calendar covers anything they do not, including dates that move each year, weekend observation, partial-day closures, and restrictions to specific years.

File action, webhook, and manual triggers do not accept a Holiday Region, because they have no scheduled run to skip.

Saved Schedule Triggers

A Saved Schedule trigger points the Automation at a Schedule, a named set of days, times, time zone, and Holiday Region defined once on your site and shared by everything using it. The Schedule supplies the timing in place of the Automation's own.

Use a Saved Schedule when the same timing already appears on other Automations, syncs, or scheduled work, and you want one edit to move all of them together. Use a Custom Schedule when the timing belongs to this Automation alone.

File Action-Based Triggers

File-action-based triggers start Automations when specific file events occur inside Files.com folders. These events include file uploads, renames, modifications, and deletions. File-action-based triggers support real-time workflows like moving newly uploaded files into processing folders, renaming files on arrival, and copying new files to secondary locations.

When using a file-action-based trigger, the Automation runs only on the file involved in the triggering event. For example, if the trigger is set to run when a file is created, the Automation processes only that newly created file and does not act on other files already in the folder.

This type of trigger is effective for workflows that involve file uploads via Share Links, Inboxes, or APIs. As soon as the file appears in a monitored folder, the Automation executes without delay. Activity in remote-mounted folders fires these triggers when the mount's Remote Metadata Index is enabled, which records remote-side changes as actions on the next scheduled scan, or when files are first synced into Files.com.

File Action-Based Triggers and Child Sites

Automations within a parent site can interact with folders in child sites, and the Automation and all its run logs exist only within the parent site. This isolation of Automations within their sites affects how file action-based triggers can be used.

Only actions recorded within the Automation's site can trigger an Automation. Parent site Automations triggered by file activity within a child site's folder fire only when the activity occurs through the parent site. The parent site Automation does not fire on file activity carried out directly in the child site.

Automations in child sites cannot interact with parent sites or any other child sites. A child site Automation with a file-action trigger does not start when file activity occurs within a parent site process or session, even if that file activity is changing the contents of the child site.

Inbound Webhook Triggers

Webhook triggers let external systems activate Automations by sending an HTTP request to a unique URL generated by Files.com. Both GET and POST methods are supported, and the contents of the request body are ignored. The trigger integrates easily with CRMs, ERPs, SaaS platforms, and automation tools that can send outbound webhooks.

For example, a webhook can trigger a file import as soon as a third-party application completes an export process. Webhook URLs can trigger automated activity on your site, so treat them as confidential and secure them accordingly.

Manual Execution with Run Now

Manual execution lets you run Automations on demand. Automations configured with the Ad Hoc (Run Manually) trigger run only when you select Run Now and never run automatically.

Run Now from the Automation Details starts an enabled Automation immediately. Use it to test and validate an Automation after configuration, or to execute on-demand workflows like one-time imports or file cleanup without waiting for a schedule or event. Run Now is available only for enabled Automations.

Run Now works with Automations that use non-file-action-based triggers. It is not available for File-Action-Based Triggers because those Automations run only in response to real-time file events.

Triggering Automations on Remote Servers

To react to changes made on a remote system, enable the Remote Metadata Index on the Remote Server Mount. Files.com scans the mount on the indexing interval you set and records new and removed files as actions, and File Action-based triggers fire on those actions. A file created on the remote system triggers its Automation after the next scheduled scan records it, so the reaction follows the indexing interval rather than the moment the file lands.

When your workflow needs the files copied into Files.com, or needs to react faster than the indexing interval, use Sync or a Run Sync Automation to pull files from the remote server into Files.com on a defined schedule. Once files arrive in a Files.com folder, you can trigger additional Automations like Move Files or Copy Files using any trigger type. For example, a partner may upload invoices to a remote SFTP location. Files.com syncs those files every ten minutes, and once received locally, a Move Files Automation routes them to the appropriate processing folder.

Controlling Run Order with Serialize Jobs

Automations triggered by file actions or webhooks run as soon as the event occurs. By default, multiple Automation runs triggered close together may run at the same time. This parallel execution improves performance but can cause issues when working with remote mounts or shared destinations.

To avoid conflicts, enable the Always Serialize Jobs setting, which is available only for Automations that are not triggered by a schedule. You will see this option when configuring file-triggered or webhook-triggered Copy Files, Move Files, Delete Files, Import Files, and Run Sync Automations where a destination is involved. This setting causes Automation runs to execute one at a time in the order they are triggered. It helps prevent race conditions, overlapping writes, and inconsistent file states, especially when Automations interact with remote storage locations that do not support simultaneous access.

Automation Triggers