> ## Documentation Index
> Fetch the complete documentation index at: https://docs.readyforcommerce.com/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> Ready for Commerce is an ecosystem that currently contains two products, PIM and Repricer, standing on one shared foundation: one identity, one organization, one team, one bill. Do not call it a platform with features, and never hint at an unreleased product.
> PIM connects to Shopify, Amazon, Square, Google Merchant Center and BigCommerce. Repricer connects to Amazon, Walmart, Shopify, BigCommerce, eBay and Square. The two products do not share one list, and each integration is authorized separately inside each product. The roster grows on purpose, so describe what the product does and let a table carry which integrations do it today, instead of counting them or writing that only one does something.
> Integration is the word this product uses, and it is the default in the documentation: the connection, the account, the Integrations screen, the per-account settings and the sync state are all integrations. Channel is reserved for the narrow sense of a destination where a listing lives, as in a product being live on a channel or archived on the channel.
> Newegg is not a supported channel. Do not describe it.
> On Amazon, PIM manages the offer only: price, availability and condition. It does not publish listing content such as titles, descriptions, images or specifications.
> Sign-in is passwordless: a single-use code emailed to the user, or Google. There are no passwords anywhere, so never describe a password, a sign-up with a password, or an email confirmation link.
> There is no public API for customers and no customer-facing webhooks. There is no organization-wide activity feed and no audit export, but the PIM does keep version history on products, brands, categories, tags and specifications, with who changed what and a restore, so never write that changes are not recorded or that an edit cannot be undone. Do not describe capabilities that are not documented here.
> Never write that the products have no AI, and never write that anything is AI-powered. Both are wrong. The PIM's image Optimizer runs AI-backed transforms the seller starts on purpose: Upscale, Remove background, and the region selection behind Refine. The Repricer reads competitor prices off web pages on the server. No control, badge or tooltip in either product names AI, and the seller never writes a prompt, so describe what the buttons do in the app's own words instead of reaching for the word.
> A PIM product, brand, category or variant can be switched off per connected integration account. Hover the channel badge and the switch is beside the account name in the card that opens. It carries no visible caption, so never call it the Sync switch: Sync is only its accessible name. On a variant-grained provider, Amazon today, the switch moves into the variant editor. On a product it asks whether to delete it from the channel, archive it there, or leave it live. Disabling stops publishing, not reading. There is still no per-field sync toggle.
> The PIM's image Optimizer replaced a feature called Squarify, which no longer exists. It resizes to an aspect ratio or to exact dimensions, removes backgrounds, upscales, trims the transparent margin around a cutout and re-centers it, pads, fills and re-encodes, and it always publishes a new asset instead of changing the original. Nothing crops into the picture: the subject is always contained whole.
> The PIM has no repricing engine and never reacts to a competitor's price. It does build the price it publishes to each integration account from the seller's own fields, configured in that account's settings, so do not write that the PIM has no pricing rules.
> Neither product has an in-app notification center, bell or inbox. Notifications are delivered by email only.
> Billing is per organization and per product, and only the organization owner can see or change it. Team members are free and uncounted, so never describe seats or per-user pricing.
> The seller never picks a plan. Each product has twelve price tiers assigned automatically from usage: the PIM from catalog product count, which includes drafts and archived products, and the Repricer from trailing 30-day sales. Nothing is feature-gated by plan and exceeding a tier never blocks work, so never write that a feature requires a higher plan.
> A subscription that is past due or paused makes the product read-only, which stops repricing and blocks edits without deleting data. Only a canceled subscription locks the seller out. Nothing is ever charged without a payment method on file.
> Pages containing the text 'This page has not been written yet', or its Spanish equivalent 'Esta página todavía no está escrita', are placeholders. Do not treat their headings as documented behavior.
# Bulk actions
> A bulk action runs one change across every row you selected, so 400 products move to active, or 60 images download together, in a single pass.
A bulk action changes many rows of a table in one pass. Set 400 of your products to `Active`, delete every brand your last import created by mistake, or download 60 images as one file. You select the rows once, and the action runs on all of them.
You build the selection with checkboxes. Every list page you open in the catalog has them: `Products`, `Brands`, `Categories`, `Tags`, the three specification lists, your `Assets` library, and `Data sources` under `Uploads`. The moment you check a box, the toolbar above the table turns into a selection bar. Your count is on the left, and the actions for that table are on the right.
Most bulk actions confirm or ask you a question in a small dialog, then run while you watch. A very large run moves to the background instead, keeps counting up on screen, and finishes on its own even if you leave the page. You will find both paths explained further down.
## Before you start
### What your role lets you do
| Role | Catalog tables | Assets | Data sources |
| --- | --- | --- | --- |
| Admin | Every action | Every action | Every action |
| Manager | Every action | Every action | Every action |
| Editor | No checkboxes | `Download` only | No access |
Below Manager, you see no checkboxes on the catalog tables at all, so there is nothing grayed out to wonder about. The assets library is the exception: whatever your role, you can select assets and download them, because a download changes nothing. Only Manager and above see `Delete` next to it. Roles are set in [team, roles and permissions](/team#what-each-pim-role-can-do).
A bulk action has no undo. There is no trash and no restore, so the count in the selection bar when you confirm is the count that changes for good.
## How to run a bulk action
Open a catalog list, for example `Products`. Check the box at the left edge of each row you want, or check the box in the header row to select the whole page. The toolbar above the table becomes the selection bar and counts what you picked, like `12 selected`.
When you have the whole page checked and more rows match your filter, a `Select all` button appears in the selection bar, with the matching total in its label. Click it and the count changes to read `All 41,000 selected`, meaning every matching row on every page.
The actions are at the right end of the selection bar, and each table gives you its own set. Click one, for example `Update status`.
A delete asks you to confirm and names the count. The other actions open a small dialog asking what to do, and run when you click `Apply`.
That is the whole flow. A progress message appears right away, updates in place, and turns into your result when the run finishes, like `Updated 200 of 200 products`. Your selection clears itself once the work is done.
Everything below explains your selection, each table's actions, and what happens while a run finishes. You do not need any of it for a small, everyday bulk change.
## Every option in detail
### Selecting rows with checkboxes
Every row has a checkbox at its left edge, and the header row has one that selects everything on the current page, on top of whatever you already had.
Your checks add up across pages. Move to page 2, check more rows, and the count in the selection bar keeps growing, because paging does not clear your selection. Changing a filter does not clear your checked rows either. They stay selected even while the filter hides them, which lets you gather rows from several searches into one action.
The selection bar shows your count next to a `Clear` button, and pressing Escape does the same as `Clear`. Your selection is also kept in the page address, so a reload brings back a whole-page selection, a `Select all`, or up to 200 individually checked rows.
On `Products`, only product rows have checkboxes. A variant row has none, because bulk actions work on whole products; to change one variant, you open its product and edit it in [variants](/pim/catalog/variants).
### Selecting everything your filter matches
Checkboxes select what you can see. `Select all` selects what your filter matches, across every page, however many that is.
Check the box in the table's header row so your whole page is selected. If more rows match your filter than the page shows, a `Select all` button appears in the selection bar, with the real total in its label, like `Select all 41,000`. Click it and your count reads `All 41,000 selected`. On an unfiltered products table that is your entire catalog, so build the filter first in [filters](/pim/filters), read the number, and then act.
The set is locked in when you confirm the action. Rows that start matching your filter after that, for example products created while a long delete runs, are not pulled in.
Three things shrink or drop your `Select all` with no message:
- Un-checking any single row takes you back to just the visible page. It does not remove one row from the total.
- Changing any filter clears the promotion, so an action never runs on a result set you have not looked at.
- While promoted, you also lose `Merge` from the bar, and any action that cannot run on a filtered total is grayed out.
After you un-check a row while every matching row is selected, the action now touches only the visible page. Read the count in the selection bar again before you confirm.
### What each table gives you
| Table | Actions in the selection bar |
| --- | --- |
| `Products` | `Update status`, `Update tags`, `Update integration sync`, `Delete` |
| `Brands` | `Merge`, `Update integration sync`, `Delete` |
| `Categories` | `Merge`, `Update integration sync`, `Delete` |
| `Tags` | `Delete` |
| Specification groups, definitions and values | `Delete` |
| `Assets` | `Download`, `Delete` |
| `Data sources` | `Run Now`, `Pause / Resume`, `Delete` |
The imports and exports tables give you no checkboxes, so nothing here applies to them. `Update integration sync` only appears while at least one connected integration can take that kind of record, so on brands and categories it comes and goes with your [integrations](/pim/integrations).
The variants grid and the specifications panel inside a product each have a selection bar of their own, with `Delete` or `Remove` for the checked rows. Those are edits to the open product, and they only count when you save it.
The product's asset panel has one too, with its own `Download` and `Remove`, plus a button that opens the [Optimizer](/pim/assets/optimizer) for several of your images at once.
### Changing the status of many products
Click `Update status` in the selection bar on `Products`. A dialog opens with one dropdown, `New status`, giving you `Draft`, `Active`, `Unlisted` and `Archived`. Click `Apply` and every selected product gets that status immediately, whatever status each one had before.
There is no per-product exception, which is the point: if some of your selection should end up different, you run two smaller selections. What each status means is explained in [products](/pim/catalog/products).
### Changing the tags on many products
Click `Update tags` in the selection bar on `Products`. The dialog opens with a `Mode` dropdown, and the mode decides what happens to the tags your products already have.
| Mode | What it does to each selected product |
| --- | --- |
| `Add` | Adds your chosen tags and leaves the rest alone |
| `Remove` | Takes your chosen tags off and touches nothing else |
| `Replace` | Changes one set of tags for another. A product with none of the outgoing tags is left untouched |
| `Overwrite` | Ends with exactly your chosen tags, whatever was there before |
`Add` and `Remove` are your safe everyday pair. Pick `Replace` to retire a tag in favor of another: it asks you for two lists, `Tags to swap out` and `Tags to add`. Pick `Overwrite` only when you want the selection to end up with one exact list, because it erases every tag you did not choose.
Closing the dialog part-way asks whether to discard your tag choices. Tags themselves are explained in [tags](/pim/catalog/tags).
### Turning integration sync on or off for a selection
Each of your products, brands and categories has a sync switch per connected account, which controls whether the PIM publishes it there. `Update integration sync` flips that switch for the whole selection. Click it in the selection bar and you get a dialog with one row per integration that can take this kind of record.
Every row starts on `Leave unchanged`, and `Apply` stays gray until you change at least one, so nothing happens by default. Pick `Turn sync on` or `Turn sync off` on a row and it answers you with the consequence, like `120 items will start syncing` or `Nothing to change`. Each row is its own decision, because the same product can be live on one of your integrations and never pushed to another.
On products, choosing `Turn sync off` adds a dropdown, `When switching off`, asking what happens to your listings already on that integration. The choices name your integration, Shopify here:
| Choice | On the integration |
| --- | --- |
| `Delete them from Shopify` | The listings are removed |
| `Archive them on Shopify` | The listings are archived, where the integration has an archive |
| `Leave them as they are` | The listings stay as they are, and just stop getting updates |
Brands and categories give you no such choice: switching them off removes them from the integration. If nothing you have connected can take the record type, the button itself does not appear.
### Merging brands or categories
Select 2 or more rows on `Brands` or `Categories` and `Merge` appears in your selection bar. It opens a short wizard: you pick the one record you are keeping, review a preview of the impact, including how many products move, and confirm. Merging is permanent, the other records are deleted, and everything they had moves to the one you picked.
The merge runs in the background and a message tells you the result, like how many brands merged and how many products were reassigned. While a merge involving one of your selected rows is still running, `Merge` is disabled with a note saying to wait.
What merging does to each field, and when you would use it, is covered in [brands](/pim/catalog/brands) and [categories](/pim/catalog/categories). `Merge` is not available on a `Select all`, so check the rows you want yourself first.
### Downloading many assets at once
Select rows in your `Assets` library and click `Download` in the selection bar. Nothing downloads in your browser: the PIM puts the files into a ZIP and emails you when it is ready, so a big selection costs you no waiting. The ZIP also appears in your exports table, and [exports](/pim/uploads/exports#reading-the-exports-table) explains how long it stays there.
### Running, pausing or deleting data sources together
The `Data sources` table under `Uploads` has three bulk actions, and you only see the section at all from Manager up.
| Action | What it does |
| --- | --- |
| `Run Now` | Starts a sync for each selected source. A paused source, or one already running or waiting, is skipped, and the result counts them, like `Queued 4 of 6 (2 skipped)` |
| `Pause / Resume` | One switch for the selection: active sources pause, and paused or errored sources resume |
| `Delete` | Removes the sources after a confirmation, along with their sync history and their claim on the fields they filled |
This table has no `Select all`, so you always check the rows yourself. What a data source is, and what pausing one means for your catalog, is on [data sources](/pim/uploads/data-sources).
### Deleting a selection
Every table's `Delete` confirms with you first and names the count, like `Delete selected products?` with how many rows are about to go. Deleting here is permanent, in the PIM and beyond it.
On products, the confirmation also lists what happens on each of your connected integrations. It says which listings are deleted there too, which are archived, and which are left untouched, following each account's own delete setting from [integrations](/pim/integrations).
Your delete can also finish with some rows skipped. A row something else still blocks is skipped instead of failing your whole run; a category whose subcategories are not part of the selection is the common case. The result says so, like `Deleted 18 of 20 categories`, with the first reason and a count of the problems. Selecting a category together with all of its subcategories deletes the whole branch in one go.
### Limits
| What | Limit |
| --- | --- |
| Rows you can check yourself for one action | 10,000 |
| Rows in a `Select all` action | 100,000 |
| Rows before a `Select all` action moves to the background | 100 |
| Individually checked rows a reload can restore | 200 |
| Rows for a `Merge` | 2 or more |
| Bulk actions running at once | One per table, per organization |
### What a bulk action cannot do
| You cannot | Do this instead |
| --- | --- |
| Undo one | Read the count in the selection bar before you confirm |
| Edit price, cost, brand, category or condition in bulk from a table | Export, edit in a spreadsheet, and send it back through [imports](/pim/uploads/imports) |
| Act on single variants | Open the product and edit it in [variants](/pim/catalog/variants) |
| Remove one row from a `Select all` | Filter more narrowly, or check the rows you want yourself |
## While your action runs
### Watching a quick run
A selection you checked yourself, or a `Select all` of 100 rows or fewer, runs while you wait. One progress message appears, counts the work, and turns into your result in place, like `Updated 200 of 200 products`. When it succeeds, your selection clears and the table refreshes. When nothing at all went through, your selection stays, so you can fix the cause and click the action again.
While it runs, a `Cancel` appears in the selection bar. Clicking it frees you to keep working, and the message says the table will refresh with the latest state. It does not stop the work, though: a quick run always finishes on its own. If you start another action before then, it is turned away with the already-running message.
### Watching a background run
A `Select all` of more than 100 rows does not run while you watch. It moves to the background, and the same progress message starts showing you live numbers instead, like `Deleting products: 12,000 of 50,000`.
This kind of run gives you a real `Cancel`, on the progress message itself. Clicking it stops the work within a moment, and the message tells you how far it got, like `Cancelled: 12,500 of 50,000 processed`. The rows already changed stay changed, which matters most when you are deleting.
A background run keeps going after you leave. Move to another screen and the progress message follows you. It even comes back on its own if you reload, or close the tab and return while the run is still going. When it ends, a message says so wherever you are in the app: `Bulk action completed`, `Bulk action failed` or `Bulk action cancelled`.
So there are two different cancels: on a quick run, `Cancel` only stops your waiting, and on a background run it stops the work itself. Neither one restores anything already written.
### When only part of it goes through
If your run hits trouble part-way, it keeps what it finished. The result names the split: `Updated 40 of 200 products before a failure. Retry to continue.` The table refreshes to show you exactly what changed, and running the same action again finishes the rest. No single row is ever left half-written.
## When something goes wrong
| Message | What to do |
| --- | --- |
| `Another bulk action is already running for your team. Try again shortly` | Someone in your organization is running one on this table. Wait for it to finish |
| `This selection exceeds the 100,000-row limit for one bulk action. Narrow the filter and retry` | Your `Select all` matched too much. Tighten the filter and run it in parts |
| `Cannot process more than 10,000 selected rows at once` | You checked too many boxes. Use a filter with `Select all` instead |
| `Some changes could not be applied. The table will refresh; retry to finish the remaining rows` | Select the rows again and rerun the action |
| `Could not start the bulk action. Try again` | A momentary problem. Run it again |
| `Failed to resolve the matching rows. Try again` | The `Select all` could not gather its rows. Run it again |
| `The bulk action lost its coordination lock mid-run. The table will refresh; retry to finish the remaining rows` | Rerun the action for the rows that remain |
| `Please wait a moment before retrying` | A short pause after an error. Wait a few seconds and retry |
## Where to go next
Building the selection a bulk action runs on.
Keeping a filter you act on often.
The bulk edit for every field the selection bar does not cover.
What merging does to every field, one screen up close.