Support

The open-issues count doesn't match the numbers next to each issue. Why?

Origova counts two different things. The headline number — "17 open issues" — counts findings: one detected problem, which can cover several product variants at once. The number next to each issue type counts affected items (individual variants). Product-level issues like missing material or a missing description are evaluated once per product, since fixing them once fixes every variant of that product in a single click. Variant-level issues like HS code, country of origin, and weight are counted per variant, since Shopify stores those values separately for each one. So a store can correctly show "17 open issues" while the issue list adds up to 31 affected items — both numbers are right, they're just counting different things.

How is the catalog readiness percentage calculated?

Readiness = items fixed ÷ (items fixed + open findings). The two halves are deliberately different units: the numerator counts the individual items you have fixed, while the denominator adds the number of findings still open — and one finding can cover several items, for the reason in the question above. So 46 items fixed alongside 17 findings still open works out to 46 ÷ 63 = 73% ready. The dashboard shows the two pieces separately rather than as a fraction: "17 open issues" next to "46 resolved" and the date of your last scan. Readiness reads 0% until your first scan finishes, and 100% once nothing is open.

Is there a limit on how much I can fix?

Scanning is unlimited on every plan, Free included — you always see every issue in your whole catalog. What a plan governs is how many distinct products you may fix: Free covers 30 (a one-time allowance), Starter covers 1,000 each billing cycle, and Unlimited has no cap.

If a batch would carry you past your ceiling, Origova stops that batch before writing anything to Shopify and tells you exactly where you stand — how many products you have fixed, how many more this batch would add, how many you have left, and which plan covers the rest. Nothing is half-applied. Stores that installed Origova before paid plans launched keep unlimited fixing at no cost.

If I change a value in Shopify, will Origova notice?

Yes. When a product, variant, or its customs data changes in your Shopify admin, Shopify notifies Origova and the affected items refresh within seconds — no action needed. That includes country of origin, HS code, and weight, which Shopify stores on the variant's inventory item rather than on the product. The exception is a large bulk import, when Shopify fires thousands of change notifications at once: if every product in that burst is new to Origova — the usual shape of a CSV import or a store migration — the app defers the whole burst to your next full scan instead of processing it a row at a time (see the bulk-import question below). Running a scan performs a full reconciliation of your whole catalog; it's the guaranteed-current option to run before handing an export to a broker.

How long does a scan take?

It scales with your catalog. Most stores finish in under a minute; a few hundred products take a minute or two; catalogs with thousands of products take several minutes, because a scan re-reads every product and variant from Shopify and re-checks every rule against each one. The scan keeps running in the background even if you leave the page — results appear the moment it completes.

On very large catalogs you may see an amber notice that the scan is still running in the background. That's informational, not an error. Origova blocks overlapping scans on purpose (so counts stay accurate), so there's no need to start a second one — give it a few minutes and refresh.

We have thousands of products. Can Origova handle a large catalog?

Yes — it's built for it. Scans process large catalogs in bulk, and a store with a few thousand products routinely produces ten thousand or more individual findings without trouble. Two honest expectations at that scale: a scan takes several minutes rather than seconds, and applying a very large batch of fixes takes a few minutes too — Origova hands the whole batch to Shopify's Bulk Operations API and waits for Shopify to finish it (see the next question).

One more thing that's by design: the dashboard count updates once, when a scan completes — it doesn't flicker or bounce while a scan is running. A mid-scan count that looks unchanged isn't stale; it's holding steady until the new results are fully committed.

How long does fixing a large batch take?

Origova writes fixes through Shopify's Bulk Operations API — the whole batch is handed to Shopify as a single server-side job, rather than sent one product at a time. That's what keeps it fast at scale: a couple thousand items typically apply in a few minutes. A very large catalog can take a little longer, but you're waiting minutes, not hours — and the fix is real, written to Shopify itself rather than only recorded inside the app.

The job keeps running in the background even if you leave the page. When it finishes, the fixed items move to Issues fixed together, and anything that genuinely couldn't be written stays open in Scan & fix, so nothing silently disappears.

I saw a notice that a scan or fix is "still working in the background." Is something wrong?

No — the opposite. Very large jobs sometimes outlast the app's usual progress-reporting window. When that happens, the work continues on the server, and the amber notice exists so a big, busy job isn't mistaken for a broken one. Give it a few minutes, come back, and refresh.

The one thing to avoid is clicking Run scan or Apply again during that window. Origova guards against double-running, but the extra click just adds load while the original job is finishing.

I just bulk-imported products with a CSV (or a migration app). What should I expect?

A bulk import makes Shopify send thousands of change notifications in a short burst — one per product and inventory item. When those products are new to Origova, which is the usual case for a CSV import or a store migration, the app deliberately stands back rather than competing for API capacity, and relies on the next full scan to pick the whole import up at once. A re-import that only updates products Origova already knows about is handled notification by notification instead — nothing is lost, it just takes longer to settle. Origova also stands down automatically for the length of any scan or bulk fix that is already running, so an import can never race one.

So the sequence is: wait for Shopify's import complete email (large imports can take a while on Shopify's side — the product count in your admin may keep climbing for some time), then run a scan. The first scan after a big import is the longest one you'll ever run; after that, day-to-day edits sync within seconds as usual.

Why does Origova now ask for inventory permissions?

Country of origin, HS code, and weight aren't product fields in Shopify — they're stored on the inventory item. The read_inventory and write_inventory permissions are what allow Origova to read those three fields, notice when you edit them in the Shopify admin, and write your corrections back.

Within inventory, Origova touches only those three customs fields. It does not read or change stock quantities, inventory levels, transfers, or shipments, and it never accesses customers, orders, or payment data. Two of the things Origova fixes are not inventory fields at all and go through write_products instead: material, saved as the custom.material product metafield, and a product title or description when you correct one.

You'll also see read_locations on the permission screen. Shopify links every inventory item to the locations that stock it, so inventory access can't be granted without it. Origova reads no location data of its own, shows none in the app, and never requests write access to locations. If you installed Origova before these permissions existed, Shopify will ask you to approve the updated set the next time you open the app. See the full permissions breakdown in the docs.

I entered a weight in pounds. Does Origova convert it?

No. The weight is written to Shopify in the unit you chose, and shown back to you in that same unit everywhere — the fix preview, your fix history, and the Shopify admin. Weights are stored internally in kilograms so rules compare consistently across a catalog entered in mixed units, but you never see that conversion. Type 50 lb and you'll see 50 lb.

Someone edited a value in Shopify after Origova fixed it. What happens?

It depends which way it was edited, and either way the next scan settles it. If the value was broken again — cleared, or replaced with something that fails the rule — the scan re-flags it and the item comes back as an open issue in Scan & fix. If it was corrected in Shopify instead, the scan folds that correction into Issues fixed rather than letting the item quietly vanish from both lists, so a hand edit still lands in your record.

The fix history itself is an audit trail, not a live mirror. Each entry permanently records the value Origova wrote and when, and is never rewritten — an audit trail that quietly updates itself couldn't tell you what was declared on the day a shipment left. Weight is the one row that reads the current synced value rather than the historical one, so a weight changed in the Shopify admin shows its real number there.

What happens if I delete a product in Shopify?

Its catalog entry is marked inactive and drops out of future scans and exports. The fix history that references it is preserved, so deleting a product never erases your record of what you corrected on it.

A product was flagged as missing an HS code or country of origin, but I don't see those fields on the product in Shopify. Where are they?

Shopify stores customs data (HS code, country of origin, weight) on each variant's inventory item, and it hides those fields unless the variant is set as physical. In the current Shopify admin, the path is: open the product, scroll to the Shipping card near the bottom, make sure the Physical product toggle is on, then expand the Customs information subsection — that's where country of origin and HS code live. The Customs information subsection is often collapsed by default, which is why merchants sometimes think the fields don't exist.

If Physical product is off but the item really is physical, turning it on will reveal the customs fields, and Origova's next sync will pick up whatever you enter there. If a product is genuinely non-physical (digital products, services, gift cards), Origova reads Shopify's "requires shipping" flag and already excludes it from the customs rules automatically, on this scan and every future one.

I fixed Material in Origova, but I can't find a Material field on my Shopify product page. Where did it go?

Material isn't a built-in Shopify product field, so Origova stores it the standard way: as a product metafield (namespace and key custom.material). The value is saved — Origova's own rescans read it back, which is why fixed items stop being flagged. Shopify's admin just hides metafields that don't have a definition yet. To make Material visible and editable on every product page, go to Settings → Custom data → Products → Add definition, name it "Material", set the namespace and key to custom.material, and choose the "Single line text" type.

Do gift cards and digital products get flagged as compliance issues?

Not for the customs rules. Origova detects non-physical products — gift cards, digital downloads, services — from Shopify's own "requires shipping" flag and leaves them out of HS code, country of origin, weight, and material. Those fields don't apply to something that never crosses a border, so they stay out of your issue list.

One rule is deliberately not skipped: Missing product description applies to every product, physical or not, because a description is catalog hygiene rather than a customs field. So a gift card with an empty description can still appear under that one issue. If you'd rather it didn't, tick it and use Ignore selected — the ⊗ button in the dark selection bar that appears once you have rows selected. Ignored items stay ignored on every future scan until you restore them from the Issues fixed tab, and ignoring never changes anything in Shopify.

Will a fixed item come back as an issue on the next scan?

No, not on its own. Applying a fix writes the new value directly to your Shopify product or variant, not just to Origova's internal copy, so the next scan reads current Shopify data and won't re-flag a value that is already correct. A fixed item only comes back if the value was changed again in Shopify after the fix — edited by hand in the admin, for instance, or overwritten by an import. When that happens the item returns to Scan & fix as an open issue on the next scan.

What does "Undo" do on an applied fix?

Undo reverts every item in that batch back to the value it held before the fix — in Shopify itself, not just inside Origova — and the findings those items resolved reopen in Scan & fix. Not every reverted item necessarily reopens, and Origova says so rather than hiding it: an item that reverts to an earlier value which still passes the rule stays resolved, and the confirmation reads like "Reverted 2,003 items — 1,500 reopened in Scan & fix; 503 reverted to earlier values that already pass this check."

You can also use Undo item(s) to revert only specific items from a batch rather than the whole thing. Origova merges repeated fixes for one issue type into a single batch, so there's one clean record to undo rather than several overlapping ones.

What's in the export files?

The full catalog export is one row per active variant, not per product — so a product with five variants contributes five rows, each carrying its own parent product id. The columns are id, title, SKU, country of origin, HS code, weight and weightUnit, material, description, product category, parent product id, and active status. Descriptions come out as plain text with the HTML stripped, and weights are written in the unit you use.

Alongside it, Origova writes a per-issue CSV for each issue type you have already applied a fix to — "missing HS code", say — listing those items with the field and its current value, which is the slice a broker or a spreadsheet actually needs. Because those files are built from your applied fix batches, a store that has never applied a fix gets the full catalog file only. If a file would come out byte-for-byte identical to the last one you downloaded in that category, Origova skips it and tells you there is nothing new rather than handing you a duplicate.

Edits made in Shopify sync back automatically, but a fresh scan is the one action that guarantees a full reconciliation — worth running before an export someone else will rely on.

We run more than one Shopify store. Is our data kept separate?

Yes. Every store that installs Origova has fully isolated data — catalog items, scan history, findings, fixes, and exports are visible only to the store they belong to, even if multiple stores are owned by the same organization.