Follow a work-item timeline¶
A timeline brings together recorded events for one piece of work. Use it to understand a sequence, inspect the context of an event and find the discussion attached to a task. For organization-wide or personal action history, use Review activity history; that view has different filters, ordering and access rules.
Draft availability: the steps below follow the newer request designs in 06 Final Screens. The current interface still uses sample events and local interactions, and its service connection needs correction before these live timeline reads can work. The intended journey still needs verification in a connected workspace. A preview confirmation is not evidence that a reply was saved.
Open the right work¶
- Open the request you want to investigate through Requests. Confirm its reference and title before interpreting its history.
- Select its Timeline view. Some current screen and frontend labels use Activity for this view.
- Read the events from oldest to newest. This differs from the newest-first organization history. Use the recorded time and event description to understand the sequence.
- Compare a historical event with the work item's current details before deciding what to do next. A past approval, assignment or completion does not establish today's ownership, available action or overall completion.
Projects, cases and records have their own entry journeys. Their shared timeline reads use the same ordering and filtering principles, but their event meanings and available actions come from the owning feature. See projects, cases and records. Do not assume every request control is available in each of those destinations.
Narrow the timeline¶
The inspected request design shows All Sources, All activities and a Search button. Choose the source and activity category you need, then select Search to apply them. Here, Search applies the dropdown choices; it does not establish keyword searching.
Sources describe which part of the platform supplied the event. Categories group comments, assignments, status changes, decisions and documents. Use the choices supplied for the current work item. A source is not the same as a person, and a category is not the current status of the work.
If a connected screen shows counts beside these choices, interpret each against the other selected filter. For example, after choosing one source, the category counts describe that source's events. They count recorded events for the selected work, not people, tasks or the rows currently visible. They are not a measure of productivity or a guarantee that every past interaction was captured.
Return both choices to All to remove this narrowing. Changing filters starts a new result sequence. An empty filtered result means that this selection returned no events; it does not prove that nothing happened to the work.
Read beyond the first page¶
The backend can return a timeline or discussion in several batches, oldest first. Reaching the bottom of one batch does not establish that you have reached the latest event. Continue while the connected screen indicates more results are available. The inspected request frames and frontend do not establish a working continuation control, so this guide does not invent a button label.
Events can arrive after the underlying action, and comments can be revised. A timeline is not a frozen snapshot across successive reads. If you are investigating an apparent gap, reload the work's history and compare it with the current source details. Do not repeat an approval, dispatch or other business action merely to make a timeline entry appear.
Inspect an event¶
When View details is available, select it on the event you want to inspect. The intended design opens a side panel and keeps the surrounding timeline visible. Confirm that the panel describes the selected event; use Close details to return to the same context.
The event type determines which details can be shown. A claim event can contain task and assignment context, while a document or decision event carries different information. Missing information must remain unavailable instead of being filled from a sample. The inspected claim design's participant role, step position and origin still require composition work; those values are not guaranteed by every claim event.
A related item can show an event summary without offering its detail view. Seeing that summary does not grant access to the source item or to every related item. Use an authorized source journey when you need current business details. Names and other context recorded with an event can differ from today's directory or work state.
Keep discussions with the right task¶
The request design shows inline discussion branches and a separate request-wide comment area. A task discussion belongs to the task, so several events for the same task can refer to the same discussion. It is not a new isolated conversation for each event row.
Use View comments where available to inspect that discussion. Reply in thread is intended to keep your reply with that task. Use the request-wide Add a comment area for a general update about the request. Before submitting, check the task or request context so the message reaches the intended discussion. Follow the workflow comment guide for the current add, edit and removal boundaries.
A reply affordance does not by itself prove permission to post or that the work still accepts new comments. A comment is also not an approval or completion action. In the inspected frontend, the reply form only clears local text and displays a confirmation; it does not persist a reply. Do not rely on that sample confirmation as a saved result.
An edited comment may retain its original position. A removal notice can remain as part of the discussion's history. Discussion counts can include those notices and should not be read as a count of visible message bodies, participants or recent edits. Check current source information before claiming that a correction has propagated everywhere.
Recover when information is unavailable¶
| What you see | What to check or do |
|---|---|
| No events after filtering | Confirm the work item, restore both filters to All and reload. A quiet result does not establish absence of work. |
| An action succeeded but its event is missing | Check the work's saved state first. Allow for delayed history and give support the reference and approximate time; avoid repeating the business action. |
| An event is visible but details are unavailable | Check source access and whether this is a related-item summary. Do not infer missing history or try another user's access. |
| A discussion is visible but reply is unavailable | Check the task, current permissions and whether the work accepts comments. Use the owning work's available actions. |
| Loading fails or the timeline cannot be reached | Retain the reference and selected filters, retry the read when appropriate, and report the failure through the approved support channel. Current implementation limitations may prevent the journey. |
| A detail panel describes the wrong event or a reply exists only in the preview | Treat it as an unfinished interface. Confirm saved state through the connected owning feature before acting on it. |
| History disagrees with current work details | Use the owning work's current state for decisions and ask support to reconcile its recorded history. |
For an investigation, retain the work reference, event time, source/category choices and the precise question being answered. Share protected descriptions only through approved channels. Timeline counts and snapshots alone do not establish complete audit coverage, permanent retention, delivery to every recipient or a compliance conclusion.
For delayed events, changed comments, recovery and organization-data scope, read timeline updates and data. A healthy service or a completed projection operation alone does not establish a complete history.
Review status¶
This is a source-traced draft for users, managers and support. Request screen observations establish the intended journey; they do not certify mobile companions, every failure state, hosted authorization, working pagination or successful comment saving. Source refresh, connected walkthroughs and initial reader review remain open.