Product-level status
Each product carries a top-level publish state:The product has never been published to any target. It exists only in
MerchantOps.
The product has been published and its live data matches the current
MerchantOps version — nothing has changed since the last successful publish.
The product was published, but its data in MerchantOps has changed since then.
The live storefront is behind — publish an updated batch to bring it back in
sync.
Per-target chips
A product can be published to more than one target and environment — for example a QA VTEX store and a production VTEX store. MerchantOps shows a chip per target so you can see each destination independently: one product might be live on production and changed on QA at the same time. Each chip reflects the most recent outcome for that destination. A product isn’t simply “published” or not — it’s published per target, and the chips make that explicit.Per-target, per-environment outcomes
Under the hood, every record in a batch carries an outcome for each target and each environment it was published to. Because outcomes are keyed by both the target and its environment, a single record holds an independent QA result and production result without one overwriting the other. A recorded outcome captures what happened on that publish:| Field | Meaning |
|---|---|
| Status | success, failed, or skipped |
| Response code | The status or result code from the destination |
| Attempts | How many tries it took (more than one means it was retried) |
| Duration | How long the publish call took |
| Error | A short failure summary, present when the status is failed |
| External ID | The record’s ID in the destination system, when one exists |
Succeeded vs failed vs skipped
Succeeded
Succeeded
The record was accepted by the destination. For a catalog record that means
the product/SKU was created or updated; for a price record, the price was
set. The record shows
success and drops out of any pending-publish queue.Failed
Failed
The destination rejected the record or a permanent error occurred — for
example a variant with no matching SKU in the store. The outcome carries an
error summary and a response code. Transient problems (rate limits,
temporary server errors) are retried automatically first; only a record that
can’t be published after retries lands as failed.Skipped
Skipped
The record was intentionally not published — for instance a connector chose
to skip it. Skips are recorded as outcomes too, so they don’t silently
disappear.
Batch-level rollup
As records report outcomes, the batch tracks published and failed counts and, when every record is accounted for, reaches a final state:- Published — all records succeeded.
- Partial — some records succeeded and some failed. Review the failed records’ error summaries, fix the underlying data, and publish again.
Some connectors surface warnings alongside outcomes — non-fatal issues that
didn’t fail the publish but need attention, such as a brand or category that
doesn’t exist in the destination yet (see VTEX). A warning
doesn’t turn a
success into a failed; it flags follow-up work.Next steps
Publishing overview
How batches, targets, and scheduling fit together.
Build your own connector
Report outcomes from your own target and see them here.