Bulk update prices and inventory in Shopify, with undo

A supplier sends a new cost list and every product from that vendor moves 6%. A sale starts Friday and ends Sunday night, and it needs the price and the compare-at price set together on two hundred variants, then both put back. A line is being cleared and everything tagged with it drops 30%. Stock arrives at one warehouse and not the other, and the counts have to land at the right location or the storefront sells what is not there.

Each of these is a few sentences in a chat and a few hundred rows in the admin. The merchant knows the rule. The work is applying it to every variant it applies to, and only those, and being able to show afterwards what changed.

Two questions merchants ask during their first price job, word for word: "How many products are you applying this change to?" and "Is this change for all of my items?" The preview answers both in its first line, and the rest of this page is about reading that line before approving.

The Shopify admin has a bulk editor: select products, "Bulk edit", and a grid with price, compare-at price and quantity columns appears. It works well for a few dozen rows that fit on one screen. It has no formula, so "raise by 10%" is arithmetic you do per cell. It has no filter by tag or vendor beyond the product list search, so "only XL variants" is a manual selection. It has no undo. It writes as you type, cell by cell, and a wrong cell is live the moment you leave it.

A CSV export handles volume and formulas. Export products, change "Variant Price", "Variant Compare At Price" and "Variant Inventory Qty" in the sheet, import. The import has no preview, and a locale that reads 12,50 as 1250 will import 1250. The export you started from is your only way back, and only if you did not overwrite it. Inventory by CSV is per location only through a separate inventory export, which is where the location column gets mixed up.

Table-style bulk editor apps add the formula and the filter, and most add a preview, which is the right shape. The remaining problem is the filter itself: it is built by hand from dropdowns, field by field, and the filter is the thing merchants get wrong. A sentence that says "XL variants of hoodies from Cedar & Pine that are active" is one line to type and four conditions to click. The preview shows rows either way; the difference is how often the rows are the ones you meant.

The instruction has three parts: which variants, what changes, by how much. Percent or fixed amount, up or down. Scope by vendor, collection, tag, product type, variant option, status or a price range, in any combination. "Only XL variants" is a scope. "Products under 20" is a scope. "Everything except the Sale collection" is a scope.

Rounding is a rule, not an afterthought. "Raise by 10%" on 24.00 gives 26.40; on 189.00 it gives 207.90. If your prices end in .99 or .00, say so, and the preview will show the rounded value. Say which way to round when it matters: "round up to .99" and "round to the nearest .99" give different results on 26.40.

ApiMate reads the variants in scope, computes the new price for each one and lists them. The list is the plan. The count in the first line is the number of variant rows the job will write. If it says 1,200 and you pictured 40, decline and narrow the scope. Nothing has been written yet.

The current value is read live from the store when the plan is built, not from a cached copy. If a colleague changed a price a minute ago, the left column shows the new one and the rule is applied to it. That also means a plan is not something to leave open overnight; build it when you are ready to read it.

A percent rule is the common case and the one where the edges bite. Ten percent on the cheapest variant in the list is pennies; on the most expensive it may cross a threshold the storefront filters on, or a price point marketing promised. Read the top and bottom of the list, not just the middle.

A fixed amount ("add 2.00 to everything from this vendor") is safer at the edges and stranger in the middle: a 2.00 increase on a 4.99 item is 40%. The preview shows the number, not the percentage, so do the division on a few rows.

A set value ("set price to 49.99") is the simplest rule and the one where scope matters most, because every row in scope becomes the same price. If the scope accidentally includes the premium line, the premium line is now 49.99. The count and a scan of the product column catch that before approval.

A sale on the storefront needs two numbers: the price the customer pays and the compare-at price it is struck through against. Setting one without the other shows no discount, or a wrong one, or a compare-at lower than the price, which themes render as a negative saving and Merchant Center flags as a price mismatch. Say both in the instruction and they land in the same plan.

When the sale ends, revert the job. The saved values put both fields back to what they were before, for exactly the variants the job changed. That is the whole "end the sale" procedure: open history, find the job, revert, approve the revert preview. A variant that was not in the sale is not in the revert.

A compare-at price that was empty before the sale is restored to empty. That matters: some themes hide the strike-through only when the field is empty, not when it equals the price.

Stock is per variant, per location. An instruction that does not name a location applies to every location the store has, and the preview shows the split. A store with one location sees one column; a store with three sees three, and the job is three writes per variant.

A wrong price is a margin hit. A wrong quantity is a customer-facing failure: zero hides the product from the storefront, too high sells what you do not have, and both show up as a support ticket rather than a report. Read inventory previews more slowly than price previews, and read the location column first.

Locations run by a fulfilment service are read-only from the Shopify side. ApiMate reports that in the plan, as a skipped row with the reason, instead of attempting the write and failing halfway through the job. "Set" and "adjust" are different rules: "set stock to 20" writes 20; "add 20" writes current plus 20. Say which.

Four checks, in this order. They take a minute and they are the whole safety model.

One approval writes every row. A few hundred variants finish in seconds; a few thousand take a minute or two, and the job reports progress and the final count. When it finishes, it appears in history with the rows it wrote and the values they replaced, which is also your record of what changed and when.

To see the result in Shopify, open a product from the list and look at the variant table; the new prices are there. The storefront shows them on its next page load, subject to any caching your theme or CDN does. For inventory, the location breakdown is on the variant's inventory panel. If a row failed, the job says which and why, and the failed rows are not marked as written.

Every variant row stores the price, compare-at price or quantity it had before the write. Reverting builds a new job from those values, shows it as a preview, and writes it after approval. It touches the rows the original job changed and no others.

Inventory is reverted to the quantity at the moment of the change. If sales happened in between, revert still writes the old number, which is now too high by the units sold. For stock, revert is a starting point, not the truth: read the location before you approve the revert, or use a fresh "set" instruction with the counted number instead.

A price reverted a week later overwrites any hand edits made in between, on the rows it covers. The revert preview shows the current value next to the value it will restore, so a hand edit is visible as a row where "current" is not what the original job wrote.

A supplier feed that arrives every Monday belongs in a file-based tool or a sync app. The file is the source of truth and the columns do not change; a sentence adds a step, not safety. The comparison page with Matrixify says where that line is.

There is no scheduler. A sale that must end at midnight on Sunday is reverted by a person on Monday morning, or by a second instruction you send when the sale ends. If your sales run on a calendar, a task-based editor that schedules is the better tool for that part, and the comparison with QuickEdit says so.

Very large jobs run in batches and the plan says how many. A catalog with tens of thousands of variants is better split by vendor or collection, so each preview is one you can read.

Prices are written in the store currency. Market-specific prices set through Shopify Markets are a separate object and are not changed by a price job unless the instruction names the market.

These phrasings resolve to plans of the same shape. The scope line tells you whether they resolved to the scope you meant.