Upload, view and sign documents¶
Zerohive uses shared document sessions to move a file into the platform, open a selected version for an authorized reader, and prepare supported signing work. The business item remains the place to decide what the file means: a record, request, memo, letter or shared-work item owns its purpose and the action that uses it.
This distinction helps teams recover from interrupted work. Uploading every byte is not the same as attaching a file to a record. Opening a viewer is not approval, and preparing a signature is not proof that the source document was updated.
Availability: ordinary upload, viewing, signature placement, internal PDF generation and document-work recording are implemented. The current frontend includes sample recovery, viewer and signing pages; the final designs describe the intended experience. Connected browser and environment acceptance remain open. This draft covers ordinary document handling, bounded expiry/export/deletion, local outcome evidence, reporting recovery, shared knowledge transfer/admission/viewing, assistant document handoffs and support interpretation. Source-caller authority and recovery, knowledge-library processing, complete reporting delivery and hosted acceptance are still being reconciled.
Choose the right starting point¶
Begin from the business action that needs the document. The shared upload machinery supports Records intake and supporting files, archive imports, workflow documents, leave attachments, memo and official-letter drafts, letter dispatch/delivery evidence, and outgoing Shared work. Those actions retain their own permissions and validation. A supported file target does not grant access to the business action.
| Your purpose | Start here |
|---|---|
| Add or review a record's documents | Records |
| Supply a document to a request or workflow | Requests and workflow execution |
| Work with memo or letter attachments | Correspondence |
| Send a document with Shared work | Sending Shared work |
| Open the primary document in received Shared work | Shared work document guide |
| Recover an ordinary upload or viewing session | Shared document guide |
| Understand attachment, finalizing and an uncertain saved result | File handoff and recovery |
| Understand temporary cleanup and this service's organization data scope | Expiry and document-session data |
| Distinguish prepared signatures and generated PDFs from saved business outcomes | Signed files and generated PDFs |
| Interpret a recorded review, processing or release result and its corrections | Document-work outcomes |
| Understand missing reporting evidence and recovery of the original result | How results reach reporting |
| Understand source-bound knowledge-file transfer, progress and cleanup | Knowledge-library file uploads |
| Understand file checks, library acceptance and recovery after completion | Complete a knowledge-library document |
| Understand administrator previews, member access and view expiry | View a knowledge-library document |
| Distinguish assistant actions, protected file work and source completion | Document work started from the assistant |
| Interpret progress, status signals and information needed by support | Document reliability and help |
Public Records intake and tenant knowledge-library uploads have separate entry and authorization rules. Signing in does not let someone take over an anonymous intake upload. Use the public intake file guidance and the source submission journey; public-adapter uploads remain outside ordinary personal recovery even when started while signed in. Knowledge uploads also cannot be recovered through the ordinary personal-upload lookup.
Understand the stages¶
| Stage | What has happened | What still needs to happen |
|---|---|---|
| Upload started | A temporary session identifies the file, uploader, destination action and expected size | Transfer the file and finish it before expiry |
| Uploading | Some file parts have been saved | Continue the same file from the confirmed progress |
| Ready to finish | The recorded transfer has reached its expected size | Finish checks and prepare the staged file |
| Ready for use | The ordinary upload has produced a staged file | Complete the source action that attaches or uses it |
| Attached to a draft | The file is associated with a draft | Finish or manage that draft through its owner |
| Finalizing | A source operation has reserved the file | Reconcile the source operation before another attempt |
| Completed | The upload lifecycle records consumption or post-consumption deletion | Check the source item's result; this label alone is not a business approval |
| Discarded, deleting or expired | Further ordinary recovery is unavailable or cleanup is pending | Use the source flow to start again when appropriate |
Progress comes from saved session state. It is not a virus-scan result, a legal signature certificate or proof that another person received the document. The activity-history explanation distinguishes preparation and protected-link records from actual reading.
Access and stored-file protection¶
Access controls determine who may open a document. Encryption protects file contents while they are stored. Protection for an ordinary file depends on its document flow and configured storage setup; a shared document session does not establish one encryption guarantee for every file. Knowledge-library uploads use a separate path that requires encryption and verifies the saved content, alongside the library's access and admission checks.
Your organization's rules for confidential files and retention still apply. A successful upload, prepared link or working viewer alone cannot certify a file's storage protection or the readiness of its environment.
Time, storage and file limits¶
An ordinary upload starts with a 24-hour lifetime. Attaching a staged file to a draft sets a separate 30-day retention window. Neither is a promise that a browser keeps the original file available; keep the original file until the source action has succeeded.
The service checks current workspace storage usage and existing upload reservations before admitting a new upload. Remaining space is a point-in-time allowance, not a reservation for a future attempt. A failed usage lookup can prevent an upload. When no positive storage limit is configured, the capability response has no finite allowance; that does not establish unlimited commercial storage or unlimited file size.
Most ordinary targets accept general file types. Signed Records artifacts require PDF; archive source packages require ZIP. The application must use the policy for the selected action. Completion checks length and a file checksum; the PDF-only path also checks the PDF header. These checks do not establish full format validation or malware clearance for ordinary uploads. The capability response does not advertise a universal chunk-size or page-count limit.
People and responsibilities¶
The uploader owns ordinary upload recovery. Managers should verify that the destination item contains the intended file, rather than treating transfer progress as completion. Executives can use these stages to distinguish a document-handling delay from an unfinished business decision; activity counts and upload status are not productivity or compliance measures.
Tenant administrators help with workspace access and storage allowance. Platform staff and support should reconcile the session, source action, expiry and error before recommending a new attempt. Operators own delayed physical cleanup and storage reconciliation. Engineering and design details are maintained in the private GitHub documentation. Public readers need no GitHub access to use this overview or guide.
Viewing and signing boundaries¶
A normal viewing session is bound to one workspace, viewer and source version, with a default one-hour lifetime. Its ordinary file links are shorter-lived, requested for no more than five minutes and bounded by the session. Reopen from the source when access expires. Downloading a copy, where offered and permitted, is a separate action from viewing.
Signing starts from an eligible source-owned task. Follow the assigned signing guide and Records guidance for the relevant action. Viewing a PDF does not grant signing permission. Readiness, placement, submission, source application and business completion are separate outcomes. The shared signing explanation describes the prepared file, optional printed labels, uncertain-result recovery and the separate background PDF-generation capability.