Follow a file from upload to saved work¶
A file can finish uploading before the action that needs it is saved. Zerohive keeps separate records of the temporary upload, its attachment to a draft and its use by a business item. Understanding those stages helps you decide whether to continue, wait or ask for help after an interruption.
This guide explains the shared service's current behavior. Use the upload and viewing guide for the inspected final-design controls and your source guide for the exact attach, save, submit or send action. The frontend is still being connected; this page does not introduce a separate file-reservation screen.
Attached, finalizing and completed mean different things¶
| What you know | Meaning | What to check next |
|---|---|---|
| The file is ready for use | Upload checks produced a temporary prepared file | Finish the action that needs it |
| The file is attached to a draft | The temporary file is associated with a draft | Save or submit the draft through its own workflow |
| The file is finalizing | A source operation has reserved it for use | Check that original operation's result before starting again |
| The file's upload lifecycle is completed | The source acknowledged use, or a temporary reserved source package was removed through its supported processing path | Check the resulting record, request, correspondence or other destination |
| A reservation was released | The service handled a request to end a reservation; in some cases the source had already consumed the file | Check the source result; do not assume the business action was undone |
An attachment to a draft does not approve the draft or send it to anyone. A completed upload lifecycle does not certify the content, prove a signature is valid or confirm that a recipient read the file. Business completion belongs to the destination item.
Keep the original action together¶
When the platform begins using a prepared file, it binds that handoff to the destination action and, where supplied, its original operation reference. A retry must continue the same action with the expected proof. A new action cannot simply take over a file already reserved by another operation.
For signing, the task, document, saved version and intended signer also matter. Returning to another task with a similarly named PDF is not a continuation of the original attempt. Follow the workflow signing guidance and Records guidance when the result depends on a signed document.
If a response is lost or the page closes:
- Return to the original source item in the same workspace and account.
- Check its current state, selected file and saved version. Look for the original action's receipt or result where that source provides one.
- If it succeeded, continue from the saved result. Do not upload, submit or sign again merely because the browser did not show a confirmation.
- If the result is pending or unclear, follow the source's supported recovery path. Preserve the original operation reference when one was shown.
- If the issue persists, ask support to reconcile the source action and file handoff. Share the source reference, file name, time and visible error; keep temporary links and access credentials out of ordinary support messages.
There is no universal “try again with a new upload” rule. A reservation can remain while an acknowledgement is delayed, and a file can have been used even though the final response never reached the browser.
Removing a temporary draft file¶
Detaching a temporary file is different from deleting a saved business document. The shared detach operation applies only while the file remains attached to a draft. It abandons that temporary attachment and attempts physical cleanup. If storage cleanup fails, deletion can remain queued.
A reserved or consumed file needs its source-owned recovery or lifecycle process. The ordinary discard action cannot reverse its use. Likewise, a successful reservation-release response can leave an already-consumed file consumed; it is not a cancellation receipt for a record, request or letter.
Use the source action's own confirmation before removing anything. After an uncertain result, check whether the draft still references the file before selecting another copy. Delayed cleanup does not grant continuing access to an abandoned upload.
Expiry and preservation¶
A new ordinary upload normally lasts 24 hours. Attaching it to a draft sets a 30-day retention window. File-handling metadata changes during the journey, so the application must keep the appropriate current handoff information; an old preparation response is not a permanent access credential.
Once a file is reserved, ordinary upload expiry and discard do not remove it. That protection allows the source operation to finish or reconcile its result. It is not an indefinite business retention promise, and it does not replace the source's retention, deletion or recovery policy.
Some operations use a temporary package to create other results, such as importing an archive. Removing that temporary package after processing does not mean the imported records were deleted. Check the import or source result for the actual outcome.
What teams should verify¶
Users should verify the right file in the right destination. Managers should check the saved work and its decision state, rather than counting uploads as completed work. Administrators and support should reconcile uncertainty before advising repeated actions. Operators need to distinguish delayed acknowledgements, failed persistence and queued storage cleanup; these require different recovery work.
The activity guide explains why preparation and protected-link entries do not prove reading. Correspondence, Shared work and Records retain their own permissions, delivery meaning and retention rules.