Understand project activity and people¶
Project activity helps you understand what changed, who was involved and which work needs attention. Read an activity entry alongside the project or delivery item it describes: a past event and the current result answer different questions.
Availability: The backend produces project activity and supports shared activity reads. The inspected Final Screens show a Governance activity summary on the project Overview. They do not establish a general project Activity tab or a project discussion flow. The current project preview does not provide the intended governance summary or a connected activity timeline. Live project activity, connected controls and deployment have not been verified. The steps below describe the intended overview journey. The explanations also describe backend capabilities whose complete user interface remains unverified.
The activity-reading connection needs to be corrected and verified before connected history is available. This issue does not by itself establish whether the underlying work actions are available.
Check governance before a lifecycle decision¶
You need access to the workspace and permission to view its projects. Being a project owner, participant or named contributor does not itself grant that permission. Access to a linked approval or other item may require additional permissions.
- Open Projects and choose the project you want to review, as described in Create and manage a project.
- On Overview, check the project reference, saved owner, status and delivery context so you are reviewing the right work.
- Read Governance activity. The intended summary shows open approval workflows, when a review was last requested and the latest outcome. Check the relevant delivery work and formal review result before deciding to hold, complete or cancel the project.
This summary is useful context for a decision. An open approval is not approval, and an approved review is not proof that every project item is complete. The current lifecycle actions do not automatically check all child work or close it with the project. See Deliverables, milestones and formal reviews for the difference between a request, an outcome and the saved delivery state.
The live summary still needs to be connected and verified. Do not substitute sample figures for the actual project record. A missing summary or unavailable linked item does not prove that no governance work exists.
Understand the kinds of activity¶
| Information | What it can tell you | What it cannot establish on its own |
|---|---|---|
| Current project overview | Saved project setup, current state and intended governance context | Every past change or a complete decision history |
| Recorded activity | Selected events such as project creation, lifecycle changes, delivery completion and linked evidence | Every edit, delivery of every event or the item's current state |
| History reconstructed from current records | Events inferred from dates and values still held on the project and its related records | Earlier values that have been replaced or every repeated change |
| Governed activity logs | Separately controlled records of supported actions for authorized review | A public project timeline, every changed field or a compliance guarantee |
The backend records selected lifecycle, execution, milestone, deliverable, repository and governance events. These are not interchangeable outcomes. Work submitted for review is awaiting review; repository synchronization requested means a request was recorded; evidence attached to work does not mean the evidence or work was approved. A milestone achievement records that its configured criteria and any required workflow approval were satisfied at evaluation. Later changes can alter the milestone's state. Always read the current item and its review requirements.
Some history is reconstructed from current records. For example, the project's current hold can appear while the project is on hold, but that reconstruction does not preserve each earlier hold and resumption. Its setup-update entry is inferred from a timestamp and does not list the fields changed. A name shown there may come from a person's current available profile rather than their name at the time.
Recorded events and reconstructed history also have different ordering rules. The shared activity feed reads from oldest to newest, while the project reconstruction reads from newest to oldest. Their entries and totals should not be treated as matching lists. The complete project presentation for these reads still needs verification.
Understand separately recorded project actions¶
Selected project setup, execution, milestone, deliverable, repository and governance actions also produce organization activity-history records. Use the history reader guide for that separate view. A project timeline row and an organization-history entry are not two guaranteed copies of the same event.
These recordings require usable details for the responsible person. A timeline can show a name from saved project profile information. The separate history recording also needs a matching identity for the person performing the action, with a name and email. Seeing a name in a timeline does not prove that this other recording succeeded. Missing person details can interrupt the operation, so verify the saved project or item before retrying an unclear result.
The related item can be the project itself or a particular execution item, group, milestone, deliverable or repository record. Keep that specific reference when investigating history; a child-work entry need not identify the whole project as its related item. Being named as an affected person is also different from being the recorded actor.
A Completed history outcome describes the recorded action. It does not mean that the project or all its child work is finished, that a requested review has approved the work, or that synchronization retrieved every repository update. These entries do not contain a full comparison of changed settings or every review note and delivery result. Use the current source item and its authorized review records for those details. The recording guide explains repeated publications, saved snapshots and missing entries.
Interpret names, responsibility and timestamps¶
A person's displayed name, photograph, department and job title provide context. They do not grant access, change project ownership or establish who performed every action. Workforce profile changes are copied into project displays in the background, so displayed details may lag the current workforce record.
Recorded activity captures the available name and picture of the person associated with an event when that event is prepared. Later profile updates do not by themselves establish that old entries have been relabelled. When identity is unavailable, the underlying record can identify System or use an identifier instead of a name. That is insufficient evidence to attribute the action to a particular person. Ask support to investigate instead of inferring responsibility from an incomplete name.
Repository evidence needs particular care. A repository activity can name the person associated with the imported evidence. That person may differ from whoever linked the evidence to project work. See Repository evidence and Contribution and project data before interpreting either entry as contribution credit.
There is also a known resumption-history limitation: resuming a held project reuses the first activation time when preparing its activation event. A separate new resumption entry is therefore not established by the inspected behavior. Check the current project state and ask support to investigate disputed timing; do not use this history alone to certify a sequence of decisions.
When information is missing or disagrees¶
| Situation | Useful next step |
|---|---|
| A recent change is absent from activity | Check the saved project or item first. Report missing activity with the project reference, action and approximate time; do not repeat a business action merely to produce a history entry. |
| Activity shows an older state | Open the current item and examine its review or completion result. A past event can remain valid even after later work changes the state. |
| A name, picture or department is wrong | Ask an authorized administrator to verify the workforce profile and have support check its propagation. Editing the project title or ownership is not a profile correction. |
| A linked approval or detail is inaccessible | Confirm workspace and item access with an administrator. Being mentioned in an event does not grant access to the linked work. |
| A request timed out or its result is unclear | Check the saved result before trying again. Provide the affected reference and time through the approved support channel. |
| Two activity views differ | Identify which view was used, its scope, filters and observation time. Recorded events and reconstructed history have different coverage. |
Do not include passwords, access tokens or unrelated confidential content in a support request. The project activity surface inspected here does not provide a verified general reply, edit-history or delete-history journey.
Use activity in management and review¶
Managers can use activity to identify the next conversation: whether work awaits review, a dependency needs attention or a governance outcome needs reconciliation. Executives should combine it with current delivery results and reports. Activity volume is not effort, productivity, independently accepted quality or business value.
Administrators and support teams should distinguish access problems, stale profile information, delayed activity and an unsaved business action before choosing a remedy. Operational replay, retention and audit procedures belong to authorized internal teams. No guaranteed delivery time, retention period, project-specific activity charge or complete audit certification is established by this project documentation.