Deployment Planning

Start with the tasks your deployment needs to perform, the people and systems involved, the resources that belong together, and any settings that must differ between environments. Those decisions determine where to create users, folders, connections, and workflows.

Every Files.com site starts with a Default Workspace. If people mainly need access to shared folders, begin there with users, groups, and folder permissions. Additional Workspaces organize related resources by task, functional area, project, or team, and can also provide delegated administration. Child Sites provide separate site-wide settings.

These choices can work together. A production Child Site might contain a Procurement Workspace, which manages several supplier Partners. A team sharing internal documents might need only folders and group permissions. User count alone does not determine the structure.

Shared File Access

For people who need to upload, download, or collaborate on files, start with folders organized around the work they perform. Give each person an individual account, use groups for people with the same access, and assign permissions to those groups. A finance team, for example, can use a Finance group with access to its working folders without creating a Finance Workspace.

Folders and group permissions are sufficient when shared file access is the main requirement. If a team lead only needs to maintain group membership or administer a folder, Group Admins or Folder Admins can provide that narrower delegation.

Create the first users, add them to groups, and assign folder permissions. Test access with an ordinary user account before inviting the rest of the team. A Site Administrator's access does not show what that user will be able to see or change.

Tasks, Functional Areas, and Teams

Use a Workspace to keep a related set of users, groups, folders, Partners, Remote Servers, and automated workflows together. A single IT team can manage several Workspaces, each organized around a task, functional area, or project. Administration can also be delegated to Workspace Administrators while Site Administrators retain control of the whole site.

Choose the boundary around resources and flows that belong together. An IT team might use separate Workspaces for payroll transfers, supplier EDI, and reporting, with each Workspace containing the Remote Servers, folders, Syncs, and Automations for that function. Keeping these resources together makes each function easier to understand, operate, and change, even when the same administrators manage all three.

A Workspace can hold one flow and its supporting resources or several related flows. Use the scope of the task, the relationships among its resources, and its access and lifecycle requirements to choose the grouping. Separate administrative ownership is another reason to create a Workspace, but it is not a prerequisite.

Workspaces share the site's authentication, security policy, domains, IP addresses, and branding. They do not give a team its own version of those settings. If those settings need to differ, use a Child Site.

Decide where users belong before creating them. Users created in a Custom Workspace are scoped to it. For employees who need access to several Workspaces, Site Administrators can grant cross-workspace access to users or groups from the Default Workspace. Grant access to the required folders, or Workspace Administrator access when the person needs to administer the whole Workspace.

Write down the Workspace's purpose, administrator, membership, and naming convention, then create it before adding its resources. A new Workspace starts empty; creating it does not reorganize users, connections, or workflows that already exist elsewhere.

Automated Transfers and MFT Migration

When replacing an MFT platform or building a set of automated transfers, map the flows before configuring them. Capture the following for each flow:

• Source and destination systems, folders, and connection methods.
• External organizations involved and the internal team responsible for delivery.
• Expected filenames, volumes, timing, and downstream processing.
• Credentials, permissions, and production and test endpoints.
• Success criteria, failure handling, and who responds when a delivery is late or incomplete.

Use that inventory to choose environments and Workspace groupings before building connections. Group related Remote Servers, folders, Syncs, and Automations around the task or functional area they serve. Several related flows can share a Workspace, or a single flow can have its own Workspace with its supporting resources. The same IT team can administer all of these Workspaces.

Production and Test Environments

For an MFT deployment with a development, test, or acceptance process, use Child Sites when testing must include independent site settings. Each Child Site has its own authentication configuration, security settings, domains, IP addresses, and branding. Production and non-production sites can each contain Workspaces organized around their tasks, functional areas, or teams.

Child Sites require a qualifying plan and have a plan-specific capacity limit. They also introduce separate configuration to maintain. Parent Site Administrators retain access to them, so the boundary does not exclude those administrators. Create the Child Sites and assign their administrators before configuring environment-specific resources.

A test Workspace is enough for an experiment confined to Workspace resources, such as a folder layout or a new Automation. It shares site settings with production, so it cannot provide an independent test of changes to SSO or site security policy.

In either structure, use test data, separate credentials, and test destinations in connected systems. A Remote Server connection in a test Workspace or Child Site can still point at a production server. Check the actual host, account, and folder before running a transfer; the environment's name does not change its destination.

The First Working Flow

Build one representative flow in the chosen test environment. Connect its systems, verify access, and transfer a sample file before adding scheduled or event-driven behavior. Use separate machine accounts for scripts and integrations, with permissions for the folders and protocols they require.

Choose a Sync for one-way folder replication, or an Automation for triggered actions, renaming, or multiple destinations. Syncs vs. Automations covers the transfer tradeoffs. Automations v2 is an opt-in early beta and is not recommended for business-critical production workflows; review its beta access guidance before including it in a deployment.

Confirm both the delivered file and the run logs. Test a likely failure and a repeated delivery so that retries, overwrites, and source deletion have the intended result. Use Expectations to detect missing or invalid deliveries and Event Channels to route operational outcomes to the people or systems that need them.

Production Handoff

Record the tested configuration and name the person or team responsible for approving changes, maintaining credentials, and responding to failures. Keep operational ownership distinct from an Automation's runtime ownership, which determines the permissions it uses.

Before enabling the production flow, review its site and Workspace, hostnames, folder paths, credentials, trigger, overwrite and deletion behavior, and notification destinations. Recreate or apply the tested design with the production values, then verify a controlled first delivery. Decide how to stop the new flow and restore the previous process if the result is wrong. During an MFT migration, coordinate the cutover so the old and new systems do not both process the same delivery unintentionally.

For configurations managed as code, Terraform can make changes repeatable and reviewable. Keep production and test configuration and state separate, and review the production plan before applying it. Use the same management method consistently for each resource; see Terraform Best Practices.

External Organizations

Use a Partner for an external organization whose people or systems need accounts to exchange files with you. Create it in the Workspace of the team responsible for the relationship. Partners work in the Default Workspace too; external collaboration alone does not require another Workspace or a Child Site.

A Partner has a root folder and permissions shared by all its users. Those users cannot access paths outside that root or receive individual folder permissions. A Partner Admin can manage the organization's users and credentials within the limits your administrators allow. This gives a supplier one relationship to manage even as its contacts change.

Plan the root folder, the direction of each exchange, and the internal owner before onboarding users. Set up the Partner, add Partner Channels for sending or receiving files, and verify access as a Partner User. If an external system needs access across many Partners' folders, use the regular-user exception with the required folder permissions.

For a one-off exchange that does not need user accounts, Share Links and Inboxes may be sufficient.

Evaluation and Cleanup

A temporary Workspace can help evaluate an integration or try a design, but it is optional. Give it an owner and decide which test data and configuration need to be retained. Once the experiment ends, disable its scheduled work, preserve anything needed for the deployment, and review the Workspace deletion process before removing it. Child Sites have a separate, support-assisted removal process.