File transfer automation

A cron line that calls SFTP, a workflow that fires when a bucket receives an object, and an MFT job on a partner calendar are all automation. The protocol underneath is unchanged. What changed is who notices failure.

Gartner separates managed file transfer from scripts on visibility and retry. A script can be automated and still be invisible. If the only alert is a mail the mailbox rule buried, the automation ran and nobody knows the file never landed. The minimum record is the same as a manual transfer: partner, path, byte count, start, end, result. SP-style audit practice wants that row retained. The product label does not create it.

Every weeknight at 01:15 a job uploads `inventory-2026-10-06.csv`, about 400 MB, to three SFTP hosts. Host two refuses the key. A bare script exits 255, cron sends mail, and the morning shift misses it. An MFT job retries twice, marks that partner failed, completes the other two, and leaves a red row. Both were automated. Only the second is operable on a Monday. A second pattern is event-driven: an object landing in `inbound/` starts a virus scan and a forward to the ERP. The trigger is the landing, not the clock. If the scan fails closed, the forward must not run. Automation that always forwards is how a bad file reaches the partner on schedule.

Automation is not server-to-server by definition, though it often is. A watched folder on a workstation is still a person-shaped host. Do not call a shared drive "automated" because two humans happen to use it.