Hi,

i discribe a situation:
The Admin is the owner of all folders/files, directors has co-owner-rights and all employees are editors. It is similarly discribed in "Folder Structure Best Practices" under "Business Unit Drive"
Now we invite some external users... not only the owner can invite them.
Then we create some relays for specific folder, especially some manual ones, assign a task and set the Assignee to "Specify at startup"...not only the owner can do this.
Last but not least we start the manual workflow and choose as Assignee an external user... but wait...ONLY the owner of the folder (1 person, here the admin) can do this.

This can't be expected behavior.

We have over 1500 external users... this is not practical.

If we have a folder with invited external users, at least all internal users who start the manual workflow should be able to include these external users.

Previously recommended workaround:
If you are an non-owner of a file/folder and want to add an external user to a manual workflow, create a separate parent folder and invite the external user.
Now you can also include these external user in manual workflows.

So to be on the safe side, 1000 internal users are now inviting 1000 external users to one of their folders so that the manual workflows can be used. The external partners will understand, there are only 1000 new folders in their box homepage.

Luckily our admin is not the owner of ALL folders, but the annoyance is big enough.
In my opinion, giving co-owners these rights as well would be the bare minimum.
Because so our employees have sick/holiday cover, but not in Box.

Regards,

Michael

In file request, have the ability to state that only a managed user in the EID or an external user that has been invited to the folder can upload, no one else. By doing this, it prevents a file request link from being randomly guessed or found on the internet AND prevents a random user from uploading bad or malware/virus infected content. The current state of requiring the user to login is too generic and doesn't meet the requirement of keeping the file request locked down. Using the collaboration role for upload is not what is needed. The File Request interface is what is needed with greater level of security on it.

Many times, there is a single automated workflow, e.g. from a file action or folder event, that actually applies across different folders in the structure.

Today, we can only select one folder for the workflow and therefore have to duplicate the workflow multiple times if we want it to work in different places. Then, if the workflows needs updating, then it has to be done in multiple places, which isn't the best place use of time.

It would be great if, in the workflow builder, if you can select more than folder for where the workflow should listen for the event, meaning you can easily scale out the workflow to different folders.

Enable ability to customize the notification that is triggered during a Box Relay workflow.

E.g. if an approval task is approved, I want to notify whoever submitted the content for approval AND potentially other relevant parties that their submission was approved, but I also want to potentially customize the notification (e.g. it was approved for x, y, and z reasons).

E.g. if an approval task is denied, I want to notify whoever submitted the content for approval AND potentially other relevant parties that their submission was denied, but I also want to potentially customize the notification (e.g. it was denied for x, y, and z reasons).

My customer would like to trigger a workflow that copies a folder (and subfolders) IN the folder where it is created.

Customer use case:

A financial services company needs to create a deal folder within the company folder a fund team is working from. Instead of going to the deal folder template to copy it into the specific company folder, they would like to trigger the workflow to copy the deal folder template to the company specific folder with one click and from the company folder.

This would be similar to using a manual trigger but having a dynamic variable available to be chosen each time the workflow is run.

When we create the workflow template to publish it company-wide from the existing workflow, the user account assigned to the task defined in the workflow are maintained in the template.

In the current specification of Box Relay, the workflow invites the task assignee if he/she doesn't have access to the contents related to the task.

Template is intended to be used by company-wide Box user, so if the task assignee is remained in the template and if the template user doesn't remove it when creating workflow from template, this original task assignee will be invited and given access.

This leads information leakage..

So we request Box to fix this. Concretely, when user creates template from existing workflow, Box should remove the original task assignee from template.