Pipeline Configuration¶

An order moves through a pipeline — a chain of processors that validate it, take payment, update inventory, send emails and so on. Pipelines are edited per site under Settings › Pipelines.

Where a pipeline comes from¶

Three things can shape a pipeline, in order of precedence:

1. The site's own definition — what you build in the editor. When present, it decides which processors run and in what order.
2. The legacy processor configuration — the older state-machine records, used when a site has no definition of its own.
3. The platform defaults — the @PipelineStep annotations in the code.

The annotations always remain the catalogue of what a pipeline can contain; the editor chooses from it. A site that has never touched a pipeline follows the platform defaults and keeps following them as they change, which is what most sites should do.

Editing a pipeline¶

Open a pipeline and you get its current chain, seeded from whatever is running today — so a first edit starts from reality rather than a blank page.

• Drag a step to change when it runs. Steps run top to bottom.
• Untick a step to switch it off without removing it.
• Add a step from the processors this pipeline supports but is not currently using.
• Save applies the change immediately; the next order uses it.

Each step shows what it does, so the decision to remove one can be made on more than its name.

Guard rails¶

Some steps a pipeline does not work without — the one that moves an order out of the basket state, for instance. Removing or disabling one of those is refused outright, because the result is not a differently-behaving checkout but a broken one.

A step naming a processor this deployment does not have is a warning rather than an error: that can legitimately happen mid-rollout, and refusing the save would strand the whole definition over one step. Such steps are skipped when the pipeline runs, and logged.

Reset to defaults¶

Reset to defaults discards the site's version and puts the pipeline back to the platform defaults. This is the way out if a site has configured itself into a checkout that no longer works.

Importing the legacy configuration¶

Sites configured before the editor existed have their pipelines as a state machine: each record says which incoming status it reacts to, and the status a processor returns decides what runs next.

Import from legacy configuration converts that into an editable definition. Most real configurations are a straight line written in graph notation and convert cleanly.

A genuinely branching configuration — where two processors react to the same status, so what runs next depends on which one returned it — has no linear equivalent. The import refuses rather than flattening it into something that looks right and behaves differently; rebuild it from the platform defaults instead.

Performance¶

The site's definition is cached per site and pipeline, including the fact that a site has no definition. Editing a pipeline evicts that entry, so a change takes effect on the next order rather than the next restart.