THE SHORT ANSWER
Approval memory should retain a decision only while its supporting context remains valid. Link each approved field to the product identity, proposed value, source evidence and rule revision. Reopen the field when relevant facts change, while keeping unrelated unchanged decisions available.
Define the unit of approval
A product-wide approval can conceal very different risks. A reviewer may accept a corrected title but still reject a material claim. Store decisions at the field level when the workflow needs that distinction, with original value, proposed value and reason.
Record the scope of the decision. Did the reviewer approve one value, a transformation rule or a batch of products sharing evidence? These approvals should not be interchangeable. Clear scope prevents one accepted example from becoming accidental permission for an entire catalog.
Attach the decision to relevant evidence
Identify which source fields support the proposed value. A title assembled from brand, model and size depends on those inputs. If the source changes an unrelated internal note, the title decision may remain valid; if the model changes, it needs another look.
Keep mapping and rule revisions alongside the approval. The same input processed by a changed rule can produce a different meaning. Reusing an old approval merely because the product ID is unchanged can preserve a decision the reviewer never actually made.
Reopen review with a useful explanation
When relevant context changes, show what changed and why the earlier approval no longer applies. Preserve the old decision as history instead of deleting it. A reviewer should be able to compare the source, previous proposal and current proposal without reconstructing the story manually.
Handle identity changes cautiously. If a source reuses a SKU for a different item, the old item’s approvals must not follow automatically. Include identity checks and explicit migration rules so review memory cannot become a source of cross-product contamination.
Measure saved work honestly
Track unchanged decisions reused, decisions reopened and new decisions made. This shows whether the workflow reduces repetitive review while still responding to new evidence. Do not call every skipped cell a quality improvement; some may simply have lacked a meaningful review policy.
Sample retained decisions periodically. This helps discover dependencies that the original policy missed. Improve the dependency model based on actual mistakes rather than making every source update reopen every field forever.
ILLUSTRATIVE WORKED EXAMPLE
Make it concrete.
Illustrative example: a shoe title was approved using brand, model, color and size. A stock-only refresh preserves that title decision. A later change to the model reference reopens the title with a visible explanation, while the unrelated shipping-policy approval remains intact.
Your practical checklist
- Record approvals at the appropriate field or rule scope.
- Keep original and proposed values with the decision.
- Identify source dependencies and mapping revisions.
- Reopen relevant fields with an explicit explanation.
- Audit a sample of retained decisions over time.
Common questions
Should approvals survive every import?
They should survive unchanged relevant evidence, not every possible source change. Define the dependency policy first.
Is bulk approval inherently unsafe?
No. It needs clear scope, representative evidence, protected fields and a reviewable preview of the affected products.
Sources & scope
Official references checked 29 October 2026. Examples are illustrative, not customer results. Platform requirements can change; use current destination documentation for implementation decisions.
Our editorial method & corrections ↗