Product record history
What changed in a product, when, why, and how it looked before.
Video transcript
In this video, you'll see what changed in a product and how to put it back the way it was.
Every time a product really changes, Bruxel saves a version. Here, you change the color.
“History” has every version, with its reason, who made it and when.
Open one and you'll see what changed: the value before and the value now.
What nobody typed, like an import or attribute detection, is shown by its reason.
Below, you pick any two versions and see the difference, even if they aren't consecutive.
An administrator can go back to an earlier version: before writing anything, it shows how it would end up.
Restoring deletes nothing: the product goes back to how it was and the history gains one more version.
In the next video, you'll translate a product into another language.
What it keeps
Every time a product record really changes, Bruxel saves a version with the product's full state at that moment. You'll find it in the «History» tab of any record.
- The record fields: name, brand, SKU, the category that came in your file, and the status.
- Attribute values, with their language.
- Assigned categories and the family.
- From the imported data, which columns changed — never their contents.
Why it's empty
History started recording the day it was turned on and does not reconstruct the past. A record that hasn't changed since then has no versions, and that's normal: it isn't an error or lost data.
When you edit it by hand you'll see two rows instead of one: the first, «Initial state», is how it looked before, and the second is the change. Bulk changes —an import, AI fill across many products— don't store that «before»: their first version is the new state, and comparison starts from the next change. Deleting an attribute, an option, a category or a family does store it: the product keeps the value it lost in its history.
Why many versions don't say who
Only changes a person makes in the app are attributed to their account (you'll see its identifier, not their full name). Imports, AI fill, attribute rules and attribute detection aren't anyone's in particular, so the row leans on the reason instead: «Import», «AI fill», «Attribute rules». If the change came through the API, you'll see the key that was used. When someone deletes an attribute, an option, a category or a family —or renames an option or a code—, the products that used it get an «Attribute or category change» version under that person's name: the product changed even though nobody edited it.
Comparing two versions
Below the list you can pick two versions and see what differs between them, even if they aren't consecutive. Only versions already loaded in the list can be compared: for an older one, press «See earlier versions» first.
Going back to an earlier version
On any version in the history, an administrator can press «Go back to this version». Before anything is written you're shown what will change and —this is the important part— what can't be brought back: an attribute option someone deleted, an attribute that no longer exists, or a value a new rule in your catalog forbids. Whatever can't be restored is said right there, and the rest does come back.
Restoring deletes nothing: the record goes back to how it was and the history gains one more version, marked «Restore» and saying which one it came from. You can always undo the undo.
What it doesn't do yet
Going back to an earlier version is something an administrator can do, from the history itself. What history does NOT bring back:
- Images and product files: the DAM has its own cycle.
- The SKU, the status and deletions: the SKU is the key your store matches on and isn't changed as a side effect; the status is managed by the generation process.
- From the file you imported, the columns' contents: only which ones changed is stored.