How ordering is configured

An ordering configuration uses six kinds of elements in LUMA. It sits on top of the deployment’s existing domain tree, sites, and frontend, and takes its currencies from the console’s Currencies module.

The route sits at the centre of the configuration, joining one process to one supplier group. It takes its order type from the process. A process only applies to an asset when a transform lists the asset’s resource type and references a route that uses the process. In the same way, a rate only applies to the resource types it lists, and they must match the ones the transform lists.

The route also decides which order each item joins. Each draft order belongs to one route, so an item added through a route that already has a draft order joins that order instead of starting a new one. The route also controls delivery: the Order Delivery Address dropdown only appears when the route carries location metadata, as described in Add an orders asset list page.

Accounts connect through the end user rather than through the route. An end user can pay for an order from any account whose audience includes them.

Keeping these links in the route and the transform, rather than in the process, makes each element reusable. A transform can list several resource types and reference several routes, so one process can govern orders for several kinds of asset. One kind of asset can offer several routes, each with its own workflow and supplier rates, which appear as separate options under Add to cart. Changing a price only means changing a rate, without touching the workflow or the transform.

Each element produces part of the end user’s journey, so a gap in the configuration appears at a predictable point.

If something in the journey is missing, the Where it comes from column names the element responsible. For the most common gaps and how to fix them, refer to Troubleshooting ordering setup.

You can configure ordering against the parent Order, Resource, and Account types, and every child type inherits the configuration. Configuring against child types keeps ordering limited to the asset types you choose, and lets different asset types follow different processes or prices.

The order type and account type sit in the system domain, while the resource type sits in the client domain alongside the assets it describes.

The process is one of the first elements you create, but the workflow it governs is the last thing the end user meets, after they select Place Order.

The one ordering-specific requirement is that you set up the process against an order type.

Everything else in the process is a choice for your deployment. A process needs at least an initiator role, a stage, and a transition before you can enable it. From there, the workflow can be as simple or as strict as the client needs:

Stages take their states from the order type, so the order type’s states should match the stages you plan. The last stage uses the Complete operation, which ends the workflow. Transitions control both which stages an order can move to next and which roles can move it, so they carry the approval rules.

A rate is either fixed or variable, and the type changes what the rate’s volumes mean.

With a fixed rate, each volume is an option the end user can pick. The end user chooses a quantity from a dropdown of the configured volumes, so every order is for one of those quantities.

With a variable rate, each volume is a price break. The end user can order any quantity, adjusting it one unit at a time. The system applies the unit price of the highest break the quantity reaches.

The type also decides delivery: only a variable-rate item can be split across several delivery addresses.

Fixed rates suit items sold in set pack sizes. Variable rates suit items where the quantity is open but bulk pricing applies.

The transform’s engine decides what happens to an asset when an end user adds it to an order. For standard assets, the Passthru engine attaches the asset unaltered. For adaptations, the Entropy engine renders the template first and attaches the result.

The transform’s Kind decides which types it works with. A Derivative transform works with resource types, and an Output transform works with template types.

A transform also has input types and an output type. The input types are the asset types that can be ordered, and the output type is the type the transform produces. A Passthru transform doesn’t change the asset, so its output type must be the asset’s resource type or one of its parents. Create the transform shows where each one is set.

The ordering configuration follows a clear chain, from the asset an end user selects to the account they commit the order to.

An asset’s resource type decides whether ordering is available for it. A transform that lists the resource type adds the asset to an order, through one or more routes. Each route joins a process, which sets the approval workflow, to a supplier group, whose rates set the price and quantities. The end user then commits the order to an account whose audience includes them.

Understanding this chain clarifies the order of configuration: the types first, then the process and the supplier group, then the route that joins them, then the transform that links the route to the asset, and finally the accounts.