Skip to main content
Run Mercur’s review workflows to decide on a proposed product from a custom route, a subscriber, or a scheduled job. Each one checks the status, records who reviewed the product, and emits an event.

Before you begin

You need the following in place:
  • A product in proposed status, such as a store submission
  • The id of the operator or system acting, for the audit record
The workflows fail with a NOT_ALLOWED error for any product that isn’t proposed.

Review a product

1

Publish it

confirmProductsWorkflow publishes one or more products in a single run. internal_note is stored on each audit record for operators.
src/api/admin/reviews/publish/route.ts
If any product isn’t proposed, the run fails and none of them change.
2

Or reject it

rejectProductWorkflow handles one product. message is stored as the change’s external_note, the note the store can read.
The product moves to rejected and leaves the store’s product list.
3

Or ask for a revision

requestProductChangeWorkflow keeps the product proposed and records a CHANGE_REQUESTED action with your message.
The product stays in the review queue, and your message is stored as the change’s external_note.

Run a review from a subscriber

Review products automatically by running a workflow when they’re created. This subscriber publishes products from one trusted store.
src/subscribers/auto-publish-trusted.ts
The handler reads the PRODUCT_ADD record to find the submitter, then publishes. product.created fires twice for each product created through Mercur’s workflow, so the second run fails the proposed check. Catch that error, or check the status first.

React to the outcome with hooks

Each review workflow exposes a hook that runs after the status change. Use it for side effects that must happen inside the same run.
src/workflows/hooks/product-rejected.ts
For work that can run later, subscribe to product.published, product.rejected, or product.change-requested instead.

Next steps