Read workflow activity and add comments¶
Activity brings together recorded workflow events and conversation so people can understand what happened, discuss a task and explain a decision. It complements the current workflow and task details: history can explain a change, while the refreshed detail tells you what is true now.
Availability: This guide follows the intended WorkOS Final Screens. The inspected frontend still renders example activity and does not establish connected history or comment actions. The backend contains feed reads and comment operations, with the limits below. Confirm connected availability in your workspace; this draft does not certify a deployed environment or audience acceptance.
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.
Open and read the history¶
- Open Workflows, select the workflow from My work or the relevant pooled queue, and check that its title and reference identify the correct work. See the work-list guide for that entry journey.
- Open Activity alongside Overview and Task.
- Read the event description, person or system identity, time and task or subject together. A task being claimed, a comment being added and a workflow completing mean different things.
- Use All Sources to choose where the activity came from and All activities to choose its category. Select Search to apply the intended screen's filter choice. The inspected control is a filter action; this guide does not establish a free-text search box.
- Return both filters to their all-inclusive options when looking for something that may have been excluded.
- Open View details on an event when available. Read Activity detail, then use Close details to return to the history. Discussion stays with the activity rows rather than moving into this detail panel.
The backend returns the history from oldest to newest, in pages. Read the displayed times and continue through available results before treating the first page as complete. The inspected screen does not establish a finished paging control. One example row at 15:12 appears above an earlier 15:02 row in the design; the connected display should follow the returned order.
Source and category counts describe matching recorded events, not employees, completed workflows, unread messages or the number of results already displayed. Each filter's counts take account of the other filter. A related event can appear as a preview without offering full detail in that view; viewing one workflow does not grant access to every related record, project or case.
Distinguish a workflow comment from a task discussion¶
| Where you write | What the comment belongs to | Where to check it |
|---|---|---|
| Workflow comment at the bottom of Activity | The workflow as a whole | The main activity history |
| Reply in thread for a task | That particular task | The task's discussion, reached through its activity rows |
Several events about the same task can show the same discussion and comment count. For example, claiming and completing a task do not create two independent conversations. The current implementation attaches the discussion to the task, even though the screen helper calls it the selected activity's thread. Do not assume that a reply is private to one event or to its actor.
The general workflow comment is suitable for a process-wide update. A task reply is suitable for a clarification about that specific work. Neither action completes a task, submits an approval, returns a request or changes ownership. Use the relevant request decision or intervention action for those outcomes.
Add a workflow-wide comment¶
- Open the correct workflow's Activity view and read recent entries to avoid repeating an update.
- Find Add a comment and the Workflow comment field.
- Enter a useful, nonempty update. Include enough context for later readers without copying credentials or unnecessary sensitive information.
- Select Add comment when the connected action is available.
- Refresh the history and check that the saved comment belongs to the intended workflow. Allow for the history view to catch up with a saved action.
Adding comments requires comment permission and a workflow that still allows changes. Access to read the workflow is separate from permission to comment. A finished workflow may remain readable while rejecting a new comment. This flow does not establish a way to upload an attachment, mention a person or make a private note.
Read or reply to a task discussion¶
- Identify the task in the activity row. Select View comments to expand its discussion, or Add comments where a supported task reply is offered.
- Read the existing messages, including any edited or removed indicators. Check that this is the task you mean to discuss.
- Enter the reply in Reply in thread and select the matching Reply in thread action.
- Refresh the discussion and verify the saved message. Hide comments collapses the view; it does not delete messages.
The task must belong to the selected workflow. A historical task reference alone does not establish that the workflow still accepts a new comment. The current connected contract supports task discussions; the design's generic reply controls on workflow-wide events and linked items still need reconciliation. Use the workflow-wide comment field when your note is about the overall workflow, and do not treat every visible example row as an independently supported reply target.
Understand edited and removed messages¶
Comment editing and removal are not yet verified as reliably saved. Where these actions are supported, the original author may edit a comment that has not been removed, and an authorized person may remove its text while retaining a notice. The inspected screens show edited and removed states, but their controls and connected behavior need further verification. Ask the authorized support or process owner to confirm availability and the procedure before relying on either action.
An edit retains the comment's original place in the history and records its edit time. Removal leaves a notice in that place rather than erasing all evidence that a comment existed. Removed messages remain part of the discussion count. A discussion's last-comment time is based on when its messages were created, so an edit or removal need not move the discussion to a newer position.
Removing a comment here is not evidence that every notification, audit record or retained copy elsewhere was erased. Use your organization's approved information-handling process if sensitive information was posted, and describe what needs attention without spreading the content further. This guide does not promise a complete revision browser or restoration of removed text.
Read event detail without guessing missing facts¶
The detail design includes the event's subject, step and workflow context. Some example values still need verified information: the inspected claim record does not supply the participant role or a “Step 2 of 4” position. The workflow's starting position also needs its own saved context.
Treat absent values as unavailable; do not infer an approval role from a person's job title or a numbered step from the number of visible events. A historical event can describe an earlier status while Overview has already changed. Use current saved detail for an operational decision and history for the explanation of prior events.
When history or a comment looks wrong¶
| Situation | Next step |
|---|---|
| No activity appears | Confirm the workflow and workspace, clear the filters and refresh. An empty view does not establish that no work occurred. |
| A saved action is missing from history | Check the current workflow/task detail first. History is assembled separately and can lag; do not repeat an approval, cancellation or other business action merely to make a row appear. |
| A comment submission times out | Refresh the main history or correct task discussion before submitting again. Record the time and visible message if the result remains uncertain. |
| The same discussion appears under several events | Check whether the events concern the same task. Shared task discussion is expected. |
| A reply or detail is unavailable | Confirm the supported target, access and workflow state with the administrator. A related preview or discussion indicator is not a permission grant. |
| An edit/removal appears stale | Refresh and ask support to compare the saved comment with the history view. Do not re-enter removed information to correct the display. |
| A message is inappropriate or sensitive | Use the approved support route to request authorized handling, identifying the workflow/task and time with minimal disclosure. |
For support, retain the workflow reference, task name if applicable, event/comment time, filter choices and visible result. Share them through an authorized channel. Operators have private reconciliation guidance in GitHub; readers do not need to run recovery tools.
For organization-history entries about tasks and approvals, read Interpret workflow and approval history. A recorded decision can coexist with pending approvals, and a Completed activity outcome can describe a rejection.
Use the history responsibly¶
Managers can use the sequence to understand handoffs and ask focused questions. Check actual task state and the responsible owner before treating silence as inactivity. Comments are discussion, and event counts are not a measure of individual productivity.
Executives can use recorded history to understand how work progressed and where coordination was needed. This view alone does not prove complete audit coverage, regulatory compliance, a contractual response time or a financial benefit. Administrators and support should distinguish access problems, unfinished frontend work, a saved business action and a delayed history update. No audience role automatically grants broader product access.