Understand how activity history is recorded¶

Activity history records selected platform actions using a common vocabulary. It helps an authorized reader understand who started an action, when it occurred and the result that was recorded. Use Review activity history to find entries, and Follow a work-item timeline for events and discussions around one piece of work.

Draft scope: this explanation follows the inspected recording code. It does not certify an environment, confirm capture of every action or establish a retention period. Connected delivery and initial reader review remain open.

For shared work, the recorded-decision explanation distinguishes successful rejection from a blocked attempt, supplied acceptance time and generic actor labels from verified approval evidence.

The messaging history guide explains why repeated read/delivered acknowledgements can produce another entry without changing status, and why affected participants are not confirmed recipients.

The meeting history guide explains lobby and guest recording limits, repeated state actions, strict actor information and why a recording request or prepared file link does not prove available content or viewing.

The document-access history guide distinguishes preparing a viewing session, obtaining a protected file link and actually reading or signing. It explains source item, file name, intended viewer, recorded actor, expiry and repeated-request limits.

From an action to a history entry¶

The part of the platform responsible for an action decides when there is a fact to record. It supplies the organization, initiating person, occurrence time, action and permitted context. The recording process checks that information against the supported action definitions before adding it to history.

Those definitions control the wording, category, permitted outcome and which additional context an action may include. An event with missing required information, an unknown action, inconsistent wording or invalid organization context is rejected instead of being turned into an incomplete history entry. A rejected record does not itself establish that the underlying business action failed. Support must check the action's own saved state as well as its history.

The supported outcomes are Completed and Access denied. Completed describes the recorded action. For example, completing a request submission is different from completing the request's later approval process. Access denied describes a denied attempt; it does not mean that every unsuccessful or interrupted attempt across the platform appears in this view.

Understand denied attempts and history viewing¶

An Access denied entry records a selected attempt that the platform refused. Recording depends on the type of action and whether the platform has enough organization, person and related-item context. Some refusals happen before that context is available. Sign-in failures, invalid input, connection failures and every other unsuccessful interaction are not all captured as denied activity.

The refusal still applies if recording the attempt fails. An absent entry does not grant access, establish that the attempt succeeded or prove that no attempt occurred. Use the original message and the current work state when investigating; do not repeat a protected action just to create history.

Viewing organization history, including its organization filter choices, has a different recording rule. The platform reads the requested information and then attempts to send a record of that access for storage before returning it. If sending fails, the reader receives a temporary failure instead of the history response. Personal-history viewing does not use this particular access-recording step. A successfully returned organization view still does not prove that its access record has already arrived in history.

An entry about viewing organization history records the system's handling of that read. It does not prove that a person received, displayed or read every returned item. Network interruption or leaving the page can occur afterward.

Why historical details can differ from today¶

An entry keeps the actor and context supplied when it was recorded. Changing a person's name, email address, position or related work item later does not refresh that historical snapshot. Read it as recorded context, not as today's directory or the current permission to inspect the underlying work.

The time of the action and the time history was stored are separate facts. Delayed delivery can make an older action appear after newer entries have already arrived. The history view orders entries by their recorded occurrence time; an entry's late appearance does not necessarily mean the business action happened late.

Some actions require a related item, while others deliberately have none. Additional network or device context is retained only for selected action types and remains subject to viewing permissions. A sensitivity classification does not mean that every entry contains a network address or device description. Blank optional context does not establish whether it was absent or withheld in the reader view.

Network and browser/device descriptions are request context, not verified identity or location evidence. They can be incomplete or approximate. A related identifier may also lack a title or reference. Support should corroborate these details before attributing an action to a particular device, person or item.

Repeated entries and delivery retries¶

The recording process recognizes repeated delivery of the same event identity and is designed to avoid adding that delivery twice. A new publication has a new identity. Repeating a business action, or publishing a new record about it, can therefore produce another history entry even when descriptions look similar.

Use the work reference, occurrence time, action and saved source state when investigating an apparent duplicate. Matching text alone is not enough to decide that two entries are the same event. Do not repeat the action to repair history; give support enough context to investigate the original attempt.

What the history can establish¶

The normal recording path adds snapshots rather than editing their business content. That is not a promise of permanent retention or protection from every form of administrative change. Separate governed retention and deletion processes exist. The history lifecycle guide explains policy, legal hold, export scope and deletion recovery limits; do not infer a fixed number of years from the history screen.

The workflow-history guide applies these principles to requests, approval decisions, task actions and workflow setup. Use it to interpret rejection, partial approvals and simulation records.

The approval-body history guide explains effective-dated membership/delegation actions, initiating versus affected people and recording after an unchanged request.

The case activity guide explains separate HR-query and case-type history, response receipt versus recording time, and why repeated case-type state requests can reuse an earlier person and time.

The project activity guide explains why a timeline display name does not prove a separate history recording succeeded, and why the related item can be specific child work rather than the whole project.

The correspondence history guide distinguishes memo/letter status History, selected organization activity and delivery/reporting evidence, including affected-recipient limits and approved-action recording identity.

The mailbox history guide explains why an accepted email can have no activity entry, why Sent-folder verification does not prove recipient receipt, and why a resend is not a history-repair method.

Guidance for administrators, managers and support¶

Use the approved support channel to report a suspected missing or duplicate record. Include the organization, work reference, approximate action time, intended action, selected history view and filters. Establish whether the business action succeeded before requesting another attempt. Share protected descriptions and security context only with authorized reviewers.

For management reporting, agree which actions and outcomes answer the business question. Counts of retained entries do not measure hours worked, employee performance, complete transaction volume or delivery to every recipient. History can support an investigation, but the current work, source evidence and applicable organizational policy remain necessary for a conclusion.

This section introduces no new user control or recording setting. The current history interface and its connected availability are described in the reader guide. Comprehensive action coverage, hosted lifecycle recovery, operational walkthroughs and initial reader acceptance remain open.