Skip to main content
Use Mercur to keep a full audit trail of every product change and govern your master data before it changes. Master-data governance depends on knowing who changed what, and reviewing it before it takes effect. The Product Edit domain is that auditable change pipeline. Every edit becomes an immutable, attributed ProductChange record that enters an approval queue, so no change to a shared product is silently written. Each record carries typed actions and a status lifecycle, and the trail records who changed what and who approved it.
Product Edit ≠ product ownership. Products are the shared master catalog, and sellers sell against them through offers. Product Edit governs changes to a product. It never makes a store the owner of one.

​
Key features

  • Immutable audit trail: every edit is an attributed ProductChange that is never rewritten, only appended to and resolved.
  • Typed change actions: each edit is expressed as ProductChangeAction rows such as UPDATE, VARIANT_*, ATTRIBUTE_*, STATUS_CHANGE, or PRODUCT_ADD/DELETE.
  • Approval queue: a change moves pending → confirmed / declined / canceled, each through a dedicated workflow.
  • Deferred application: actions are applied to the product only on confirmation, then marked applied.
  • Auto-confirm: when review is off, staged changes confirm and apply immediately.
  • Revision requests: operators send a submission back to the vendor as a recorded CHANGE_REQUESTED audit action.
  • One active change per product: a product can’t have two pending changes at once.

​
Get started

Learn how the domain fits together:

The change pipeline

The ProductChange record, immutability, and the audit trail.

Change actions

The typed actions that make up a change and their details.

Status & auto-confirm

The status lifecycle, revision requests, and auto-confirm.

​
Examples

Build against the Product Edit domain in your own code:

Edit a product

Stage a product change from server code.

Confirm or decline

Resolve a pending change in code.

Request a revision

Send a submission back to the vendor.

​
Resources

Data models, workflows, service methods, and events for the Product Edit domain:

Data models

The ProductChange and ProductChangeAction entities.

Links

How the Product Edit domain links to other modules.

Workflows

Create, confirm, decline, cancel, and stage workflows.

Service

Module service methods for working with records directly.

Events

Events emitted as changes move through the pipeline.