Skip to main content

Solution Design

A Files.com deployment connects a business requirement to people, accounts, storage, transfers, and operating responsibilities. Start with the result you need, then choose the resources that support it. The same platform can support staff collaborating on documents, suppliers exchanging files, and systems moving data unattended, including combinations of all three.

Describe the Work

For each exchange, identify who supplies the files, who uses them, where they live, what changes along the way, and when the result is needed. Include the human steps. A finance team approving invoices is part of the workflow even if software performs every transfer around it.

Describe success in terms the receiving team can verify. “The daily report reaches the application and is accepted before the morning processing window” is more useful than “Set up an SFTP connection.” The connection is one choice within that requirement.

Record the consequences of a missing, late, duplicate, or incorrect delivery. Those consequences determine how much isolation, validation, monitoring, and recovery the design needs.

Choose the Boundaries

Account Structure & Environments covers where resources belong. Users, groups, and folder permissions can serve shared file access in the Default Workspace. Additional Workspaces group resources and flows by task, functional area, project, or team. Child Sites provide separate site settings when environments need different authentication, security policies, addresses, or branding.

These are choices you can combine. A Procurement Workspace can contain several supplier Partners and the Remote Servers and Automations that serve them. One IT team can manage that Workspace along with payroll and reporting Workspaces. Creating separate administrative teams is not a prerequisite.

Choose storage independently from the people using it. Native storage can hold a working copy. A mount can expose files on an existing server to staff and workflows. A Sync creates another copy with its own timing and retention implications. Files, Storage & Mounts explains those distinctions.

Work Through a Complete Example

The following examples start from different jobs rather than assigning technologies to a particular audience:

RequirementDesign example
A team needs shared working documents and controlled distributionTeam Collaboration
External organizations need recurring exchanges for people and systemsPartner File Exchange
Applications need scheduled delivery with operational accountabilityManaged File Transfer

An organization may need all three. The examples explain consequential choices and what to test; their folder names and resource groupings are examples, not required platform conventions.

Assign Access and Responsibility

Separate access to files from authority to configure the workflow. Identify the people who work with the data, the accounts used by applications, the administrators who maintain resources, and the team that responds to failures.

External organizations can use Partners to manage their people and machine accounts within a common access boundary. An occasional visitor may need only a Share Link or Inbox. The recipient's job determines the access method; an existing Remote Server or Agent connection can supply the files for either approach.

Prove One Flow Before Expanding

Build a representative flow with test data and test destinations. Verify ordinary-user access, the required file operations, run results, and the receiving system's acknowledgment. Exercise a likely failure and a repeated delivery before applying the pattern more broadly.

Production Validation & Change Control covers configuration authority, environment-specific settings, a controlled first delivery, and recovery. Use it when launching a new deployment or replacing an existing transfer system. Keep the resource reference nearby for exact configuration steps and supported behavior.