Enforce Product Quantity

PeakCommerce can cap the total number of units an order may contain, using a seat limit policy. Read the limits of that mechanism before you design around it — it is deliberately narrow, and it is not a general per-product quantity constraint.

What the seat limit policy does

Create a policy of type seat limit and give it a maximum. When an order is created or updated, a seat change is made, or a cart reaches checkout, the engine adds up the quantities across all items in the request and blocks the operation if the total exceeds the maximum.

Because it runs in the Policy Engine, it holds on every surface — self-service checkout, a CSR-assisted change, and anything driven through the Agent API alike. Blocked operations are recorded in the audit log.

What it does not do

This is where teams get caught out. The seat limit is:

• Tenant-wide. It cannot be scoped to a product, plan, or audience. There is one ceiling and it applies to every order.

• A total, not a per-line limit. It sums quantities across the whole request. It cannot say "at most 5 of product A".

• A maximum only. There is no minimum quantity, and no step or increment constraint.

There is no per-product minimum or maximum quantity setting anywhere in the catalog. If you have seen minQuantity and maxQuantity on a pricing tier, those are the boundaries of a price band — they select which price applies at a given volume. They do not restrict what a customer is allowed to enter. Likewise, a charge's default quantity pre-populates the field; it does not constrain it.

Achieving the intent another way

If you need a genuine per-product constraint today, the practical options are:

• A response gate on the commerce action that commits the order, testing the quantity and failing with a message you write. See Raise an error.

• A plan dependency, when the requirement is really that one quantity should track another rather than be bounded. See Match quantity across plans.

• Product set curation, when the goal is to stop a combination being assembled at all. See Plan selection and deactivation.

Gotchas

• Only block is enforced. Policies offer several enforcement actions, but require-approval, show-warning, and allow-freely are stored and displayed without changing runtime behaviour. A policy that must actually stop something has to be set to block.

• Evaluation stops at the first block, so if several policies would fail, the customer sees one reason rather than a combined list.

Related

• Raise an error — custom messages when a constraint fails.

• Logic & Rules overview — which engine owns which job.