Skip to main content
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.
1

Assemble a draft

Create the batch (or let mass-create make one for you) and add price records. Set a name and the effective date the prices should go live.
2

Submit for review

Move the draft to pending_approval. MerchantOps records who submitted it and when.
3

Approve or decline

A reviewer with approval permission approves the batch, moving it to approved. Approval requires the batch to be in pending_approval — not draft. To decline a submitted batch, cancel it, which preserves its records. Reject is a separate draft-stage action that throws away the draft prices before review.
4

Publish on the effective date

Once approved, a batch with a publishing target publishes automatically when its effective date arrives — no further action is needed, unless it is waiting on a linked catalog batch (see below). A batch approved without a target activates its prices in MerchantOps but is never published.
Rejecting a batch discards its draft prices. Cancelling withdraws a batch that has not started publishing. A batch that is already publishing or has published cannot be cancelled or deleted.

​
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.
Exporting an approved batch removes it from publishing — permanently. Exporting from the batch — the Export action on the batch detail page, which downloads the batch’s prices as a spreadsheet — sets the batch’s status to exported. Nothing publishes an exported batch: the scheduler, Publish Now, and Republish all act only on approved batches, and there is no action that returns an exported batch to approved. The batch cannot be edited or re-submitted for review either, and today nothing warns you before the export.There is no “export it first” workaround: the batch’s Export action only appears once the batch is approved, which is exactly the state the export destroys. If you want a spreadsheet of prices you also intend to publish, export from the price-records pages instead — that export leaves the batch alone — and use the batch’s own Export only when you have decided the batch will not be published.The prices themselves are not lost. Approval already made them active in MerchantOps, so what you lose is the delivery. To recover it, build a new batch that references those same price records (select the SKUs on a product’s price-records page and publish them to a target), and take that batch through review and approval.
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.

​
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.
For a batch that references records — a promoted child, or one built by publishing selected SKUs to a target — the dispatch list is resolved fresh at publish time with no status filter. That is what lets in-place corrections ride along, and it also means a record superseded by a newer price since the batch was built still ships. Check the records list before republishing an older batch.
Republish covers batches that already published successfully. If a publish failed outright or only partly succeeded, use Publish Now instead.

​
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. Each entry names the member who took the action — or the scheduler, when the publish was automatic — the time, and, for publishing entries, the target and environment. 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.

Publishing overview

How batches are delivered to external systems.

MAP policies

Generate price changes per colorway from an active MAP policy.