Flows and journeys

Where each product stands between your supplier, your teams and your systems, and what happened at each step.

What a flow is

A flow is the map of the path a product follows in your organization, for example from the moment the supplier submits it until it is ready for your store. It has one lane for each party involved and steps that depend on one another: a step's turn comes when the steps it depends on are done.

• The supplier, who fills in and submits the product from their portal.
• Your teams inside Bruxel, such as Purchasing, Master data or Content, each with its own part of the product record.
• Your company's systems, such as SAP, your warehouse or your store.

A flow can have an entry rule: a product enters as soon as it meets it, for example when its supplier's submission is approved; without a rule, every product in the catalog enters. The same product can be in more than one flow at a time.

When a step counts as done

Each step has a rule, and Bruxel counts the step as done as soon as the rule is met. The rule looks at the product record or at its supplier's submission:

• A Yes/No flag on the product record is set to Yes, such as «Ready for review».
• A field has a value, such as the code your ERP assigned to the product.
• The description is published in every output language.
• The product has everything a channel asks for, such as your store's.
• The supplier sent the submission, or their submission was approved.

A step can also apply only to some products: depending on their category, whether they are a variant or the value of a field. For the rest it shows «Not applicable», and that does not hold up the steps that follow.

Your systems' steps

A step in a system's lane, such as SAP, your warehouse or your store, can be marked done by what happens outside, in three ways:

• The system reports an event about the product to Bruxel through the public API, for example that it created the material.
• Bruxel notifies the system of a change to the product (a webhook) and the system answers that it received it.
• The system reads the product record or writes data to it with its public API key. Checking the product's journey or history doesn't count.

The latest one decides: if it went well, the step is done; if it went wrong (a reported error, a notification that wasn't delivered, a rejected call), the step shows an error and the journey stops until a good one arrives.

For Bruxel to know which notification and which call belong to each system, register it under Account → General → Connected systems with its code (the one that names its lane in the flow), the key it calls with and the endpoint Bruxel notifies. A call from a key that isn't linked to any system counts by the key's name: a key named “SAP” belongs to sap, unless sap already has its own key. Each notification and each call keeps the system it had at that moment: changing a link doesn't move what already happened.

The states of a step

Each step on the map says which state it is in:

• Pending: its turn hasn't come yet, because a step it depends on is still missing.
• In progress: it's its turn, because the steps it depends on are done or not applicable.
• Done: its rule is met.
• Not applicable: the step is only for some products, and this one isn't one of them.
• Error: the latest thing the system reported, the latest notification or the latest call went wrong. It clears only when a good one arrives.

There are also two warnings: a «late» step has been in progress longer than its expected time, and an «out of order» one was met before a step it depends on; the step's detail says so. Neither one stops the journey: they are there so you can see them.

If a rule stops being met, for example because someone set a flag back to No, the step is no longer done and the log records it.

Where to see it

In the «Journey» tab of each product record. It only appears in organizations with at least one active flow, and your whole team sees it, viewers included; the supplier does not.

At the top is the map: the lanes with their steps and where the product stands. With «Replay the journey», or by moving the slider, the map goes back to how it was at each moment, event by event, up to today.

When you pick a step you see its detail: the rule that counts it as done, in plain words, its expected time and how long it has been like that. The log tells what happened in that step or in the whole journey: what changed, who caused it and in which version of the product record. What was already like that when the product entered the flow is marked separately, so you don't mistake it for a change made today.

If a step of your team is done with its Yes/No flag and you can write it, its detail offers “Mark as done”: it sets the flag to Yes on the product, with your name in the history, and the journey updates right away. It only shows up while the step is in progress, and it doesn’t show up if the flag is protected and you aren’t an administrator, if it belongs to a group outside your write scope or if the system sets it.

A flow's board

Under My products › Flows you'll find each of your organization's flows with its board. It appears if your organization has any flow that isn't a draft (a paused or archived one keeps its board), and your whole team sees it, viewers included, except people whose access is limited to part of the catalog and the supplier: the board covers the whole organization.

• In progress: the products that are in the flow and haven't finished it, including the stopped ones.
• Stopped by an error: of the ones in progress, those with a step in error.
• Late: the ones that have been at a step longer than its expected time.
• Completed in the last 7 days, and the typical end-to-end time (the median of what finished in 30 days).

Below is the same map as the «Journey» tab, but each step says how many products are there today, with a red bubble with «!» for the ones with an error and an amber one with a clock for the late ones. If steps run in parallel, a product counts at every step it is at, and the board says so.

Click a step to open its list: the products that have been there the longest come first, with their last event, and each one opens its journey. «Open in the catalog» takes that same list to Products, where the «Flow step» filter can be saved as a view; the grid has the same filter.

«How long each step takes» shows the median time each step was in progress over the last 30 days, with the slowest one highlighted. «Where is my SKU?» opens a product's journey by its SKU; from search (⌘K), the «Journey» button next to each product does the same.

Deadlines, notifications and reports

A step with a deadline is late when it has been in progress longer than its deadline. Bruxel checks deadlines every minute in active flows and lets you know in the bell:

• When a system reports an error and a product’s journey stops at a step.
• When a product goes past a step’s deadline: once each time it enters that step.

Notifications are grouped by step: while a step’s notification is still unread, new products are added to it and it moves to the top of the bell; once read, the next one is a new notification. Your team sees them, except people whose access is limited to part of the catalog; they don’t arrive by email, and each one opens the board on that step’s list. An error that was already there when the flow was activated or edited isn’t notified, because the board already counts it; a late step is: on the first run after activating the flow, a notification arrives for each step with products past their deadline.

On the home page, the “Flows” card shows your active flows with how many products are in each, how many stopped and how many are late, those with something stuck first. In Reports, the Team and operations family has “Time per step” (how long each step was in progress in the period: median, p90 and maximum, and how many times it went past its deadline) and “Stuck products” (the ones that are in a step with an error or past its deadline today).

What the supplier sees

On the page of their products, the supplier sees “Your progress”: the steps you gave a name in “How the supplier sees it”, with that name and their status in words.

• “Done on …” once the step is met, with its date.
• “In progress” on the first one still missing, even if the product is stopped at a step they don't see or at one with an error.
• “Pending” on the ones after it. A step that doesn't apply to that product doesn't show up.

In My uploads, the journey of each upload shows the same row over its products, with how many are at each step (“1 of 2”). The supplier doesn't see your lanes, your systems, the unnamed steps, errors or the flow's name, and still doesn't see the “Journey” tab. A flow with no steps named for the supplier shows them nothing.

What was sent and what it answered

The «Journey» tab also shows the notifications Bruxel sent your systems about that product and the calls your systems made through the public API, each with its time, what it answered and how long it took (the 100 most recent). If the product is in a flow, they appear in the log under «Whole journey»; if not, in their own list.

«See what was sent and what it answered» opens the details: operators and up can see them. From there an administrator can resend a notification. The rest of the deliveries and calls are in Webhooks and API Keys, which are administrator screens.

When you pick a step of a system, the log shows that system's notifications, calls and reports next to its changes.

When it updates

When you open the tab, Bruxel recalculates that product's journey right then: what you see is up to date. If someone changes the product record while you have it open, the tab won't notice on its own; use «Refresh».

You don't need to open anything for the journey to move forward: when a product record or its published description changes, Bruxel recalculates it on its own in about a minute, and the log records the time of the change, not the time of the calculation. Changing a channel the flow names (its columns or its language) also recalculates it. When a flow is turned on for products that already had something done, each step carries the time of the change that completed it; if there is no way to know it, the time the flow was turned on.

Designing a flow

An administrator builds flows in “Flows” → “New flow”. You start from a template (the onboarding that arrives through the portal, or the content update) or blank, and edit a list of steps with its form; the map above redraws with every change.

• Lanes say who does each step: the supplier portal, a team with its attribute group or one of your systems.
• For each step you choose which steps it depends on, when it counts as done, when it applies, its deadline and how the supplier sees it. Each rule reads as a sentence below the form; what the form doesn’t cover is written as JSON in “Advanced”.
• “Create this step’s flag”, in a team lane, creates a Yes or No attribute in the team’s group and uses it as the step’s rule.
• “Test with a SKU” tells you where a real product would land with what you have on screen, even unsaved. It writes nothing.
• While you edit, Bruxel checks the flow: dependencies in a circle, lanes without steps, attributes, channels or groups that don’t exist and systems without an endpoint. It also warns about a loose step or a system that isn’t in Connected systems.

“Create draft” saves it without moving any product. “Activate…” first counts how many products would enter and what state each step would be in (in a large catalog, from the first ones it managed to count), and once you confirm, the engine places each product within a minute or two. When a flow is activated or reactivated, Bruxel checks again what it names.

Every “Save” creates a version. In “Versions” you see who saved it and what changed from the previous one; “Load in the editor” brings it into the draft and, when you save it, you go back to it as a new version. If someone else saved the flow while you were editing it, Bruxel doesn’t overwrite their version: it asks you to reload.

Tasks on arrival and notices to your systems

A step can assign a task to someone on the team when a product reaches it (“When a product arrives, assign a task to”, in the designer). It's the usual product task: they get the notice in the bell, it shows up in “My tasks” and, if the step has a deadline, it's due then. If the next step also assigns, the task the flow set moves to that person; a task someone set by hand is never touched.

• Activating or editing a flow doesn't hand out tasks for what was already in each step: only for what arrives afterwards.
• A viewer isn't assigned (they couldn't close it), and someone with scoped access only gets the products they can see.

Your systems find out by webhook: flow.step.ready when there are new products in a step, flow.run.blocked when a journey stops with an error and flow.run.completed when it finishes. They arrive grouped by step or by flow, with a sample, and the system reads the full list with the public API (Developers → Flows and events).

What it doesn't do yet

• Bruxel doesn't ask your systems anything: if a system doesn't report, receive notifications or call with its key, its steps only move with rules on the product record.
• From the journey you don't assign a task by hand: that's done in the catalog or on the product page. A step can assign one on its own when a product arrives.
• The log shows up to the 300 most recent events of each journey; if there are more, it says so.