OriginSpan · Episode 12 / 14

Correcting product data with history

2:38Watch on YouTube ↗Full video transcript ↓

Video hosted by YouTube. You can also watch it directly on YouTube. English narration. Captions and transcripts in English, Spanish, Italian, French and German. Meetings are conducted in English.

Someone records that a jacket was inspected at the wrong location. The mistake needs correcting, but deleting the original entry would hide what happened. This episode explains how to separate a historical correction from a new operational event. Our jacket history is illustrative, and the available correction fields and permissions must match the configured workflow.

Educational examples and AI-generated narration.

Full video transcript

Someone records that a jacket was inspected at the wrong location. The mistake needs correcting, but deleting the original entry would hide what happened. This episode explains how to separate a historical correction from a new operational event. Our jacket history is illustrative, and the available correction fields and permissions must match the configured workflow.

First identify what is wrong. Is it a model specification shared by many products, evidence for one production batch, or an event for one individual item? These have different scopes. Correcting an item inspection should not silently rewrite the whole batch. Locate the exact record and source revision before deciding which correction process is appropriate.

For an accepted lifecycle event, preserve the original and add a linked correction with a clear reason. Record who submitted it and when. Distinguish the time the business event occurred from the time the correction was recorded. OriginSpan's described lifecycle approach preserves history through visible correction links instead of silently replacing the original event.

A historical correction is not automatically a current state change. Suppose the old inspection location was wrong, but the jacket has since moved to a service center. Correcting the earlier location should not move today's item back. If the current operational state also needs updating, use the appropriate separate authorized action and keep both decisions understandable.

Check permissions and concurrent work before accepting the correction. Another operator may have already corrected the same event. Read the current version, show conflicts clearly, and require the configured review or fresh authentication for sensitive changes. Do not assume every field is editable or that registration, archived records, and custody details share the same correction rules.

Follow the effect into published information. A source correction may require a new passport version or a review of dependent translations. Preserve the relationship between the old publication and its replacement where supported. Decide who should be informed and what readers should see. Keeping history does not mean making every old value or private document public forever.

Test a real correction scenario before rollout: a wrong entry, its linked correction, the current item state, and the intended reader view. The goal is an understandable account of what changed and why. Bring one example of a data mistake to an OriginSpan demonstration. Use the booking link in the description to discuss the right workflow.

Watch next

All videos

See how it fits your business

Bring one product record, a supplier information request and the markets you serve. We can demonstrate the relevant workflow and discuss implementation together.

Book a live demo