Price batches

A price batch groups related price changes so they can be reviewed, approved, and published together on a chosen effective date. Batches give you a review gate before prices go live and a single unit to schedule and track. This page covers the batch workflow for merchandisers and reviewers. For the underlying records, see Price records.

​

Why batches

Publishing prices one record at a time offers no review step and no way to make a set of changes go live at the same moment. A batch solves both: it collects the records, requires an approval before anything publishes, and carries a single effective date so every price in it takes effect together. Most price creation flows put records into a batch automatically. Mass-create and bulk-set operations find or create an open batch keyed on the effective date, so changes sharing a date coalesce into one batch. You can also create a batch explicitly and add records to it. Batches don’t always create new prices. A republish batch instead references existing price records and re-delivers their current values to a target without changing them — useful for re-pushing prices after a target integration is added or reset.

​

The review lifecycle

A batch moves through a fixed set of states. You cannot approve a draft directly — it must first be submitted for review, mirroring a two-person workflow where the author submits and a separate reviewer approves.

​

Required effective date

Every batch carries an effective date, entered as a calendar date and interpreted as local midnight in your organization’s publishing time zone. This date is both the schedule (when the prices go live) and the grouping key that auto-batching uses to coalesce same-day changes.

​

What you can edit, and when

Edit rules tighten as a batch advances, so a reviewer can trust that an approved batch will not silently change: The publishing target stays editable through approval on purpose: a batch approved without a target is not a dead end — set the target on the approved batch and it becomes publishable. The target locks for good once publishing has been attempted, whatever the status says, because the recorded per-target outcomes are keyed to it. Trying to edit a field that is not allowed in the current status returns an error, so the interface can explain why the change did not stick.

​

Scheduled publishing

An approved batch publishes on its own when its effective date arrives — you do not have to trigger it. You can watch progress on the batch’s publish-status view, which reports how many prices have published, failed, or been skipped, broken down by publishing target. A batch approved without a publishing target is the exception: its prices go active in MerchantOps but the batch is never published, so there is nothing to schedule. Use it to keep MerchantOps in sync with prices managed elsewhere, and set a target when you want the batch delivered downstream. If you need a batch to go out immediately — for testing or an emergency reprice — a Publish Now action lets an approver publish an approved batch without waiting for the effective date. Publish Now on a future-dated batch is allowed. It opens a confirmation you must complete by typing Yes, because publishing early has consequences worth reading:

• The prices go live at the batch’s target immediately, ahead of the effective date.
• Prices publish in MSRP / selling-price pairs, so if a different, already-approved batch holds the matching price for the same product dated on or before this batch’s effective date, that price goes live too.
• The effective date itself is not changed, and the batch will not publish again when that date arrives. If the prices change in the meantime, use Republish.

Publish Now is genuinely unavailable in three cases: the batch has no publishing target, a publish is already in flight, or the batch is waiting on a linked catalog batch. It also covers recovery — a batch whose publish failed or only partly succeeded can be published again from the same button. A publish that never finishes reporting is the awkward case: the batch stays in its publishing state, so it reads as “already in flight” and Publish Now stays blocked. An approver can unstick it by resetting the publish (POST /api/pricing/batches/{key}/reset-publishing — there is no button for this on the pricing batch page yet). The reset force-finalizes the batch to partial or failed, and Publish Now then re-drives it. See resetting a stuck pricing publish for the guards and what each result means.

​

Waiting on a catalog batch

A price batch can be linked to a catalog batch it must wait for, using the catalog-batch dependency picker on the batch detail page. While the link is in place, the price batch will not publish — not automatically on its effective date, and not through Publish Now, which is blocked until the linked catalog batch has published. This keeps a price change from going out ahead of the catalog change it depends on. Where prices are published (the connector, target, and environment) is covered in the Publishing section.

​

Promote to the next environment

Once a batch has fully published, you can promote it to another target environment — typically from QA to production — instead of rebuilding the same set of prices by hand. Promotion is available to anyone who can edit pricing. Promotion creates a new draft batch linked to the source. That child does not copy the prices: it references the source’s price records, and the values are read again at the moment the child publishes. Anything you corrected in place after the QA publish therefore goes to production automatically — you do not re-promote to pick up a fix. The child is an ordinary batch from there on. It starts in draft, and you give it an effective date, submit it for review, approve it, and let it publish or push it with Publish Now. The two batches are independent: cancelling the source does not cancel a batch promoted from it, and the batch detail page shows the link in both directions so you can see the chain. Promotion is refused when the source has not fully published, when the destination is the same target and environment the batch already published to, or when no enabled integration matches the destination.

​

Republish

Republish re-delivers a batch that has already published — the action to use after correcting products, variants, or prices that the target got wrong. It is gated on approval permission, the same as Publish Now. Republish re-drives the whole batch, not just the parts that failed. Every record in the batch’s dispatch list is sent again and the progress counters restart, so the publish status view counts the new run from zero. Republish covers batches that already published successfully. If a publish failed outright or only partly succeeded, use Publish Now instead.

​

Publish column

The batch’s Price Records table has a Publish column showing each row’s publish pill for the batch’s target. A SKU row shows one pill. Style and color rows roll their SKUs up into one pill with a count (for example “VTEX QA · 1/2”): it reads as a warning when only some SKUs published, as failed when none did, and as scheduled while the batch is approved with an effective date still ahead. A batch with no publishing target shows no pill. Hover a pill for the publish details. The batch’s Publish Status card counts only the publishes this batch made. After a promotion, the source batch’s card no longer includes the publishes its promoted child later made to the next environment on the same records, and the child’s card counts its own publishes.

​

Activity history

Every batch carries an Activity history card that records each step in order: created, submitted, approved, rejected, cancelled, publish started, published (with the record counts), partially published, publish failed, promoted, republished, and exported. A publish that had to be force-finalized adds its own entry, as does a manual reset of a stuck publish. Each entry names the member who took the action, its exact date and time (the relative time is on hover), and, for publishing entries, the target and environment.

• Job links. An entry that started a job, such as Publish started, links to that job.
• Scheduled publishes are logged. A publish that started automatically on the batch’s effective date writes its own Publish started entry, shown as scheduled · approved by the member who approved the batch.
• Promotion is linked both ways. The source batch’s Promoted entry links to the new batch, and the new batch’s Promoted from entry links back to the source.

The log is append-only, so a batch that was published, corrected, republished, and then promoted shows all four events rather than only the most recent one.