Interpret document-access history¶
Preparing access to a document is different from reading it. Selected Shared work and correspondence actions create a temporary, person-bound viewing session and can record that preparation in activity history. The entry does not prove that the document was opened, downloaded, read, approved or signed.
Draft scope: this guide explains selected access-preparation entries and the separate entry for obtaining a protected file link. Complete upload, viewing and signing journeys remain under review. Use the shared upload and viewer guide and the source guides linked below for the intended steps and availability limits.
What these entries describe¶
| Preparation | Related item in the activity entry |
|---|---|
| Prepare the primary document in Shared work | The supplied source item for the shared-work document, rather than the new viewing session itself |
| Prepare a memo attachment | The supplied memo source item, with attachment context used to relate the action |
| Prepare an official-letter attachment | The supplied official-letter source item, with attachment context used to relate the action |
The displayed file name comes from the saved document location's final name. It need not be the business title of the memo, letter or package. The entry contains no document text, file bytes or complete list of people who can access the source.
Other document families and actions use different recording paths. For example, absence from these three preparation entries does not establish that a Records document was never accessed. Meeting file access also follows a separate path.
People, time and repeated preparation¶
The intended viewer and the person recorded as performing the preparation are selected separately in the implementation. Do not use this entry alone to prove that its named actor was the person who later opened the file. Authorized support should reconcile the source action, intended viewer and recorded account when attribution matters.
The entry's time is the viewing session's creation time, not the source document's creation date or a confirmed reading time. A fresh preparation can create a new session and another entry for the same source document. Repeated entries therefore do not establish multiple reads or multiple versions of the document.
The generic session defaults to a one-hour lifetime; source-specific flows and later file links have their own constraints. A preparation entry does not renew that access or prove that it remains usable. Use the source guide's recovery steps when a session expires or the document changes.
An empty affected-people list is normal for these entries and does not mean that the document has no other readers. A completed result describes preparation of the session, not completion of work involving the document.
What a protected-access entry means¶
After a viewing session exists, the application can request a short-lived link to its file. This checks the workspace, intended viewer, session token and expiry before preparing the link. The normal service path also saves an activity entry before returning the link. If that recording fails, the request can fail even though a link was prepared internally.
This entry identifies the related source item; it carries no file name or file contents. Its time is the link request's recording time, rather than the session's creation time. Its recorded account comes from the authenticated profile. An entry alone cannot establish which person subsequently received, opened or read the file.
| Evidence | What it tells you | What it does not establish |
|---|---|---|
| Access-preparation entry | A selected source action prepared a viewing session | The file was opened or read |
| Protected-access entry | The link request reached activity recording after the session checks | The browser received the response or fetched the file |
| A successful view-open counter | The service finished its link-resolution path | The document was displayed, read, approved or signed |
Refreshing a file link can produce another entry for the same viewing session and document. It does not create another document version or prove another reading. Delayed history and a failed browser response can coexist, so avoid judging either outcome from history alone.
Why access can expire before the session¶
The ordinary file link is requested for at most five minutes, bounded by the viewing session's remaining lifetime. Less than one second of session time is insufficient to prepare it. A provider's reported expiry can be earlier, and issuing a link does not test whether the browser can retrieve its file.
A session can therefore still exist while a previously obtained file link has expired. Conversely, an old activity entry does not keep either form of access alive. Return to the authorized source flow when access expires; a copied link or another person's session is not a recovery path.
Recover without creating misleading evidence¶
- Return to the document's authorized source page and check the selected document or attachment and current version.
- If opening failed, follow that source guide's expiry or uncertain-result recovery. A filename in history is not proof that the underlying content is available.
- Do not repeatedly prepare access, download a file or sign a document merely to create a history entry. Missing or delayed history does not by itself prove that preparation failed.
- For support, preserve the workspace, source item, selected document, approximate time and visible error. Do not paste access tokens, temporary links or confidential file contents into an ordinary support message.
Follow Open the Shared work primary document, the memo guide or official-letter guide for the intended user journey and its availability limits. See how activity history is recorded for shared snapshot and recovery guidance. Managers should use separate, appropriate evidence for approval, signing, delivery and reading.