Every successful save stores, for each changed record, the previous value of each changed field. The History tab lists points newest first with date, user and record count. History keeps values, not what a save set off: on Orders, an email WooCommerce sent when a status changed, and the refund WooCommerce records for Refunded, are not taken back by Undo or Revert.

Undo, on the message that confirms a save, reverts that save straight away — all of it, even where the save was long enough to be recorded as more than one point. A long undo goes back in steps of twenty records, so a run over a whole list finishes instead of timing out. The message stays until you use it or dismiss it, open a panel, or make your next edit; it is the next stop after the grid when you press Tab.
View shows each record with field, previous value and current value, and a Revert button per field and per record. A point holding more than twenty records is shown a page at a time.
Revert on a point puts every previous value back — that point's, which is what the History line counts, and not the rest of the run if the save was recorded as several points.

A save of more than twenty rows is sent in batches of twenty, and each batch is added to the same history point as it arrives, so an ordinary run is one line in History. If a later batch fails (a timeout, a closed tab), the rows already saved are in History and can still be undone; the error message offers Undo for them.

A point holds a quarter of a megabyte of previous values — thousands of prices, stock figures or dates. A run long enough to pass that, which in practice means one over long descriptions, carries on in a new point, and so does a batch the database refuses rather than losing it. Such a run reads as several lines in History: Undo on the save message puts all of them back, newest first, while Revert on one of those lines covers that line only.

After a revert the page of records reloads, so the grid shows the values that are stored now. Reverts go through the same setters as a save, so they respect validation and fire the same hooks. Reverting a product's type changes it back the way the Type cell does, through WooCommerce; variations WooCommerce removed when the product stopped being variable are not recreated. Retention is set in Settings (default 30 days; 0 keeps points forever).

On the Orders and Reviews editors the previous values are customers' details: names, addresses, phone numbers, email addresses and notes. Tools → Erase Personal Data takes a person's records out of every history point: each order WooCommerce files under their address or account, each review left with their address, and any record whose previous values hold the address itself. A point left with nothing in it is deleted. History also never writes old values back over an order WooCommerce has anonymised, so Undo and Revert leave such an order as it is and put back the other records of the point. Tools → Export Personal Data does not list what the history holds; it is there only so that a save can be undone.

A row whose sale price is not lower than its regular price is held back when you save: it stays tinted and counted on Save changes, the message names it, and everything else in the batch is saved. Lower the sale price and save again.

The Sale starts and Sale ends cells are read as YYYY-MM-DD, the way the date picker in the cell writes them; the leading zeroes are optional, so 2026-9-3 is read too, and a time after the date is kept. A date written another way round, such as 31/12/2026 pasted from a supplier's sheet, is refused against that cell: the message names the row, the date already stored is left as it is, and the rest of the save goes through.