Audit & traceability

Installed PROVEN app

See what changed, who changed it, and whether the result was confirmed in Shopify.

When a catalog question comes up, you do not have to reconstruct the change from fragments. PROVEN connects the action, target, available context and verified result in one history you can follow.

Available in the installed PROVEN app within role and permission boundaries

Less manual investigation

Do not reconstruct a change history manually.

Audit connects the change to its context so you can understand what happened quickly and, where possible, return safely to the previous version.

01

Who

See the person or system action associated with the change.

02

What

Identify the product, field or image that was modified.

03

Why

The change can be connected to the issue and remediation that came before it.

04

With what result

See whether Shopify accepted the change and whether the result was then confirmed.

Change history

See separately what was approved, what was published and what was confirmed.

This keeps Shopify accepting a change from being confused with proof that the final result is the one you expected.

  1. 01

    Before the change

    PROVEN keeps the available previous state and the result the change is intended to produce.

  2. 02

    Publication

    The change is connected to the person who initiated it and the Shopify item being changed.

  3. 03

    Verification

    When the result can be read back, PROVEN compares it with the approved change and keeps the verification result.

  4. 04

    Eligible restore

    For changes with a safely retained previous version, returning to it is a separate, verified action.

What a record shows

Enough context to understand the change.

Audit keeps useful investigation information without turning history into a full copy of the catalog.

Older records can have less context when some information was not retained at the time of the change.

ExampleCatalog change
Verified
Change
Type of modification applied
Target
Product, field or image affected
Initiated by
Person or system action associated with it
Context
Issue and remediation that led to the change
Before / after
Available previous state and intended result
Shopify result
Acceptance and verification where they can be confirmed
Restore
Reversal state when restore is available

Before and after

PROVEN keeps the starting state, intended result and observed result separate.

Separating these moments makes comparison clear and reduces the risk of confusing intent with outcome.

BEFORE
Starting state

What was available before the change was published.

PROPOSED
Approved result

What the change was intended to produce.

AFTER
Observed result

What could be confirmed from Shopify after publication.

If information was not retained when the change happened, PROVEN does not invent it later.

Complete context

From problem to verified result.

Audit can connect the problem to the approved change, Shopify publication and verified result.

  1. 01Issue
  2. 02Proposal
  3. 03Approval
  4. 04Publication
  5. 05Shopify object
  6. 06Verification

Controlled restore

Available where safe

Reversal keeps the same level of control as publication.

Restore is available only when PROVEN retained the required previous version and can confirm that the reversal applies to the correct current Shopify state.

Available example

Image source

For eligible image replacements, the original can be retained and restored after checking the current state.

Principle

Restore only for reversible changes

PROVEN does not show a restore action when the previous state cannot be retained and verified safely.

What happened around the change

See the important actions that happened in the store and in PROVEN.

Alongside catalog changes, PROVEN keeps a chronological history of important access, configuration, synchronization and publishing actions. Events already recorded are not rewritten.

ACCESSSign-ins, access granted or denied, and delegation changes
STOREInstallation, configuration, uninstall and important app-access changes
TEAMTeam access, user confirmation and access still pending
SYNCSynchronization and checks: started, stopped, resumed, completed or failed
DECISIONSCheck rules and decisions about found problems
PUBLISHPreparing, approving, rejecting, cancelling and applying changes to Shopify
AIAI analysis: request, cancellation, completion and failure
PLATFORMLanguage features, support and important service events

Approval and publishing remain separate steps. Catalog history keeps the applied change and the verified result. Audit follows important product actions rather than every interface interaction.

Tracked changes

Audit covers the main catalog changes executed through PROVEN.

The available details depend on the type of change and what PROVEN could observe before and after publishing.

PRODUCTProduct fields
ALTMedia alt text
IMAGEImage source replacement
RESTOREReturn to a retained source

Everyone sees only what they are allowed to see

Your team sees its own store history; support can investigate with additional context.

The same change can be viewed differently by role without allowing one store to see another store’s data.

Store team

Your store history

Your team can inspect changes to the store catalog when it has the required permission.

  • Data remains scoped to the current store.
  • Changes can be filtered and followed over time.
  • Historical information that does not exist stays explicitly unavailable.
PROVEN team

Support and security investigation

Authorized PROVEN team members can investigate support and security events without changing store history.

  • Filter by store and type of action.
  • See when the action happened, who was involved and what result was recorded when those details are available.
  • Sensitive credentials and secrets are not exposed in the history.

A history you can rely on

History says only what it can prove.

  • It does not retroactively fill in information that was never retained.
  • It does not treat a request being accepted as a verified result.
  • It records important actions rather than every interface interaction.
  • It does not expose secrets or sensitive credentials in access history.
  • It does not offer Restore when a change cannot be reversed safely.

Traceability across the product

From user action to verified result.

History of important actions explains what happened around a change, while catalog history shows what changed and which result was confirmed.

Available functions depend on the change type, store permissions and active option.

Explore checksAudit guide