Connecting Vault with Fusion Team Hub via the Desktop Connector – Downloading more than 50 documents at once

[ritthaler]

When exchanging design-related, project-specific documents between two Vaults, Fusion Team Hub (FTH) can serve as the intermediary platform. The upload from Vault A is initiated by selecting the top-level assembly and synchronizing it to FTH via Dekstop Connector. However, if one subsequently wishes to download this assembly into a different Vault—Vault B—the process works only selectively, as the synchronization currently imposes a limit of no more than 50 documents at a time. If the assembly contains 5,000 components, the user is forced to initiate the download 100 separate times. This is an extremely time-consuming and frustrating experience for the user!

Please lift the document quantity limit for downloads! Furthermore, provide the option to initiate synchronization—for both uploads and downloads—on a folder-by-folder basis. Doing so would significantly boost user adoption and acceptance of the FTH platform!

Möchten man konstruktive, projektrelevante Dokumente zwischen zwei Tresor austauschen kann hierbei Fusion Team Hub (FTH) als Plattform genutzt werden. Der Upload von Vault A erfolgt, in dem die oberste Baugruppe selektiert wird und nach FTH via Dekstop Connector synchronisiert wird. Möchte man nun die Baugruppe in einen Vault B downloaden, funktioniert das nur selektiv da die Synchronisation nicht mehr als 50 Dokumente auf einmal zulässt. Wenn die Baugruppe 5000 Komponenten enthält, muss der Anwender 100 mal den download starten. Das ist sehr aufwändig und frustrierend für den Anwender!

Heben Sie die Limitierung der Anzahl der Dokumente beim Download auf! Geben Sie die Möglichkeit auch ordnerweise die Synchronisation zum Up- und Download anzustarten. Das würde die Akzeptanz für die FTH Plattform deutlich erhöhen!

[ihayesjr]

@ritthaler 

Why are you using the Desktop Connector to add files to Vault B?

Why not just log into Vault B from the CAD application add-in and load the files?

[Uwe_Lindner]

Both questions are valid—let's assume, for the sake of argument, that there is no workaround available, and that the data within Team Hub is additionally required for other tasks (e.g., external manufacturing).
An additional point: Uploads to Team Hub need not originate exclusively from Vault. Let's set Vault A aside for a moment; imagine a user has manually uploaded an assembly to Team Hub. When downloading this assembly (whether at a different location or within a different company), the 50-document limitation still applies.
It would be even better if one could download the top-level assembly into Vault, with all linked components (i.e., sub-assemblies, parts, and drawings) automatically included in the download. In that scenario, the 50-file limitation would once again become irrelevant, as the "header file" would bring along all its references (one by one).
After all, this is precisely how it works when uploading an assembly *to* Team Hub.
Consequently, Team Hub must already be capable of recognizing these references.

[ritthaler]

@ihayesjr, good morning,

The main goal should be to enable an automated synchronization of project-relevant data between two Vaults. For this, we need unlimited download.

Once I have imported the data into Vault B, the goal should be that it is synchronized back to Vault A. At the latest here, we again have a problem with the limited download.

[ihayesjr]

@Uwe_Lindner 

Why not allow this external user to access your Vault directly via Vault Gateway?

@ritthaler 

You are not duplicating data between two Vaults, which would increase your environment size. Why not have all of this information in one Vault?

[Uwe_Lindner]

@ihayesjr Customer A does not seek to establish full access via a Vault Gateway, as Customer B is intended to have access solely to selected projects or project areas, and the level of trust required to justify a Gateway connection does not exist. Furthermore, Customer A wishes to avoid the effort involved in implementing a comprehensive permissions scheme within its Vault environment. Additionally, the data designated for export is flagged within Customer A’s system as "externally in progress"—thereby rendering it read-only for Customer A’s internal users. Moreover, Customer B intends to integrate this project-specific data into "its own" Vault environment and utilize it for manufacturing purposes—specifically regarding item BOMs and the integration of Vault with its ERP system. In essence, we are dealing with two entirely separate and distinct Vault ecosystems.

[Uwe_Lindner]

Pack&Go Upload from Vault to Team Hub an Download with Check-in integration to Vault B is a accepted solution for Customer. The Way return (if its nescessary) with Pack&Go and team hub ist possible and stable