Files, Storage & Mounts
Files.com gives files a common place in your workflows even when their contents live in different storage systems. A folder can hold native Files.com storage or provide access to a connected server or cloud service. The path tells people and applications where to work; the storage behind that path determines where the contents reside and which operations are available.
This distinction matters when a team wants to collaborate on existing files, deliver files to another system, or keep an independent copy. Those are different uses of storage, and they do not all require a transfer into Files.com.
The File Tree
Files and folders are addressed by paths such as Invoices/Received/invoice.csv. The web interface, client apps, APIs, and supported protocols provide access to the file tree within the connecting account's permissions and organizational scope. A Workspace user or Partner User may see a restricted part of that tree as their root.
Folder permissions govern access. File System Semantics defines the rules for paths, names, and operations. A permissions display in an SFTP client does not replace the Files.com permission model, and a file's appearance in a folder does not establish that its contents are stored natively.
Native Storage And Mounted Storage
Native storage holds file contents on Files.com. Your organization can choose storage regions for the site or particular folders and configure retention and recovery within the platform.
A Remote Server defines a connection to another system. A Remote Server Mount attaches a location on that system to a Files.com folder. Reading, uploading, renaming, or deleting through the mounted folder acts on the remote location, subject to the connection and the remote system's rules.
For example, an accounting server's invoice directory can appear as a mounted folder. A finance user can access those invoices through Files.com, and an Automation can deliver additional invoices through the same mount. The remote directory remains the storage location in both cases.
Mounting does not create an independent working copy. Deleting a file through a mount can delete the remote file. Recovery then depends on the remote system's recovery capabilities. Native-storage retention is not a backup of the mounted directory.
Copies And Replication
A transfer copies or moves files between locations. A Sync maintains a one-way replicated copy according to its schedule, selection rules, and source-deletion settings. Until another run transfers a change, the destination can differ from the source.
| Requirement | Storage Arrangement |
|---|---|
| People need to work on files already held on another server | Mount the remote location and grant appropriate access. |
| A business system needs its own recurring copy | Use a Sync or an Automation to deliver files into that system. |
| Staff need to review files before onward delivery | Receive them into a controlled location, then transfer the selected files when they are ready. |
| Recovery must survive an unwanted change to the working files | Preserve earlier copies through a verified retention or backup policy. |
A replicated copy and a backup can serve different purposes. Replacing a destination with the latest file does not by itself retain earlier versions. Backup planning determines which recovery points survive later changes.
Remote Storage In A Workflow
Remote systems have their own naming rules, permissions, metadata, and supported operations. A mount provides a shared access path, while the Remote Server reference describes the behavior of the selected connector. Your design needs to account for other applications that also modify files directly on the remote system.
Upload completion can also have more than one meaning. With Buffered Uploads, Files.com can finish receiving a file before forwarding it to the remote destination. The temporary staging copy supports delivery; it is not an independent folder your users can browse or a retained backup. A workflow that depends on the remote file being available must check onward delivery, as described in Activity, Delivery & Recovery.