Workflow Identity, Triggers & Scheduling

A workflow needs authority to act and a reason to start. Its maintainer, execution permissions, Remote Server credentials, and trigger can all be different. Understanding those differences prevents a working transfer from breaking when a person leaves, a credential changes, or a schedule is reused.

Separate the Identities

The maintainer edits the configuration. The workflow's execution permissions determine which Files.com resources it can use. A Remote Server connection then supplies credentials for the external system, whose own permissions govern operations there.

For example, a finance administrator might maintain a transfer whose remote SFTP account can write into a bank's upload directory. Administrator access in Files.com does not grant that remote account permission to replace or delete files. Test every operation the workflow performs, including overwrites and cleanup.

Automations v1 ownership can change when someone edits an Automation. An edit by a Folder Admin transfers ownership to that user; an edit by a Site Administrator gives it site-level ownership. Even a rename or enable/disable change counts. A user-owned Automation can fail after that user's access changes.

Automations v2 ownership instead belongs to the site or a Workspace. That distinction applies to the v2 early beta; it must not be used to predict v1 behavior. V2 is not recommended for business-critical production workflows.

For Syncs, check who may create and manage the Sync and the permissions on each Remote Server. Do not apply Automation ownership rules to every feature that transfers files.

Choose What Starts the Work

A file-activity trigger responds to a matching action. A schedule selects a time to begin. An incoming webhook lets an external system request work. Choose the trigger from the point at which the input is ready, using the supported triggers for your Automation version.

If a supplier writes a large file gradually, its presence alone is not a business-level declaration that the delivery is complete. Agree on a handoff, such as moving a finished export from a working directory to a pickup directory. Also check whether changes made directly on remote storage are visible through the connection and its configured event/indexing behavior.

Avoid making the output eligible for the same trigger that processed the input. Separate input and output folders or use selection rules that prevent repeated processing.

Design the Timing

Sync triggers distinguish automatic intervals, calendar intervals, custom schedules, and external starts. Scheduled times of day define start windows, not exact-second appointments. A Sync already running causes another scheduled start for that same Sync to be skipped.

Set a time zone deliberately. Work backward from the delivery deadline to allow for source preparation, the start window, transfer duration, processing, and recovery. A job that starts at the deadline cannot also guarantee that its output is ready then.

A saved Schedule shares days and times among several resources. It belongs to the site and can be used across Workspaces. Editing it changes the timing for every resource using it, so identify those dependents before moving a shared processing window.

Holiday Calendars exclude scheduled runs on your organization's closed days or partial-day windows. They do not suppress file-activity, incoming-webhook, or manual triggers. If files must wait until the next operating day, use a schedule that observes the calendar and leave the files available for that run.

Plan Credential and Ownership Changes

Keep an inventory of the accounts, keys, connections, and administrators the workflow depends on. Protect credentials using the controls documented for the consuming feature. Creating a Secret does not by itself connect it to an Automation or replace a Remote Server's credentials. External scripts also need a secure place to store their credentials.

After changing ownership, permissions, credentials, or shared timing, test with the actual execution identity and inspect the result. Include those dependencies in the production change procedure.