<improvement>
Improve zoom/enlargement in 3D file preview function

With the current 3D file preview function of Box, the display of the 3D model is small, and there is a limit to the distance that can be brought close to the 3D model even when zooming, so I would like to improve.

<Use case>
- BIM/CIM-based 3D CAD data can be easily displayed on a browser, which can be expected to improve communication with relevant parties and productivity.
- The viewer of a CAD maker has high performance and high affinity with CAD data, but it has a large burden such as device specifications, software installation labor, and subscription maintenance costs.
- Even if you do not require the functions of the viewer of the CAD maker, if you can refer to a certain 3D model with a general-purpose browser, the data expansion will be easy.

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.”

Please support xdw, xbd and xct files in Box for iOS.

Box for iOS can preview files supported by Box, such as PDF.
However, Box for iOS can not preview xdw, xbd and xct files (*1) for the following reasons.

DocuWorks Viewer Light (iOS) (*2) implements Quick Look Preview Extension.
Thus, an app can preview xdw, xbd and xct files if the app implements QLPreviewController.
Although Box for iOS has already implemented QLPreviewController, previewing xdw, xbd and xct files are not supported by Box.

*1)
a) DocuWorks Document
extension : xdw
MIME type : application/vnd.fujixerox.docuworks
b) DocuWorks Binder
extension : xbd
MIME type : application/vnd.fujixerox.docuworks.binder
c) DocuWorks Container
extension : xct
MIME type : application/vnd.fujixerox.docuworks.container

*2)
Fuji Xerox, DocuWorks Viewer Light (iOS)
https://apps.apple.com/jp/app/docuworks-viewer-light/id412415307

Japanese translation（日本語訳）

タイトル：iOS版Boxでのファイルプレビュー（xdw, xbd, xct）

iOS版Boxでxdw, xbd, xctファイルをサポートしてほしい。

iOS版Boxは、PDFのようなサポートされたファイルをプレビューできる。
しかし下記理由により、iOS版Boxはxdw, xbd, xct (*1)ファイルをプレビューできない。

DocuWorks Viewer Light (iOS) (*2) は「Quick Look Preview Extension」を実装している。
そうすることで、アプリ側で「QLPreviewController」を実装していれば、xdw, xbd, xctファイルをプレビューできるようになる。
iOS版Boxは「QLPreviewController」を実装済みではあるが、xdw, xbd and xctファイルのプレビューはサポートされていない。

*1)
　a) DocuWorks 文書
　 拡張子 : xdw
　 MIME タイプ : application/vnd.fujixerox.docuworks
　b) DocuWorks バインダー
　 拡張子 : xbd
　 MIME タイプ : application/vnd.fujixerox.docuworks.binder
　c) DocuWorks 入れ物
　 拡張子 : xct
　 MIME タイプ : application/vnd.fujixerox.docuworks.container

*2)
　Fuji Xerox, DocuWorks Viewer Light (iOS)
　https://apps.apple.com/jp/app/docuworks-viewer-light/id412415307

======================================================

For our use case it is important to trigger a workflow based on metadata availability. E.g. when a string metadata contains a list of values (think about a list of violated policies a document was validated against) and for a specific value in that list a workflow should be started (think about that a financial policy violation is listed the financial remediation workflow has to be started).
Right now only "equals" or "starts with" are supported metadata matching options but "contains" is missing.
Using multi value string fields is no option right now as those are not supported in search which is another important use case from our side that the metadata values are searchable.

We’ve been using Box Drive since launch, and it’s been an incredible improvement in our workflow. Only a small issue has made it notably less useful in saving time, and is a known issue documented here (community.box.com/t5/Box-Drive-Known-Issues..)

Our file name and directory lengths are wider than the default for Box Drive/Windows. Normally Windows remembers preferences around column width, but in this case, as you know, Box Drive does not. This causes us to have to manually resize the “Name” field in every folder/directory, every time we access one. Therefore each user is having to do this perhaps dozens of times a day--- a lot of unnecessary time wasted.

Of course, Box Drive solves so many problems in our workflow that this is a relatively small nuisance--- but possibly one of the most important issues outstanding to us for future development with the Box Drive application.

Thanks for your hard work on this project--- it’s much appreciated and valued.