Somebody ran a bulk edit. A percentage was applied to the wrong column, or the filter caught more products than intended, or a decimal moved. Shopify did exactly what it was asked and reported success.
Nothing is broken. Forty prices are simply wrong, and the store looks completely normal.
Why this is hard natively
Two separate gaps, and you need both closed:
- Shopify has no undo. The bulk editor applies changes immediately. There is no "revert this edit".
- The Activity Log records that a product changed, not what it changed from. The value you need in order to put it back is the one thing not written down.
So the native recovery path is whatever you can reconstruct — an old CSV, a spreadsheet, a supplier list. If none exists, you are repricing by hand from memory.
The first problem is noticing
A bad bulk edit produces no error. The usual way people find out is an order at the wrong price, which is both late and directly expensive.
Two things shorten that.
Price-band tags make the damage visible in a list
In Rules2Tag, tag products by what they cost:
When a product's price is under $20 → add the tag
price-under-20.
A handful of bands, evaluated continuously. The value is not the tag itself — it is that a bulk edit which halves forty prices shows up as forty products changing band, visible in one filtered product list instead of by opening products one at a time.
The tag is not the recovery mechanism, and cannot be. It describes the current state, so once the price is wrong the tag is faithfully describing a wrong price. Its job is to make the blast radius obvious within minutes.
An alarm catches the size of the change
In Undo History, set a rule on the change itself:
Alert me when a product's price drops by more than 30%.
This is the half that reacts to movement rather than state, and it is the one that fires first. A 60% drop across forty products is not a decision anybody made deliberately in a bulk editor; it is a mistake, and it should page you rather than wait to be noticed.
The second problem is putting it back
Undo History keeps the value before each tracked change, which is precisely what the native log omits. So for each affected product you can see the old price and restore it — per product, or across the whole affected set at once.
The order that actually works:
- The alarm fires. You know something moved, and by how much.
- Filter by price-band tag. You know how many products and which ones.
- Open one product's history. You confirm what the price was before, and that the change is what you think it is.
- Undo. The old values go back.
- Watch the tags settle. The band tags re-evaluate against the restored prices. If they land back where they were, the recovery is complete — the tags are now doing a third job, as the confirmation.
That last step is worth doing rather than assuming. A partial undo that missed a variant leaves a product in the wrong band, and the tag will say so.
Deleted products, not just edited ones
The same mechanism covers the worse case. A deleted product is gone from the admin entirely — nothing to open, nothing to read. A change history that recorded the product's state before the deletion can put it back, because it kept its own record rather than asking Shopify to remember.
What each app is doing
| What it watches | What it gives you | |
|---|---|---|
| Rules2Tag | The current state of every product | A filterable view of which products are where |
| Undo History | Every change as it happens | The value before, an alarm, and a way back |
State and change are different things, and this is the recipe where the difference is the whole point: the tag tells you how bad it is right now, and the history tells you what it was before. Neither alone gets you back.
Both have a free plan, which is the right time to set this up — the value of a change history is entirely in having had it running before the day you need it.