Access & Ownership

Access in Files.com involves several related decisions: which identity connects, which files it can use, which resources it can administer, and whose permissions an automated process uses. Keeping those decisions explicit lets a supplier upload files without granting it control over the connection or workflow that delivers them onward.

Identity And File Permissions

Authentication establishes the account or credential making a request. A successful login does not by itself grant access to every folder. Folder permissions define the permitted actions, such as listing, reading, writing, sharing, or administering a folder.

For ordinary users, direct and Group grants combine. Removing one grant does not remove access supplied by another. Partner Users instead receive their Partner's folder permissions; they do not receive separate user or Group grants. The effective-access check helps identify where access comes from.

A user's Workspace or Partner boundary also affects which paths are available. Granting access and choosing the organizational boundary are related parts of the design, as described in Sites, Workspaces & Child Sites.

Administrative Authority

Administrative roles determine who can change configuration. A Site Administrator has authority across the site. Workspace Administrators manage their assigned Workspaces. Folder and Group administration delegate narrower responsibilities.

The ability to read an invoice, change a folder's permissions, and edit the delivery workflow are separate responsibilities. Assigning a broad administrative role to solve a file-access problem also gives the user control over configuration. Start with the actual operation the person needs, then choose the corresponding permission or role.

Credentials Have Scope

A user API key draws its access from its associated account and is also restricted by its own permission and Workspace scope. A Files Only key limits use to file and folder operations. Full Access does not give a non-administrator user administrative privileges it does not already have.

Site-wide keys have no associated user and must be managed independently of the administrator who created them. Name and scope credentials for their purpose so that replacing one integration's key does not require changing unrelated connections.

A connection to a Remote Server has another authorization boundary. Files.com must permit the operation, and the account used on the remote system must have the rights needed there. For example, replacing a file through a mounted move or copy can require remote delete permission as well as write permission. The mount reference explains the operation-specific behavior.

Workflow Ownership

An Automation executes using its owner's permissions. The user who uploaded the triggering file or requested the run does not supply those execution permissions. This permits a supplier to submit to an intake folder while an internally controlled workflow delivers the file to a destination outside the supplier's access.

Ownership behavior depends on the Automation version. Automations v1 can have user ownership, and editing can change that ownership. Automations v2 uses site or Workspace ownership. V2 is an opt-in early beta and is not recommended for business-critical production workflows. Use the rules for the version you are configuring when deciding who may maintain or operate it.

Access Changes And Existing Activity

Removing access prevents new authorized operations, but does not retrieve files already downloaded or displayed. Already-issued transfer URLs can remain usable for their validity period, and an accepted transfer can continue after its URL expires.

Resources created during a user's access also have their own lifecycles. Removing folder access does not automatically revoke existing Share Links or delete email notifications. Share Link ownership and notification management therefore belong in an offboarding review alongside the account and its credentials.