Permission Fences

Permission fences stop permission inheritance at a folder boundary. They prevent parent folder permissions from applying to a subfolder tree.

Permission fences are a migration tool. Use them when your legacy system used negative ACLs (deny rules - Negative Permissions). Because Files.com uses an allow-only permissions model and does not support negative permissions, migrating from a system that relied on the ability to explicitly assign denied permissions requires some thought. You can either re-design your permission structure in your new Files.com site, or you can use permission fences in place of your previous deny rules. Permission fences stop an "allow" rule from propagating, which has the same effect as the original "deny" rule.

Avoid permission fences if you are not migrating from a legacy “deny” model. They increase the cognitive load required to reason about access.

Permission fences can only be created and managed by site administrators and folder administrators because they impact who has access to files and folders.

How Permission Fences Work

A permission fence is defined for a folder to block inherited permissions from parent folders. You can apply new permissions inside the fenced folder. Those permissions can be recursive within the fenced subtree.

Permission fences can also be set up within other permission fences. A nested permission fence blocks all inherited permissions from its parent folders, just like an un-nested permission fence.

A permission fence cannot be applied to the root folder of your site because there are no inherited permissions to block.

Permission Fences Increase Complexity

When a site does not use permission fences, folder access is easy to reason about. Permissions are additive. A user can access a folder only if they have been granted access to it, either directly or through group or partner membership.

Permission fences change that model. A fence can block inherited permissions at a boundary, even when a permission is granted higher in the tree. At that point, answering “who can see this?” requires you to check both the grants and the inheritance boundaries.

This has practical downstream effects. Most important: it becomes harder to answer "who can see this file?" quickly and confidently. Interpreting permission reports that list out all of the assigned permissions for users becomes less intuitive because inherited grants are conditionally blocked. Auditing becomes harder because reviewers must account for both grants and fences, and explaining access to external auditors requires a more detailed mental model.

Avoid Using Permission Fences

Do not use a permission fence as a general best practice. They are intended only to assist customers migrating from a legacy system that used negative permissions, and only when it's not possible to change the folder structure or permission model.

Avoid permission fences when:

• You are designing a new folder structure. Put permissions at the right folder level instead, so that you don't need to rely upon permission fences.
• You want to restrict site administrators. Permission fences do not block administrators.

When to Use Permission Fences

Use a permission fence when you must break inheritance at a folder boundary because you are migrating from a legacy system that used negative ACLs, and a parent folder grants a broad allow but a subfolder must not inherit that access.

When all of those conditions are met, the usual pattern is to first place a permission fence at the subfolder boundary and then re-grant the specific permissions needed inside the fence.

What Permission Fences Do Not Affect

Permission fences do not affect Site Administrators. They also do not remove admin-level folder permissions from Folder administrators.

Permission fences do not affect notification settings, so notification features configured for parent folders include activity details from inside the fenced folder, unless recursion is disabled for the notification. Email notifications can be configured for users without folder permissions because people may be responsible for monitoring a workflow without being authorized to interact with the files that are being transferred. To prevent child folder activity from triggering a notification feature, disable recursion on that notification's setting.

Example: Replacing a Legacy "Deny" Rule

Imagine a legacy folder structure of Company/Team A/Manager Only/. Team members are in a Files.com group named "Team A".

The whole "Team A" group needs access to Company/Team A/, but Company/Team A/Manager Only/ should be accessible only by the manager.

If your legacy system used a "deny" rule at Company/Team A/Manager Only/, preserve it like this:

1. Apply a permission fence to Company/Team A/Manager Only/. This stops the inherited "Team A" group permission.
2. Grant access within Company/Team A/Manager Only/ to only the manager.

Operational Guidance

If you use permission fences during a migration, keep them rare and intentional. Document why each fence exists. Plan to remove fences after you have reshaped the folder tree or permission design to fit the allow-only model.

Creating a Permission Fence

Permission fences are defined on a folder. They prevent permissions from parent folders from being inherited.

After the fence has been created, new permissions can be applied within this fenced folder.

Removing a Permission Fence

Permission fences can be removed from a folder by folder admins or Site Administrators.

Removing a permission fence does not remove permissions inside the fence. It only re-enables inheritance from parent folders.