StoreVault and Power Tools Bulk Edit Tags: what a restore does after a bulk tag edit
Last updated 1 September 2026
StoreVault is a versioned backup app for Shopify; Power Tools Bulk Edit Tags rewrites product tags across a whole catalogue in one submit. We installed Power Tools on a store we own, deleted a tag from every product that had it using their app, then restored the catalogue with StoreVault and read the result back field by field. The short version: a bulk tag edit is fully reversible. The tags come back on the same products, under the same product IDs, and nothing else on those products moves.
What we tested, and what actually happened
Tested on 31 August 2026 against a development store with 21 products, 13 of them tagged. The edit was made in their interface, not by us: Bulk delete tags → “For all products delete ALL instances of the following tags” → Winter. Their own job log recorded it as Complete — Delete tag(s) ‘Winter’, and their summary reported 13 products updated, 13 tags removed. We are not affiliated with Power Tools, the developer of Bulk Edit Tags. This page describes what happened when both apps ran on the same store.
| What we checked | What the store actually did |
|---|---|
| Does the edit reach the backup at all? | Yes. The fifteen-minute catch-up that runs in production looked at exactly the 13 changed products and stored 13 new versions. |
| Does the restore plan name the right records? | Yes. A plan for the moment before the edit named 13 records to change, 0 to recreate, 0 unchanged. |
| Do the tags come back? | Yes, on all 13, byte for byte, on the same products under the same product IDs - nothing was deleted, so no new IDs. |
| Does anything else move? | No. Title, description, vendor, product type, status, SEO, price, compare-at price and SKU came out identical on all 13. |
| Can the restore itself be undone? | Yes. Undo put all 13 products back to the state their app had left. |
Why a tag edit is the easy case, and what the hard case is
A bulk tag edit changes records; it does not delete them. That is the whole difference. The product keeps its ID, so a restore writes the old tags back onto the same record and the rest of your catalogue never notices. The expensive incident is deletion: a deleted product cannot come back under its old ID on this platform, and everything keyed to that ID has to be rebuilt. If a bulk operation is about to delete rather than edit, export first; if one already went wrong, undoing a bulk edit is the same story told from the other end.
Beyond tags: what their revert does not cover
Power Tools ships its own Revert tags job, and it does exactly what its name says: it puts tags back. Their developer listed what it deliberately does not cover and asked what StoreVault does with that list. We ran every line of it against a development store on 7 September 2026 - broke it in the live store, restored with the same code merchants use, then read the store again. The verdicts below are what the store said afterwards, not what our code intends.
| Their list | StoreVault | What happened in the run |
|---|---|---|
| Product titles and descriptions | Restored | Both came back word for word after being overwritten. |
| Prices | Restored | Variant price set to 999.99 came back as 10.00. |
| Metafields | Restored | Overwritten value came back, including metafields on variants. |
| Changed collection rules | Restored | A smart collection’s rule was rewritten and came back identical, including whether the rules apply disjunctively. |
| Changed collection sort orders | Restored | Sort order changed to PRICE_DESC came back as BEST_SELLING. That is the sort setting; a collection sorted by hand also gets its products back in their saved order. |
| Deleted products | Restored, with a boundary | The product is recreated from the snapshot, but under a new ID - the old one died with the record. Anything keyed to the old ID by another app does not follow. It comes back unpublished in every sales channel unless the backup shows it was on the Online Store and publishing is allowed, and other sales channels are not restored. |
| Deleted collections | Restored, with a boundary | The collection comes back with its title, handle, sort order and rules, and a hand-picked collection gets its products back, including products recreated under new IDs. The collection itself returns under a new ID, so links to the old one break, and it comes back unpublished unless the backup shows it was on the Online Store and publishing is allowed; other sales channels are not restored. |
| Theme changes | Restored, with a boundary | Theme versions are captured daily, and since 8 September 2026 a restore writes those files back into the theme they came from. We never create a theme and never publish one - that boundary stays. An undo puts back the theme files a restore rewrote. |
| App settings | Not restored | Another app’s settings live in that app’s own database. A store backup has no access to it, and should not. |
Two of these are worth saying plainly rather than burying in a table. A recreated record is a new record - if you have automations keyed to product IDs, they will not follow it. And an undo covers what a restore overwrote, not what it recreated: removing a recreated product would mean deleting from your store, which a backup app should never do on its own.
The boundaries, stated plainly
- We exercised one operation of theirs: deleting a tag across the catalogue. Their other tools - Speed Tag, edit by collection, edit by description - write the same
tagsfield through the same Shopify calls, but we have not run them, and we do not claim what we have not run. - Power Tools’ own data - its job log, its counters, its settings - lives in Power Tools’ infrastructure, not in your store. It is neither backed up nor touched by StoreVault.
- Media files are not re-attached by a restore - the same boundary as everywhere else, listed in full on what backup apps can and cannot restore.
How this was verified
The run is a command in our repository, not a one-off demo: it reads the truth from the store itself before and after every step, waits for the edit to be made in the other app’s interface, and every line above is its literal output. We re-run it when the restore code changes, and the date above moves only with a real re-run. The same method is published in full on the restore drill report, and the first integration pilot is on the Simple Bundles page.
A backup app covers you from the day it is installed, not from the day you need it. That is true of all of them, ours included.
StoreVault on the Shopify App Store - versioned backups of products, collections, content and themes, plus inventory levels on paid plans, with a plan shown before any restore writes.