Interpret workflow and approval history¶
Workflow history helps explain selected actions around requests, tasks, approvals and workflow setup. Read the recorded action together with the current work. A completed history entry can describe a submission, a decision or a settings change while the overall work remains open.
Draft scope: this guide follows the inspected workflow recording code. It adds interpretation to activity-history viewing and work-item timelines. Use the request guide, approval guidance and workflow designer guide for their intended screen journeys. Connected delivery and initial reader review remain open.
What a recorded action means¶
| Recorded action | How to interpret it |
|---|---|
| A request is submitted, or a general workflow starts | The work started. It does not mean that its tasks or approvals are finished. |
| A person claims or acknowledges a task | The recorded claim or acknowledgement occurred. Check the current task to see its owner and remaining work. |
| A task is completed | That task's completion was recorded; other tasks, parallel branches or later steps can remain. |
| An approval decision is recorded | One decision was recorded. Other required people may still need to decide. |
| Work is returned for correction or resubmitted | The correction cycle advanced. A resubmission does not itself approve the request. |
| A task is reassigned or escalated | A change was recorded. Open the task for its current assignment and the reason available there. |
| A workflow is cancelled | Cancellation was recorded for that workflow. Related services and linked work may have their own outcomes to reconcile. |
| A comment or document is added | The addition was recorded. The history entry is not the complete comment, document or every later revision. |
An approval can be rejected while its activity outcome is Completed: the completed action was recording the rejection. Access denied instead describes an attempt the platform refused to allow. Do not count every Completed entry as an approved request or a successful business result.
The platform uses different recorded actions for request tasks, general workflow tasks and record-approval tasks. An approval decision is not automatically an additional ordinary task-completion history entry. The work-item timeline and organization history also describe different facts, so their entry counts need not match.
Changes to who belongs to an approval body, who chairs it and who holds delegated authority have a separate administration-history explanation. Those entries do not represent decisions on an individual request.
Workflow setup and service-level changes¶
Creating a workflow definition, changing its structure, running a simulation and publishing it have their own recording paths. Creating, updating and deactivating a service-level policy—the rules for response and completion targets—can also be recorded. These entries help identify that a setup action occurred; they are not a complete comparison of every field before and after the change.
A completed simulation entry means the simulation action was recorded. It does not establish that the simulation found no issues or that the definition can be published. Review the saved simulation result and current draft revision in the workflow designer. Similarly, a published definition does not prove that every organization has started using it or that existing work was retroactively changed.
Understand the person, reference and time¶
The entry keeps the person details available when the activity was prepared. Work performed through an assistant or an automated process still needs enough information about the responsible person. If that information is missing or identifies a different person, recording can fail. Support should inspect the original work and its result when an expected entry is missing.
Related information describes the workflow, request or definition supplied to the recording process. A task action may be associated with its workflow rather than expose a separate link to that task. A visible record reference does not mean that the history entry contains the record's files or grants permission to open them.
The recorded time comes from the relevant saved action information where available. Delayed delivery can make an earlier action appear later in history. Compare the action, reference and current work state before interpreting a repeated entry or an apparent gap; matching descriptions alone do not establish duplication.
What to check in the original work¶
Use the original request, task, approval or workflow definition for the information needed to continue work. These activity entries do not provide every changed form answer, reassignment reason, correction reason, approval comment, comment body, document content or setup difference. Related timeline and business records can carry additional context under their own access and retention rules.
For a review or management report, identify the exact action being counted. Keep decisions separate from task completion, submissions separate from completed requests, and simulations separate from successful validation. Retain the organization, person and date filters used to reach the result. The recording guide explains delivery retries, conditional denial recording and historical snapshots; the lifecycle guide explains retained-history limits.
When the visible history and current work disagree, report the work reference, action and approximate time through the approved support channel. Establish the saved business result before repeating a submission or decision. Operational reconciliation, full domain-publisher coverage and reader acceptance remain unfinished; this guide does not introduce a new repair button or permission.