Catalog approval workflows: who reviews what before publishing

The problem: “where is this product at?”

In a large catalog, a product record passes through many hands: the supplier captures it, purchasing reviews the cost, master data assigns the codes, content writes the description, e-commerce publishes it. When that path lives in emails and spreadsheets, the most common question of the week is “where is this product at?”, and nobody can answer it without investigating.

An approval workflow makes that path visible.

The pieces of a workflow

• Lanes: one for each participant. The supplier, each internal team and the systems, such as the ERP or the store.
• Steps: what each lane has to do, in order, with clear dependencies: a step starts when the previous ones are done.
• Rules: when a step counts as done. Ideally it is met by data, not by a checkbox someone forgets to tick: “has an ERP code”, “the description is published”, “the channel has everything it requires”.
• Owners: each step has someone responsible.

Review before publishing

The step that matters most is the last one before the buyer sees the record. A clear review —someone approves or sends it back with a written reason— keeps a made-up figure or a wrong photo from going out. What matters is that the reason is written next to the record, not in an email.

Comments and tasks where the product is

Much of a workflow's back-and-forth is questions: “is this the right material?”, “who has the packaging photo?”. When those questions live on the product record itself, with mentions for the person who should answer and tasks with due dates, the context is not lost and the next person who opens the product sees the whole story.

See the whole catalog at a glance

Besides each product's journey, the team needs to see the whole picture:

• how many products are in each step;
• which ones are taking longer than expected;
• where a specific SKU is when someone asks.

That board is what turns the workflow into a management tool and not just a diagram.

Common mistakes

1. Steps marked by hand that nobody marks: the workflow says the product is stuck when it has already moved on.
2. Too many steps for small changes: fixing a comma should not go through five approvals.
3. One workflow for everything: a new product and a price update don't follow the same path.
4. No owner: a step owned by “everyone” is owned by no one.

What to measure

A workflow improves with a few numbers, always measured the same way:

• How long each step takes, on average and in the slowest cases.
• How many products are stuck and in which step.
• How often a product is sent back and for what reason.

If one step concentrates the waiting, that is next week's work: more people, a clearer rule or a step that is not needed.

How Bruxel handles it

In Bruxel a flow is the map of a product's path through your organization, with a lane for each participant —your supplier, your teams and your systems— and steps that complete themselves when their rule is met: a flag on the record, a field with a value, the description published in every language or the supplier's submission approved. Each product has its journey and the board shows how many are in each step; the flows guide explains it. Comments with mentions and tasks live on the record, and the staged workflow with several teams use case shows it on video.

Where to start

Draw the path a new product follows today, even on paper: who touches it and in what order. Mark where it gets stuck most often. That point is the first step worth turning into a clear rule with an owner.