Turn on Shopify inventory tracking across every product and location

The first reader opened a second or third location and discovered that the products already in the store did not follow. Shopify attaches new products to the locations that exist when they are created; it does not backfill. So the catalog splits into products that know about all your locations and products that know about one, and the split is invisible until an order routes to the wrong place.

The second reader has been overselling. Untracked variants read as available forever, so the storefront keeps taking orders after the shelf is empty. They found the "Track quantity" checkbox, discovered it is per variant, counted their products, and closed the tab. The checkbox is right; there are just several thousand of them.

The third is migrating from a channel that managed stock elsewhere — a marketplace, a POS, a supplier feed — and needs Shopify to become the system of record before the switchover. Tracking has to be on everywhere before any count means anything.

In the Shopify admin you can bulk-edit Inventory and tick "Track quantity" for a page of variants at a time. It works, and it is the slowest of the three: the bulk editor pages, and a catalog in the low thousands is a long afternoon of ticking and waiting for saves. It also does not attach locations — that is a separate screen, per product.

A CSV export and re-import can set the inventory policy column, but the import is where quantities get hurt. The inventory columns in a Shopify product CSV carry quantities per location, so a round-trip that was meant to flip a boolean can overwrite counts with whatever was in the file when it was exported, or with blanks. People who have done this once do not do it twice.

The Admin API does it properly: `productVariantsBulkUpdate` sets `inventoryItem.tracked`, and `inventoryActivate` stocks an item at a location. That is two mutations, a paginated read to find what is missing, per-variant and per-location arguments, and rate-limit handling. It is an afternoon of scripting for a job you will run once.

Write the scope, the thing that must not change, and the thing that must not be created. The last one matters more than it looks: "do not create new locations" is what keeps a plan from inventing a location to hold the stock it is activating.

Ask for the preview explicitly. A plan that says "4,960 changes" is not the same as a plan that says "1,240 variants get tracking and 3,720 location rows get created at these three locations", and the second is what you want to read before approving.

Two different things are being changed, so the preview reports two different counts and they will not match. Tracking is one row per variant that currently has it off. Location activation is one row per variant per location that the variant is not yet stocked at. A catalog of 1,240 variants with three locations and nothing stocked anywhere yet produces 1,240 tracking rows and 3,720 location rows — 4,960 in one plan.

That asymmetry is the single most useful thing on the preview screen. If the location count comes back far smaller than you expected, the plan is only covering part of the catalog, and the reason is almost always a filter in your own instruction narrowing more than you meant.

Every row names the field it changes — `inventoryItem.tracked: false → true` for the tracking rows, `inventoryLevel.stocked: — → 0` for the location ones — so the two kinds are legible in the same list without being counted together.

A very common way to write this instruction is to add "only where tracking is currently off" — sensible, because you do not want to re-write variants that are already tracked. Read it again before you approve, because that clause can narrow the whole job rather than just the tracking part.

The variants that already have tracking on are usually the ones most likely to be missing a location, since they are the oldest products in the store. Scoping the location work to the untracked set skips exactly the products that needed it. The counts on the preview are what catch this: if tracking is 1,240 rows and the location work is also roughly 1,240 rows, the location step inherited the filter.

Two ways to avoid it. Either drop the "only where off" clause entirely — setting `tracked: true` on a variant that is already tracked changes nothing and costs nothing — or split it into two runs: tracking first, then a second instruction that says "every tracked variant" for the locations.

Turning tracking on does not set a quantity. A variant that was untracked had no count to preserve; it becomes tracked with zero on hand, which is accurate — nobody had counted it.

Activating a variant at a location it was already stocked at is not part of the plan, so the counts at your main location are not rewritten. Only the variant-location pairs that do not exist yet get created, and they open at zero.

This is worth saying plainly because it is the fear that stops people running the job: the worry is that a bulk inventory operation will flatten a year of counts. Read the preview for your main location. If the row count there is near zero, everything is already stocked there and nothing about it is being touched.

Planning is one turn: the catalog is read, the gaps are worked out, and the plan is written. That is what the credits pay for. The apply afterwards is not charged again.

The apply is where the wall-clock time goes, because each location activation is its own call to Shopify and the API is rate-limited. A catalog in the low thousands runs in minutes, not seconds, and the job page shows rows as they land, so you can close the tab and come back.

Every row is verified after it is written, not assumed. The job reports how many were accepted and how many were confirmed in Shopify afterwards, and those two numbers matching is the point.

Counting comes after tracking, not before. With every variant tracked and stocked everywhere, a stock count per location writes into rows that already exist, rather than creating them as it goes.

This is also the moment local pickup and ship-from-nearest start behaving, because routing needs a variant to exist at a location before it can choose between locations.

If the catalog came from an import, the same products usually carry supplier text and marketplace naming as well. Those are separate jobs and separate approvals.