Folder Permissions and Shared Access

Folder permissions define what an account can do with files. They also determine who may establish shared access or configure workflows over those files. An access review therefore needs to distinguish the person's current permissions from the resources created using those permissions.

Effective Access

For ordinary users, direct grants and group grants add together. Removing one grant does not remove access that another grant still supplies. Recursive permissions extend to subfolders; permissions limited to one folder do not. The Check Access feature shows the effective access for a user, group, or Partner at a particular folder, including where that access comes from.

Use groups to maintain a shared set of permissions for a team. Review membership as part of the permission decision: adding someone to a group gives them the access already assigned to it. A Group Admin who can manage membership can make that decision without editing the folder's permission list.

Partner Users follow their Partner's permissions and Root Folder instead. Site Administrators and Workspace Administrators retain the authority of their administrative roles; ordinary folder grants do not restrict those roles.

What Each Level Permits

Read permission includes downloading. List/Preview permits viewing supported content without ordinary download access, but a person can still capture or copy what a preview displays. List permission exposes names and metadata without file contents. Choose these permissions based on what the recipient may learn, as well as which buttons they should use.

Write permission supports delivery of new files. Full permission also permits general replacement, moves, renames, and deletion. Write and Read/Write include limited upload replacement allowances so clients can complete or resume uploads without receiving general Full permission. A workflow that requires an immutable submitted record should move completed submissions into an appropriately controlled location rather than assume Write means a path can never be written again.

Share permission lets someone establish a separate route for recipients to access content. Folder Admin adds administration over permissions, folder settings, notifications, and v1 Automations. These powers go beyond reading or writing the folder: they can change how other people receive its files or information about its activity.

Inheritance and Permission Fences

Files.com uses additive permissions rather than negative grants. A Permission Fence stops permissions inherited from above a folder, allowing new grants inside that subtree. Fences are intended for migrations from systems with deny rules; a straightforward folder and group design is easier to maintain for new deployments.

A fence also excludes that subtree from a parent folder's Share Link or Public Hosting configuration. It does not restrict Site Administrators, remove Folder Admin authority, or stop a permitted deletion of the parent folder from deleting the subtree with it. Notifications configured above the fence can still report activity below it when they are recursive. A fence is an inheritance control, not a separate administrative, retention, or notification boundary.

Granting a broader permission can replace redundant narrower grants. Removing that broader permission later does not restore the grants it replaced. Review the resulting permissions rather than treating removal as an automatic return to the earlier configuration.

Shared Resources After Permission Changes

A Share Link has its own access rules and lifetime. Removing its creator's folder permission does not revoke it; a live link continues to expose the included paths as their contents change. This lets a business's external sharing continue when a staff member changes roles. Revoke the link separately when the intended outcome is to end recipient access.

Email notifications can also continue after a user's folder access is removed. Administrators can deliberately send activity notices to someone responsible for a process without granting that person file access. To end those notices, delete the notification or have the recipient unsubscribe. A permission review should include who receives activity information, not only who can open files.

Automations have their own ownership and execution permissions. A change to a user-owned v1 workflow's owner can affect its ability to run; site-owned and Workspace-owned workflows have a different lifecycle. Do not infer a workflow's access solely from the person who starts it.

Content Already Opened or Delivered

Removing a user's editing permission prevents further saves under that user's identity, even if the editor stays open. In a co-authoring session, the combined document is saved using the first participant's identity, so removing a different participant's access does not stop saves while that first participant remains authorized.

Previously loaded previews, editor contents, and downloaded copies may remain with the person who received them. Temporary download URLs also have their own expiration. Permission changes govern further authorized use of Files.com; they do not erase information already delivered.