This feature would be a massive benefit for my organization and many other. Waterfall permissions are disruptive to general company file structure if we are wanting to provide a unified file map for users.

Would love to see this one come to fruition. Thanks!

We have a project folder hierarchy. In lower level there are folders that is allowed to be shared externally. But we cannot enable our users to share link and invite collaborators because the folder setting at the root folder is being inherited down the lower level. If we unchecked the collaboration setting and share links at root folder, individual sub-folders has to be edited. There is also a loophole that even you restrict the folder settings on each individual sub-folders, if a user share link of the root the whole project folders and file can be downloaded by anyone with shared links.

Our users need to contact Admins and co-admins just add collaborators and shared links.

Hey Guys,

There hasn't been a box admin comment in how long on this? This is something that really needs to be worked into your product. Why not have a choice from the creation of a folder to have it be "waterfall" or "not waterfall" bc as many previous users have demonstrated, the workarounds for this create huge inefficiencies.
Come on, Box! Get on it! Please!

I agree completely. We came from a regular Windows server environment where I could allow or deny access to files and folders at any point in the structure. That is what we need and what works best.

A current example of how the waterfall permission structure is hurting is with the new Box Drive custom location. If I add someone as a collaborator on a file down in the file structure where they have no access to the parent tree & folders, I cannot hyperlink in Outlook to files through Box Drive and have it work. I am still forced to use the URLs to bypass the waterfall structure and the work-arounds that had to be done to get permissions correct. Hyperlinks work perfect only for files/folders where all parties have the exact same file structure, i.e. permission for the entire file structure chain.

Breaking waterfall permissions could definitely be beneficial in some use cases but I agree with others that it could get really complicated, too.

I suppose I'd be happy with a folder setting that can be enabled by owners/co-owners to "Hide this folder and it's child content from External Collaborators" OR "....from non-Owners/Co-Owners."

This would effectively keep the folder structure the owner wants but everything in that branch of the tree would be invisible to external users or Editors and below, respectively. I suppose you could even allow the co-owner to select the permission levels from which to hide that part of the folder tree, i.e., instead of Editors and below, they could select the Viewer/Uploaders and below, Viewers and below, etc.

Enabling this would put a label on the folder and child content in both the web UI and Drive to indicate to the co-owner that this private setting was enabled.

You could also do this at the file level using the right-click context menu in Drive or the ellipses button in the web with a "Hide" or "Make Private" option, or via Classifications similar to setting a Confidential/Internal/Public label. It's important to have a visual label on the file indicating that it's hidden and it shouldn't be super easy to toggle on-and-off; there should at least be a message such as "Are you sure you want to disable this private setting? All of this content will now be visible to all collaborators!"

This hybrid approach still uses waterfall logic in order to hide everything in that branch of the folder tree so it wouldn't address the valid concern by Mark E regarding folder naming conventions in a Shared folder. I'm thinking that folder-level metadata with cascade could be used to apply a Client Name or Project name value to the parent folder (using Mark's example) and have that value show up in a metadata column next to all of the child folder/file names to provide the context for those similarly named shared folders. If you can ultimately take advantage of metadata attributes in Box Drive, too, then that client/project name could be shown in Drive as well.

I might read this back later and find some flaws in the approach I just offered, but hopefully there's something worthwhile in here. :-)

Just curious on the status of this? My use case is below.

Our business provides product development services. We work with external consultants, contractors and other remote workers. Plus, we collaborate with our clients.
We have a template folder structure for each client and project. .. e.g. Client Name/Project 1/ Project Phase/"various project folders".
The "Project 1" folder includes financial, legal and other information that is for internal use only along with multiple Phase folders (these Phases describe groupings of steps in the development process). The Project Phase folder houses all the Phase specific information such as reporting, engineering, client supplied info, client communications... etc.

With waterfall permissions I can't allow collaborators to have permission to see the client folder, one specific project folder, one specific Phase folder and only the folders that I want them to see under the Phase folder. Right now I have to create a SHARED folder within the Phase folder and only share that folder with collaborators. However, I must name the folder "SHARED-Client Name-Project Name-Phase" in order for the external collaborator to understand what the folder means on their BOX account. Otherwise, they would see 5 folders named "SHARED" not know which Shared folder pertains to which project.

All of that is to say that allowing specific users access to specific folders without regard to the parent folder, would be very helpful!

I understand it can get complicated to manage but managing workarounds is also very complicated too.

One suggestion to make it easier when assigning permissions would be to allow an indented visual list of folders under a user with the subsequent permission level shown next to the folder. That visual tool would make adding and adjusting permissions for a user much faster. I can also envision the same thing for reviewing permissions of a folder where the main folder is at the top and all the sub-folders (indented) are below and the users/groups and their permissions are shown next to each folder. A visual tool like this would be great!

Finally, folder templates with permission templates would be really great too. That way I can setup a template for Client and Project Folders with all the proper group permissions setup ahead of time. Then I would only need to add a few specific people instead of setting up all the permissions each time. Again, making this a visual easy to use tool would make the user experience great!

Playing with fire here. Years of user decisions in a non-waterfall environment accumulate a massive set of permissions exceptions that become a headache for everyone. If implemented, "allow breaking waterfall" should be a folder setting, with defaults managed in the Admin Console.

Effectively have box work similar to Windows NTFS and DFS permissions (source : https://docs.microsoft.com/en-us/windows-server/storage/dfs-namespaces/dfs-overview) and not enforce the current "waterfall" method of permissions as assigning viewer rights to a child folder of a shared root folder breaks the file path and directory tree within Windows Box Drive (i.e. spreadsheet linking).

We just subscribed to box for our business but we didn't realize that these permissions were set up as waterfall. This really makes box in efficient for us because we have to have separate out folders that really should be together in order to effectively give permissions. This does not make sense for our business. . If this cannot get fixed we will have to switch to another service that can provide it.

Our waterfall of permissions and restrictions could be interrupted down the line because the user can have sub-items which specify different permissions/restrictions if the user moved to the folder.
Please restrict or change permission to parent folder one's

Please Box team, consider moving forward with the implementation of this feature post haste! It's 2019 and inheritance of permissions should not be enforced. It is a detriment to project organization in my industry and the only solution at this time that isn't a hack seems to be meeting the issue with greater disorganization (partitioning files in such a way that they end up in separate folders).

Although there are inelegant workarounds, hacks really, it is imperative in many common use cases to be able to change the inherited permission of a folder. Not having this ability in an enterprise-level product like Box is unforgivable.

Any updates on this request, looks like its from 2016, and is of critical importance for many users.

I respect that you've developed Box as it is, but we're drowning in the waterfall. Perhaps rather than undoing all you've done, for in some cases it may well be useful this way, perhaps adding a "compatibility mode" option that would allow more restrictive (server-like) permissions to be used where needed would be the best. Folders running in this new mode could be indicated by another color, so that people could easily distinguish between native Box and compatible-mode folders. This way your system could go to the Box rule set for permissions if in Box mode, a separate set of rules for the compatibility mode. This may be easier than trying to jury rig additional features into your existing structure. We WILL appreciate this functionality, believe me and a whole lot of other admins! Thanks for your consideration.

I would like to give someone access to a parent folder and then remove them from a few specific ones.

Grant access to a folder but restrict subfolder access

The ability to have collaboration permissions at single folder levels (instead of waterfall) to allow for more secure and easier sharing, especially externally.

By allowing permissions to be controlled for a single folder, risk of accidental collaboration invites can be lessened (either with wrong departments or external individuals).