FEATURE IDEA:
Provide ability to flag/classify files and folders in a way that allows Box to move them to a less-expensive storage offering on the back-end. This can be referred to as an "inactive" or "archive" flag.

BENEFITS & BACKGROUND

During the Box Higher Education Community Monthly Open Discussion on January 11th, an idea to submit to Box Pulse was formed, and seemed to have support from all in attendance (25-30 institutions).

Box acknowledges that there is a growing concern around constantly increasing storage, and the costs associated with it. The majority of files stored in Box are perceived (or actively reported) as being "inactive" and yet those files are costing Box and their customers the same amount. As a result, organizations are searching for alternative cost-effective solutions to move their data into. Implementing a separate solution for a subset of Box data requires significant technical, administrative, procedural, and support overhead.

Given a user or admin-driven active/inactive flag, Box could engineer their platform to use cheaper back-end storage for inactive data, and more permanent storage for active data, ultimately providing a more cost-effective service.

Administrators could be given the ability to set the parameters for what makes something an "inactive" file, and then allow end-users to tag their own content.

Allowing a view and controls around "active" vs "inactive" content, means Box could then provide X amount of "active" storage, and Y amount of "inactive" storage quota either included in the price, or for an additional fee (at better a less-expensive per TB rate). Organizations can then choose to deploy the associated quota controls and processes based on their own budget and needs for active and inactive storage.

Market opportunity -- other cloud  providers do not provide user-initiated controls for this kind of approach to data storage and management. If the providers are implementing anything like this, it is not transparent to the user. Box may have an opportunity to retain users and their data, by providing a more cost-effective glacier/cold-line/archive/inactive data storage offering, side-by-side with the rest of the Box platform.

File uploads are extremely slow. For example, a group of 3 x 20Mb files might take an entire day to upload on a 5mb.s connection. This has happened in the past 3-4 weeks.
I found the root cause of it. I am in New Zealand and redirected to the Tokyo server, which is very very slow. I verified that this upload path is an issue thus:
Tried to upload a 20Mb file using browser (via Tokyo) - 2 hrs later the file was at 20% upload. Cancelled the upload.
Connected a VPN onto Los Angeles. Uploaded the same file (and others). Uploads completed in less than a minute.
This performance issue forces me to use a VPN each time I use Box to upload which is burdensome.

Thanks for your attention on this.

Many people in my organization share folders with me. EVERY SINGLE ONE OF THEM ends up in my top-level directory. But some should be in one folder and some in another. I should be able to move any shared folder, even ones I am not a collaborator on, to ANY place in my directory structure without changing the physical storage space and without worrying about ownership. Why should the sharer have a right to clutter up my top-level directory with so many folders? It's pages and pages of stuff on the web interface. Since the real data is physically stored in a redundant, distributed file system, there is already a system that locates all the parts and copies of parts that exist to make this "folder" and all its "files." There is already a system that tracks and tags which accounts the folder has to "appear" in. It should be child's play to let that appearance be manipulated by the receiver without needing ownership. The sharer's experience and control of the data would not change if you let me put that folder in a subfolder called "Shared Items." They would literally not even know. I can't believe this is not a feature as of the moment you deployed.

I am a software developer, and I use Box so that I can access my code at work and at home. If there is a folder called Project1 with my solution files in it, the act of opening that solution or building that solution will create both a "bin" and an "obj" folder that both contain several hundred megabytes of data that does not need to be sync'ed. When I stop debugging and change the code to run it again, now I have 2 copies of nearly identical data still being pushed up to the cloud and being downloaded by my other devices.

Is there any way that I can select Project1 to be sync'ed to the cloud and my PCs but exclude certain folders like 'bin' and 'obj' that do NOT need to be sync'ed?

I realize that I can turn Box off on my PC while I am developing, but then I often forget to turn it back on for a week or so, which defeats the purpose of having my data sync'ed.

Your syncing is taking up all of my bandwidth.

I'd like to preface this by saying that this is a bug that needs to be fixed, not an idea. Even so, Box suggested we post this here to get others to chime in and say that this should be fixed.

This is a problem that's been around for at least 1.5 years.

Often, when an account's folders and files are transferred to someone else, the account from which the data was transferred still shows something greater than 0 bytes owned. This becomes a problem for deleting that user, because we can't be sure if the transfer worked, and we don't want to delete an account that has data that will be lost forever. This seems to happen, more often than not, for accounts that have a lot of owned data prior to the transfer.

At the moment the workaround is to have a script run every day to detect when this has happened, and to then create a Box ticket to have someone in Box support run their own homegrown script that rectifies the situation for the individual account. (Note, Box created this script because this is a known problem that they have to regularly fix.) So, it takes our time to detect it and create the ticket, and it takes Box's time to fix it and deal with the ticket. This happens almost every week at least one time.

After 1.5 years, it's about time to fix this readily reproducible problem!