Skip to main content

Lifecycle stages

Decide when products go live Stages are gates, not labels

Give every product a stage, attach the field checks that stage demands, and let products move up only when they actually meet them.

  • 2 default stages, unlimited custom
  • 5 requirement operators
  • Bulk stage changes

Key features

  • Name your own stages

    Start from Not Reviewed and Reviewed, then add the stages your team really uses: content ready, photography done, QA passed.

  • Attach requirements to a stage

    A requirement is a field check: description longer than 100 characters, EAN not empty, price greater than zero. Five operators cover it.

  • Advance without chasing people

    Auto-advance promotes a product the moment its stage requirements pass, so nobody re-reads the list looking for what changed.

Why stages

An unenforced status is just a rumour

Everyone agrees a product should be checked before it publishes. Stages are where that agreement stops depending on memory.

  • See where the catalog is stuck

    Filter by stage and the answer is a number: 340 products waiting on photography, 22 waiting on a reviewer.

    Result: the standup question is answered before it is asked.

  • Hand over without a spreadsheet

    A product leaving one stage is the signal for the next team, so the handover is the stage change rather than a message.

    Result: no parallel list of what is ready for whom.

  • Keep half-finished products off the channels

    Exports read the stage. A product that has not reached the publishing stage is not in the feed, no matter who edited it.

    Result: an unfinished draft cannot leak into a marketplace.

The path

The same four steps for every product

These are the default stages. Rename them, add your own, or cut them down to two. The mechanism is the same.

  1. 01

    Draft

    New products land here, from an import, a scrape or by hand. They are visible to your team only and appear on no sales channel, however unfinished they are.

    The product exists and nothing can publish it yet.

  2. 02

    Review

    Once the draft stage's requirements pass, the product moves to review, one at a time or a whole selection in a bulk edit. The reviewer sees which fields changed and who changed them.

    Somebody named is now looking at it.

  3. 03

    Approved

    The stage's manual checklist has to be ticked off: image quality, brand check, the legal line on a regulated product, and everything else a rule cannot measure.

    The checks a person owns are recorded, with their name.

  4. 04

    Published

    The product syncs to the channels it belongs to. An edit that breaks a requirement afterwards drops it back to the previous stage instead of quietly staying live.

    The catalog and the storefront say the same thing.

Automatic movement

Most stage changes need no person

Requirements are checked continuously, so a product moves the moment it qualifies rather than the next time somebody looks.

  • Auto-advance on the requirements you set

    Turn it on per stage. As soon as every requirement on that stage passes, the product moves up; a stage with a manual checklist waits for the tick.

  • Automations on entering or leaving a stage

    A stage change is a trigger: enrich the description when a product enters Draft, notify the channel manager when it reaches Approved, start an export when it is Published.

  • Bulk changes when you do want to intervene

    Select a filtered set and move it in one edit. Products that fail the target stage's requirements are reported instead of moved.

The process tracker shows what is running right now: an auto-advance sweep, an enrichment triggered by a stage change, an export.

In practice

Three pipelines teams actually run

The stages differ per team; what they have in common is that publishing is the last gate, not the first action.

  • New-supplier intake

    Imported products sit in Draft until the required attributes, images and an EAN exist, then move to review on their own.

  • Seasonal relaunch

    Last season's products are moved back to Draft in bulk, re-enriched, and only re-published once the new copy and pricing pass.

  • Marketplace expansion

    A separate stage per marketplace holds products until that channel's required fields are filled, so one channel does not block another.

FAQs

Lifecycle questions

How stages, requirements and checklists decide when a product may publish.

Still have questions?

Can't find the answer you're looking for? Please get in touch with our team.

Contact Support

Two: Not Reviewed and Reviewed. Rename them, add as many as your workflow needs such as Draft, Content Ready, QA Approved and Published, or leave them as they are. There is no fixed set you have to adopt.

A requirement is a check on a field, using equals, contains, starts with, greater than or is empty. A product cannot enter the stage until every requirement on it passes. Requirements read your own attributes, so they can be as specific as your data model is.

It moves a product to the next stage the moment every requirement on that stage passes, instead of waiting for someone to re-check the list. You enable it per stage, and a stage with a manual checklist still waits for the tick, because auto-advance never skips a human step.

Yes, for the checks a rule cannot make: image quality, brand tone, a legal review. Team members tick items off and their name is recorded against each one. A checklist item cannot be filled by an automation, which is the point of it.

Yes. Entering or leaving a stage is an automation trigger, so you can enrich on entering Draft, notify a channel on reaching Approved, or start an export on Published. The automation runs after the stage change, not instead of it.

Put a gate before your storefront

Set a requirement on the stage you already have, turn auto-advance on, and see how much of your catalog would move by itself.