A refund work item has moved to Done, but a reviewer suspects that its workflow changed before testing finished. Which record should the QA lead inspect? The configuration change and the work item's transition belong to different evidence trails. Finding one does not establish the other, and neither record alone shows which refund checks ran against which build.
In Jira Cloud, the product audit log focuses on configuration changes that can affect users and spaces. Issue history, called work-item History in current documentation, records updates on an individual item, including field edits and workflow movement. A useful QA review connects those records to the test specification and execution evidence instead of treating either log as a complete release history.
Start with the object that changed. A workflow definition governs how work can move; a work item records a particular piece of work moving through that workflow. A custom field's configuration governs its use; a field value belongs to one item. These differences determine where to look and how narrowly to state the finding.
The comparison below concerns the Jira Cloud product audit log under Settings, System, Audit Log and the History filter inside a work item's Activity section. Organization security logs, automation logs and test-management app records are separate surfaces. Do not transfer their permissions or retention rules into this comparison.
Review Criterion | Jira Product Audit Log | Work-Item History |
|---|---|---|
Main question | What recorded configuration or administrative event affected Jira? | What recorded updates happened on this work item? |
Typical events | Workflow drafts published, status definitions updated, custom fields or schemes changed | Fields edited and the item moved through its workflow |
Scope | Configuration affecting users and spaces, plus other listed events such as work-item deletion | The individual item opened for review |
Access and edition | Requires Administer Jira; unavailable when all Jira Cloud apps are Free | Open Activity and select History on an item the reviewer is authorized to view |
Coverage boundary | Records specified events, not all Jira activity; retention is configurable | Describes item updates, not a complete approved test specification or execution packet |
What remains unproven | Whether an affected behavior was tested successfully | Whether the recorded change represents application testing, approval or a release-ready result |
Treat the product log's configuration focus as a selection principle rather than an exhaustive description of every event it can hold. Atlassian also lists events such as sprint changes and work-item deletion. Conversely, selecting All in Activity combines comments, history and work logs. A comment saying “tested” or a time entry may provide context, but it is a different record from a field change and needs its own supporting evidence.
For a suspected workflow change, inspect the product audit log for the relevant recorded event, such as a workflow draft being published. Then establish whether that workflow applied to the work item during the period under review. A configuration event elsewhere in the site does not explain this item's behavior merely because the timestamps are close.
For the item's movement to Done, open the work item, find Activity and select History. That is the documented surface for workflow movement. A recorded transition supports a statement about the item changing state. It does not independently establish that the workflow definition changed, that a tester followed the intended steps, or that the application met its acceptance criteria.
Both records can therefore be useful in the same review. The configuration event identifies a candidate system change; the item's history identifies its recorded movement. The relationship between them still needs evidence about applicability and timing. Avoid writing “the workflow change caused the test to pass” when the available records show only publication and a later status transition.
A field becoming required is a configuration question. The product audit guide lists field-scheme changes covering required or optional behavior, along with custom-field and screen changes. A reviewer investigating why testers suddenly cannot complete an operation should ask the administrator about the relevant configuration and its scope.
A changed value on one refund item is a work-item question. Inspect History for the recorded edit, rather than expecting a matching product audit event for every value change. “The field was updated” is too ambiguous for an investigation note: name the field definition or the affected item and value, as appropriate.
This distinction also prevents an overbroad conclusion about impact. A configuration change may warrant checking several affected items, while one item's history explains only its own recorded updates. Define the population that needs review separately from the evidence found on the first item.
A missing entry is a result of a particular inspection, not proof that nothing changed. Before escalating an apparent logging failure, make the question specific enough that another reviewer could repeat the check.
Retention needs a log-specific check. The product audit documentation describes a configurable period; organization and automation documentation describe their own retention behavior. A duration quoted for one surface should not become a universal promise about every Jira record. If the required event is outside the available evidence, record that gap instead of silently treating the accessible period as complete.
Attribution deserves the same care. Atlassian documents a limitation in which the product audit log's Author field may omit the username for changes made through user-management pages. Elsewhere, automation changes are attributed to the configured flow actor. In Jira automation, the default is Automation for Jira, and Atlassian's example shows that account on a work item's History when a flow transitions it.
A displayed account can identify the actor recorded by the system without proving which person intended, initiated or approved the change. When automation is relevant, inspect its separate audit log for the triggered flow, execution status and attempted steps. A successful flow execution supports a conclusion about that automation; it does not automatically establish that application test assertions ran.
Organization-level investigations require another scope check. Atlassian Administration's audit documentation has its own roles, subscription requirements and search behavior. Use that surface for the question it supports, rather than treating its absence of results as an independent confirmation that a product configuration or work-item edit never occurred.
Consider a fictional refund-release investigation. An administrator finds a recorded workflow draft publication. A refund work item's History shows a subsequent move to Done. The QA lead also has an older passing result, but the refund requirement now calls for authorization to be checked again before a retry.
The publication is evidence of a recorded configuration event. The transition is evidence of the item's recorded movement. The older pass belongs to its own execution context. Together, these observations justify further investigation, but they do not establish that the new retry requirement was tested.
First, determine whether the published workflow governed this item at the relevant time. Next, inspect the transition's attribution and any relevant automation record. Then recover the test content and execution context behind the older pass. If the older specification did not include the retry condition, that result cannot establish the changed behavior, even if the work item is now Done.
For a reviewable evidence packet, retain references that answer distinct questions:
This is a recommended review record, not a claim that the Jira audit log automatically supplies all of these fields. Keep missing references explicit. A release reviewer can decide what additional evidence is required, but should not have to infer a test run from an item's status or reconstruct an expected outcome from memory.
An old result must resolve to the instructions used at the time, not merely to today's editable case. A case key or version label is insufficient if the content behind it cannot be recovered. Check what the installed test-management app retains, which fields belong to its execution record and whether permitted maintenance can change or remove them. The discussion of test case versions and run snapshots develops those preservation questions without assuming that every app uses the same model.
Sherlock Test Management provides a relevant baseline-and-run example. Its current product description says approved cases retain source references, each approval creates a baseline version, and finished runs remain attached to the version they executed. For the refund change, a team could review the proposed retry coverage separately from the earlier run's executed baseline. Human acceptance of the changed content remains distinct from recording a new execution result.
That model does not by itself establish immutable storage, electronic-signature compliance or automatic execution against the application. Verify the actual retained content and result for the review at hand. Version association helps answer what was tested; it does not make every claim about the test true.
Write findings that name the record and its boundary: a configuration event was recorded, an item changed state, or a particular execution recorded an outcome against recoverable content. If the relevant event was not found, state the surface and scope inspected and the unresolved limitation.
Before using the packet for a release decision, ask another reviewer to recover the changed requirement, applicable configuration, executed specification, build and result from its references. Where that chain breaks, obtain the missing evidence or document the uncertainty. Neither an empty audit search nor a Done transition should carry a conclusion that belongs to a verified test execution.
A tester reviewing a Jira issue may need a fresh smoke run without opening GitLab and choosing pipeline parameters. A manually triggered Jira Cloud…
A scheduled QA flow stops updating release-readiness notes. Some work items may already have changed, others may still be waiting, and the last visible…
A sprint can contain carefully estimated testing work and still overload the only person who can perform it. The missing input may be a…
Create traceable test cases, prepare release-specific test runs, and keep approved coverage current as the product changes.
