I recently launched PriceSafe, a Shopify bulk price editor built around scheduled sales and snapshot-based rollback. While researching the workflow, I found that the expensive failures usually happen after the initial edit: compare-at prices are set in the wrong order, a large job is throttled halfway through, or a later manual/ERP change gets silently overwritten when the sale ends.
I turned that research into a public BFCM checklist covering:
when to use a checkout discount versus changing product prices;
compare-at prices, rounding, Markets, and CSV backup;
scheduling activation and rollback together;
testing at realistic catalog scale;
handling a price changed after the original snapshot;
verifying every price on December 1.
Checklist:
Disclosure: I am the developer of PriceSafe. The app has a free plan for up to 50 variants per change; paid plans are $9.99 and $19.99 per month. App Store listing:
I am looking for feedback from merchants or agencies that are actually planning catalog-wide BFCM pricing. Which failure or check is missing from the list?
Developer disclosure: I build CatalogDelta. This is AI-assisted technical feedback, not a merchant testimonial or a claim that I have tested PriceSafe.
Based on the checks listed in your post, one explicit test case I would add is a variant being deleted and recreated between the original snapshot and the scheduled revert. A matching SKU alone is not proof that it is the same variant. Keep the original variant identity in the comparison and surface a conflict instead of silently restoring a price onto a different item.
I would also make the final acceptance check show four separate counts: intended items, verified updates, skipped/conflicted items, and failures still needing attention. “Job finished” and “every intended price verified” are different outcomes. Read back the affected prices after the job, including items that failed or were skipped.
Thanks for the thoughtful review — the deleted-and-recreated case is exactly the right test.
That’s actually how PriceSafe works today: snapshots record the variant GID, never the SKU, and the revert only ever writes back to that exact GID.
If the variant was deleted in between, the revert surfaces it as “skipped — this variant no longer exists” rather than matching anything by SKU. A
recreated twin is a different object to us, so it’s never touched. Agreed that SKU uniqueness is merchant-maintained, not guaranteed — that’s why
we don’t use it for identity at all.
On the acceptance counts: the job page already reports applied / failed / skipped / “changed by something else” as separate buckets, and drifted
items block on an explicit merchant decision instead of auto-restoring. The post-job read-back is a fair addition — today we rely on per-variant
error indexing from the mutation response, and a final verification read is on the list.
Hi @zerocoder Welcome To Shopify Community So The “later manual/ERP price change gets silently overwritten when the sale ends” failure is the one that stands out most, that’s a genuinely nasty class of bug because it’s invisible until someone notices a product priced wrong weeks after the sale, by which point tracing it back to a rollback overwrite (rather than a fresh pricing mistake) takes real digging.
One thing I’d add to the checklist: verifying rollback behavior for products that were added to the catalog during the sale window, not just ones that existed at snapshot time. If a snapshot is taken before the sale starts and new products get added mid-campaign (common during BFCM restocks or new drops), those products have no “original price” in the snapshot to roll back to, worth confirming whether PriceSafe treats those as no-op (safely ignored) or throws an error, since that’s a scenario a lot of merchants won’t think to test before relying on it.
Testing at realistic catalog scale is underrated advice in general, a lot of merchants test rollback logic on 10 products in a sandbox and assume it’ll behave identically at 5,000, throttling and partial-failure behavior specifically tend to only surface at real scale.
Thanks — this is a great addition, and exactly the kind of edge case merchants often miss because it feels intuitive that a sale only affects
products that existed when it started.
I checked the actual PriceSafe rollback path. Rollback works from the variants written by the original run, rather than scanning the current catalog.
So a product added mid-sale was never part of that run and won’t be touched during rollback — it’s a silent no-op, not an error.
The important flip side is that the new product also won’t automatically inherit the existing sale. You’d need to run a second change for that new
drop, which would then have its own snapshot and rollback.
Two related cases are worth adding to the test plan:
Scheduled sales resolve the selected products when the sale actually fires, not when it’s scheduled. So something added after scheduling but before
launch will be included, as long as it matches the selection.
If a variant is deleted during the sale, rollback skips it as “no longer exists.” It won’t try to match a recreated variant by SKU, since Shopify
SKUs aren’t guaranteed to be unique.
And fully agree on testing at scale. A 10-product test won’t expose the same throttling, partial-failure, or resume behavior you can hit with
thousands of variants. The 50-variant free-tier limit is enough to observe basic pacing, but not a failure halfway through a 5,000-variant job.
I’ll add the “product added during the sale window” case to the checklist — thanks for calling it out.