A Shopify supplier feed with missing products should not automatically become a list of products to set to zero stock. I built feed-health holds into BC Supply Ops so short or broken files stop removals and reach a review queue. The next decision is just as important: what evidence makes that feed safe to release?
Why I put a hold before inventory removals
In BC Supply Ops for BeautyCorner.gr, I built operations around a 70,000+ product store and 7 suppliers. Three suppliers were automated; four used spreadsheets. Short or broken feeds held removals instead of mass-zeroing inventory, with the issue surfaced for review.
The decision was to separate receiving data from trusting it enough to change a live store. Stock sync produced a reviewable plan before writes. Operators had explicit confirmations, write guards, and recorded sync state.
That is the documented implementation. The acceptance sheet and release procedure below are how I would specify this safeguard for another store; they are not additional claims about that project's internals. For the surrounding import, pricing, and ordering architecture, see my multi-supplier Shopify operations walkthrough.
Does a missing row really mean zero stock?
I would first ask the supplier what the file represents. Is it a complete snapshot, a list of changed products, or an export restricted to one category? Write that agreement beside the importer configuration before enabling any missing-product rule.
A row absent from a changes-only feed tells you nothing about its current quantity. Even with a complete snapshot, I would infer zero only after confirming completeness and agreeing that omission means unavailable. An unexpected export filter should produce a review task, not a new stock policy.
Use separate outcomes for explicit zero, missing, and invalid quantity. I would reject a blank or unreadable value instead of converting it to zero. A valid explicit zero can proceed only after the file and product match pass their checks.
Define the destination quantity as carefully as the source. Shopify's inventory state definitions distinguish sellable Available inventory from On hand, which includes Committed and Unavailable quantities. A supplier's warehouse total needs an agreed mapping before it can become a Shopify quantity.
What should make the importer hold a file?
I would evaluate each supplier separately against its last accepted file with the same scope. Compare unique product identities and successful matches as well as total rows. A plausible row count alone does not prove the intended products are present.
Use this acceptance sheet before authorizing writes. Its rules are a proposed operating checklist, not Shopify settings or universal thresholds.
| Check | Evidence to retain | Hold when |
|---|---|---|
| File identity | Supplier, export time, received time, saved file reference | The file is old, incomplete, or for another supplier |
| Export scope | Snapshot or changes-only agreement; included categories | Scope changed or omission has no agreed meaning |
| Parsing | Expected columns, rejected rows, quantity validation | Required data is missing or quantities cannot be interpreted |
| Matching | Unique identifiers, matched variants, unresolved duplicates | Matches collapse or an identifier points to ambiguous variants |
| Proposed changes | Explicit zeros separated from absence-based zeros | Removals are unexplained or exceed the supplier's review limit |
| Write ownership | Intended variants, locations, and inventory state | The plan would touch quantities this importer does not own |
Set review limits from accepted supplier history and the merchant's tolerance for incorrect availability. I would not copy a percentage from another importer and call it safe. For a new supplier without history, start with manual acceptance and collect the evidence needed to set limits.
Choose the hold's scope explicitly. If file identity or parsing is unreliable, I would block every inventory write from that file. If only omission-based removals are doubtful, separately validated rows might proceed under an agreed policy; do not let that exception become automatic.
How long can you keep the previous stock values?
A hold prevents an untrusted file from changing quantities; it does not prove the previous quantities are still accurate. I would track the age of the last accepted supplier snapshot separately from the time of the latest attempted download. Repeated failed downloads must not make the data appear fresh.
Assign a named reviewer and a deadline based on that supplier's expected delivery schedule. Record which products remain exposed to uncertain availability. A hold with no owner or next review time can quietly become permanent.
Agree in advance what happens when accepted data becomes too old. Options might include obtaining a verified replacement feed or restricting affected products through the merchant's approved availability process. Keep that decision separate from interpreting a broken file as proof that everything sold out.
For products available from several suppliers, I would review the affected source before changing the shared listing. Do not remove independently verified availability simply because another supplier's feed failed. The ownership check in the acceptance sheet makes that boundary reviewable.
How do you test the hold before releasing it?
I would require a corrected file or a documented explanation that resolves the exact hold reason. If the supplier intentionally removed a category, record that scope change. If identifiers changed, review the mapping before rebuilding the plan.
Tie approval to the specific accepted file and proposed changes. Replacing the file or changing the mapping should invalidate the earlier approval. Keep rejected files for diagnosis, but do not promote them into the baseline used to judge tomorrow's feed.
Before writing, refresh Shopify quantities and rebuild any stale part of the plan. For API integrations, Shopify's inventorySetQuantities reference reserves absolute quantity setting for a system acting as the inventory source of truth. Use its documented quantity comparison for your API version to guard against concurrent changes.
I would treat a failed comparison as a reason to read and reconcile again, not permission to disable the check. A current Shopify comparison also cannot establish whether an old supplier snapshot is trustworthy. Both the source data and the destination plan must still pass review.
Build a repeatable set of test files
I would start with a sanitized, previously accepted supplier file and a saved destination snapshot. Make a separate copy for each failure case, change only the condition being tested, and record the expected decision before running it. Keep the accepted original unchanged so the next test has a known baseline.
These are proposed acceptance tests, not reported BC Supply Ops results. Run the planning tests with writes disabled; use an isolated test store for checks that require destination changes. Deliberately broken feeds should never become production test inputs.
| Test input or event | Expected decision | Evidence to inspect |
|---|---|---|
| Accepted complete file with an explicit zero | Propose a zero only for the matched, owned quantity | Variant, location, inventory state, source row, and reason |
| Snapshot truncated beyond the agreed review limit | Hold omission-based removals; retain the accepted baseline | Hold reason, affected products, and unchanged baseline reference |
| Changes-only file omitting an existing product | Leave the absent product outside the change plan | No absence-based zero for that product |
| Blank quantity or ambiguous identifier | Hold the row or file according to the agreed policy | Rejected value or conflicting matches; no authorized update |
| Same row count, but a different category replaces the expected products | Require scope review rather than accepting the row count alone | Changed identity set and unexplained removals |
| Corrected file arrives after approval | Require a new plan and approval | Replacement file reference and superseded approval |
| Destination quantity changes after review | Stop the stale absolute write and reconcile | Comparison failure and a fresh destination read |
| A held file is retried after its review deadline | Keep the unresolved hold visible and escalate | Original accepted-data age, assigned reviewer, and next action |
For each run, retain the file reference, mapping revision, destination snapshot, expected result, actual result, and reviewer. Ask the developer to show the blocked write boundary as well as the plan. A reassuring preview is insufficient if a different worker can still submit the held changes.
Separate a correct plan from permission to write
In BC Supply Ops, network writes require both DRY_RUN=false and the relevant ALLOW_*_WRITES flag. I would test each guard independently in an isolated environment: withholding either permission must block the write. This follows the documented guard design; it does not claim those exact tests were run on the project.
Repeat the hold case through the scheduled entry point as well as the operator's manual action. Require both paths to preserve the same hold reason and approved scope. If the team cannot observe whether either path attempted a write, mark that check unresolved.
Before production release, require the negative cases to pass and the corrected-file case to produce an explainable plan. Authorize a bounded set of reviewed products, name the person who can pause the importer, and compare actual changes with the approved plan. Expand only after checking the applied, held, and failed records; a successful job status alone is not acceptance.
What if the bad feed already zeroed products?
Pause the affected importer before making corrections, so another run cannot immediately repeat the change. Save the suspect file, its mapping, and the generated plan. Establish the affected supplier and locations before deciding how broadly to intervene.
Inspect representative variants using Shopify's inventory adjustment history. It shows the adjustment date, activity, creator, and resulting inventory quantities. Use that evidence alongside the importer's own records to determine which changes need investigation.
I would not replay an old export as a blanket rollback. Reconcile verified supplier availability with the store's current quantities and intervening activity, then produce a fresh correction plan. Apply a reviewed batch and inspect the result before expanding it.
Keep confirmed corrections, unresolved products, and held changes separate in the report. Completion should mean the intended corrections were checked, not merely that the importer finished running.
Where to start
Choose one supplier and compare its latest file with the last accepted snapshot. Fill in the acceptance sheet, then ask the importer to produce a plan with explicit zeros and missing-product removals counted separately. Resolve any uncertainty about export scope before enabling absence-based updates.
Keep stock review alongside the holding queue for products missing images: each queue needs a clear reason and release decision. Save the completed test matrix with the supplier's operating rules so another reviewer can repeat it after a mapping change.
If your current sync cannot explain or demonstrate its holds, request a supplier automation review or book a call. Bring a sanitized feed, its mapping, and a sample change report. Those give us a concrete starting point for testing the hold before the next live update.