Transfer Jobs currently allow the transfer of documents between two file cabinets and now, in Cloud, between two organizations. However, tracking these transfers is an operational challenge due to the absence of a built-in option to update an index field in the source system upon completion.

Today, we are forced to rely on cumbersome workarounds—scripts, AutoIndex rules, and other manual processes—just to enable basic transfer tracking. This includes creating new fields to capture the destination DocID, adding status flags to identify which documents have been transferred, and maintaining these solutions over time. These workarounds quickly become unmanageable, error-prone, and extremely time-consuming, especially when transferring millions of documents. The risk of data inconsistency and lost tracking visibility at this scale is significant and poses a serious operational concern.

What we need: The Transfer Job must natively support the ability to update index fields in both the source and the target once a document has successfully arrived in the target system. This would eliminate fragile workarounds, drastically reduce administrative overhead, and provide reliable, auditable tracking out of the box.

This enhancement would be a massive improvement to the Transfer Job functionality and is critical for any organization managing large-scale document migrations or ongoing inter-organization transfers. We strongly urge that this be prioritized on the development roadmap.