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.

I’ve created several Relay workflows across the business and the issue I found is that people are reaching out to me because my name is tied to a task that is assigned to them. Often times, I do not have any context to the workflow so it results in me having to reach out to the person who started/uploaded the document. We want to avoid approvers having to reach out to the workflow owner vs. the actual owner of the program. This process would not be sustainable if it were rolled out to a larger company.

Currently Example: Hayley creates workflow in Relay > Relay is kicked off by end-user > Box assigns an approver a task. The task is assigned by the owner of the Relay workflow - “Hayley has assigned a task to Approver.”

Proposed Example: Hayley creates workflow in Relay > Relay is kicked off by end-user/uploader > Box assigns an approver a task. The task should either read - “[End-User/Uploader] has assigned a task to Approver” OR “[Alias - People Operations team] has assigned a task to Approver.”

Suppose you like to assign an approval task to a person with multiple files and when the task is rejected, you like to move the package of those “rejected” files to a different folder("Rejected folder) instead of having them sat in the triggered folder.

For a single file, you can create the following workflow containing 2 flows and it works perfect as expected, however it doesn't work for multi-files...
Flow 1: Trigger Manual start-> Outcome: Assign task -> When rejected, the flow is end
Flow 2: Trigger Task -> Outcome: when the task is rejected, move the file to “Rejected folder”
--> Only single file will be moved to Reject folder.

It would be efficient if rejected files are moved to a different folder as a clean-up process,

Create reporting for Shield activities, including the following:
1) Classifications applied by their name (i.e. 'externalpublic used on 157 folders/files'). This would help determine popular and unpopular classifications.
2) User who applied the classification label and each time they applied one (i.e. Person A applied shield classification labels on 10/1, 10/2, 10/3, etc). Helps see who is using the labels and how frequently.
3) User and which label they applied (i.e. Person B applied the externalpublic label on 10/1, 10/2, 10/3, etc.). Helps see a combo of the above two bullets.
4) Number of times a shield classification label prevented file/folder sharing (i.e. internal_only label prevented 300 files/folders from being shared externally). Doesn't have to be a deep dive into which folders, just some gauge of how effective the labels are at stopping things from being shared incorrectly.