Guide · Catalog & bulk edit
Catalog and bulk edit
The Catalog screen reads your products straight from BigCommerce — nothing is mirrored, so what you see is what the store has. From it you can open one product to inspect everything BigCommerce reports for it, or change one field across every product a filter matches.
Finding the products
Paging happens on the server, so the screen behaves the same on a store with fifty products and one with fifty thousand. Combine any of these and press Search:
| Filter | Matches |
|---|---|
Name contains… | A substring of the product name. |
SKUs, comma-separated | One or more exact SKUs, e.g. SLCTBS, OTL. |
Category IDs | Products assigned to any of those category ids. |
Any visibility | Visible only, or hidden only. |
Modified since | Products BigCommerce changed on or after that date. |
The count above the table is the number of products the filter matched, not the number on screen. Page size can be 25, 50, 100 or 250.
What gets edited: the ticked rows, or the whole filter
This is the one thing to be sure of before pressing Apply.
- Some rows ticked — the edit covers exactly those products, and only the ones on the current page. The modal says "N selected products".
- Nothing ticked — the edit covers every product the filter matches, across every page. The modal warns about this in amber, and the Apply button carries the full count.
The five operations
| Operation | What it needs | What it does |
|---|---|---|
Set a metafield | Namespace + Key + Value | Creates it where absent and updates it where present. A duplicate namespace + key is refused by BigCommerce, so this upserts rather than adding a second one. |
Delete a metafield | Namespace + Key | Removes it. Products that never had it are unaffected — the row is not a failure. |
Set a custom field | Field name + Value | Matched by name, because BigCommerce allows two custom fields sharing one name and the column is the only identifier a spreadsheet has. |
Delete a custom field | Field name | Removes every custom field with that name on the selected products. |
Show or hide | A visibility toggle | Storefront visibility only. Nothing else about the product changes. |
Preview before Apply
Preview generates the file and runs it as a dry run: every row goes through the real identification and the real checks, reads still hit your store, and nothing is written. You get back the summary, the columns of the generated file and its first rows, so you can see the exact CSV that Apply will run.
Apply is the same file, run for real. It is queued, so the screen does not block; the rows on screen are re-read a moment later, because a value you just changed showing as unchanged is worse than a slow refresh.
Things worth knowing
- Rows always say UPDATE, never MERGE. MERGE would create a product for a row whose id had been deleted between the plan being built and the file being run.
- Two custom fields with the same name are refused. BigCommerce allows them; a spreadsheet column cannot tell them apart, so the app stops rather than updating one and silently leaving the other behind.
- You will see a file you never uploaded in History. That is the generated bulk-edit file. It is marked as coming from a bulk edit and can be downloaded, so a change is always reconstructable.
- The list read is deliberately light. Only images are fetched alongside each product, for the thumbnail — a single product can carry dozens of variants, so including them would make one page of 250 products a multi-megabyte response. Variants and everything else load when you open a product.
- Reads are cached for about a minute so paging back and forth is instant. The cache is dropped as soon as a bulk edit is applied, and a product that could not be found is never cached.
- If BigCommerce refuses a read you get a panel saying so, with the upstream message — that is nearly always an expired or wrong access token rather than a fault here.