Someone edited a price mid-sale: what happens next

It is the second Tuesday of a two-week sale. A colleague notices that one jacket has been priced at 89 instead of 98 for months, opens the bulk editor, fixes it and moves on. Except the jacket is in the sale, its price field currently holds the sale price, and what they just “fixed” was the discount. Nobody did anything wrong. Shopify showed them a number, they typed a better one, and the sale lost a variant without telling anyone.

This post is about that moment: what a mid-sale price edit does to a storefront, why it only bites one kind of sale, and what SafeSale does when it sees it happen.

Only one kind of sale can drift

Shopify stores run sales in two ways, and the difference between them decides whether this post applies to you.

With an automatic discount, including the one SafeSale creates in Functions mode, the variant’s price field is the regular price and the discount is worked out at checkout. Edit the price mid-sale and the percentage simply applies to the new number. There is nothing to drift from, because the sale was never stored in the price.

With a price rewrite, the sale is the price field. The app moved the old price into compare-at and wrote the discounted price in its place. Shopify has no idea those two numbers are related, so anything that writes to either one, from the bulk editor to a CSV import to another app, is editing the sale whether it means to or not.

Three ways it goes wrong on the storefront

The price gets “corrected” upwards. The colleague from the opening sees 78.40 on a jacket that should be 98, and restores 98. Compare-at still says 98. The theme now shows 98 with no strikethrough, or 98 struck through next to 98, depending on the theme. Shoppers who came from the sale email see full price on the product the email showed them.

Compare-at gets cleared. A product CSV export taken before the sale, edited and re-imported, carries the pre-sale compare-at column, which for most variants is empty. The import blanks compare-at on the live variants. The discount is still being charged, but with no higher number to strike through, the page looks like an ordinary product that costs 78.40. You are paying for a sale nobody can see.

Both fields get overwritten. A supplier sends new recommended prices, someone imports them, and both price and compare-at go back to pre-sale values on every imported variant. The sale is over for those products, mid-campaign, with the countdown timer still running.

None of these are app failures. They are the predictable result of storing a sale in a field other people are allowed to edit. The question is what the app does once the field has been edited.

What SafeSale does when it notices

Every price-rewrite sale in SafeSale keeps a snapshot per variant: the price and compare-at before the sale, and the price and compare-at the sale wrote. The app also subscribes to Shopify’s products/update webhook. When a product changes, SafeSale looks up any of its variants that are currently on sale and compares the live price and compare-at with what the sale applied.

If they match, it does nothing; the update was about a title, an image or some other field, or it was SafeSale’s own write. If they do not match, it adds an entry to the sale’s audit log marked as an external change, with the applied values as “before”, the live values as “after” and a note that the original snapshot is untouched and will be restored when the sale ends. The entry shows with a red badge on the sale page so it stands out from the routine apply and revert lines.

What it deliberately does not do is write the sale price back. An app that re-applies on every external change is fighting the merchant, and if a second app is doing the same thing in the other direction the two will trade writes until one of them gives up. Flagging is the safe response; the decision about what the price should be belongs to a person.

What the revert restores

This is the part that matters most, and it is a design choice rather than a detail. When the sale ends, SafeSale writes the pre-sale snapshot to every variant. It does not calculate “current price plus the discount I took off” and write that. The snapshot post explains why delta-based reverts leave wrong prices behind; the mid-sale edit is the sharpest example. Undo a 20% discount on a price someone has already raised to 98 and you get 122.50, a number that never existed anywhere.

Writing the snapshot means an external edit cannot be compounded. It also means the edit is undone. If the colleague’s correction to 98 was right and the product had been underpriced for months, the revert puts it back to 89 along with everything else, because 89 is what was there when the sale began. The audit log is how you catch this: any sale that ended with external-change entries deserves a glance at those variants, and the entries say exactly which ones they were.

The edit that happens before the sale starts

A quieter version of the same problem happens between preview and start. You preview a scheduled sale on Monday, the prices look right, and on Wednesday someone updates a dozen variants before the sale goes live at midnight. SafeSale fingerprints the catalog it previewed and compares it with the catalog at start. If they differ, it logs an external change noting that the catalog moved between preview and start, then applies the rules to the current prices. The sale still runs; the log tells you the numbers you approved were not quite the numbers that went live. The post on products added mid-sale covers the related case where the catalog grows rather than changes.

How to make price edits during a sale

The clean answer is not to. If a price must change while a rewrite sale is running, these habits keep the damage small.

• Check whether the variant is on sale before editing it. The sale page in SafeSale lists every variant it wrote; the bulk editor does not know.
• Edit compare-at, not price, if the correction is to the regular price. The strikethrough updates, the discount stays live, and you still need to redo the change after the revert.
• Never import a product CSV during a sale unless the Price and Compare At Price columns have been removed from the file. An import writes every column it contains, including empty ones.
• After the sale ends, open the audit log and filter your attention to the red entries. Each one is a variant whose post-sale price needs a decision.
• For a price that genuinely has to change mid-campaign across many variants, end the sale, make the change, and start a new sale from the same rules. Two clean reverts beat one muddled one.

A sale stored in a price field is a sale anyone with product permissions can edit by accident. SafeSale cannot stop that, and does not try. What it does is notice, write it down with before and after values, and restore the number that was true before the sale began, so the worst case is a correction you have to make again rather than a price nobody chose.