One region, one channel, and a configurator stays clean. Add a few of each – different pricing, different discount ceilings, different compliance rules per market – and it turns into hundreds of rules where changing one discount cap means shipping a release.
The pain isn't the rule count. It's that in a rule-based model, every policy change is a developer's problem. In CML, it can be a single record edit. This article is about how to build multi-region, multi-channel logic so the business can change it without waiting on a deployment.
Before reaching for CML, it helps to name the four axes that make global selling hard to configure. Each one is manageable alone. Together they compound.
Model these as region and channel domains (and be deliberate about how you bound those domains), and the shape of the problem becomes clear: it is a matrix, and it grows on every axis at once.
A rule-based (procedural) approach encodes each dependency as an explicit instruction:
If channel = Direct and product = A, then max discount = 0%
If channel = Distributor and product = A, then max discount = 15%
If region = EU and product = B, then require tax treatment X
...
This reads cleanly for the first dozen rules. The trouble is the arithmetic. The number of rules you have to author trends toward products × channels × regions – and each one you add is a place where order matters, where two rules can quietly contradict each other, and where a future edit means finding every rule that touched the same product.
At enterprise scale this becomes thousands of individual rules, and the performance cost of evaluating them climbs alongside the maintenance cost.
The deeper issue is conceptual. A procedural rule describes a step to take. But “a distributor may not exceed 15% on this product” is not a step – it is a fact that must remain true no matter what order the user makes selections in. Encoding facts as steps is what forces you to write, and re-write, one rule per path through the configuration.
CML takes the opposite stance. Instead of listing the steps, you declare the constraints – the conditions that a valid configuration must satisfy – and the constraint engine resolves a valid result on its own, regardless of selection order.
⮕ Rule-based configuration = "if-then."
⮕ Constraint-based configuration = "these conditions must always remain true."
That sounds subtle, but in multi-channel and multi-region organizations, it changes everything.
Apply it to the four axes above and the payoff shows:
You are no longer enumerating combinations. You are describing the boundary of what is allowed, and letting the solver stay inside it. That is why a constraint model absorbs a new region or channel far more gracefully than a rule set does: the structure does not multiply, only the data behind it does.
There is one prerequisite for any of this to work. The model has to know which region and which channel it is configuring for. That information lives on the quote header (the Sales Transaction), not inside the product itself.
CML reaches it through external variables. The contextPath annotation maps a field on the Sales Transaction to a variable the model can read:
@(contextPath='SalesTransaction.Channel__c')
extern string Channel;
@(contextPath='SalesTransaction.Region__c')
extern string Region;
With channel and region available as an ordinary CML variable, every constraint in the model can branch on them without the value being duplicated onto each product. This is the seam between the deal and the logic – get it in place first, and the rest of the model has something to stand on.
A note on setup: contextPath variables depend on the corresponding attributes being tagged and mapped in your Context Definition.
If the mapping is missing, the variable reads as empty and every constraint that relies on it silently does nothing – one of the harder failure modes to spot. Confirm the context mapping before debugging the constraints themselves.
The models below are independent examples – each one stands on its own. Both use the same three pieces: an external variable that carries the deal context, a Salesforce object that holds the policy, and a table constraint that matches one against the other. Only the data differs.
Here is the pattern that ties it together. The requirement: across Direct, Distributor, and Reseller channels, each product carries a different maximum discount, and exceeding it should trigger a warning.
Written as procedural rules, this is products × channels explicit entries. In CML, the caps live in data, and the model reads them.
Store the caps in a custom object – Discount_Cap__c, with a lookup to the product (Product__c), a channel picklist (Channel__c), and a max-discount number (MaxDiscount__c). Each product type then reads its cap straight from that object through a table constraint:
@(contextPath='SalesTransaction.Channel__c')
extern string Channel;
type BaseProduct {
@(tagName = "Product")
string productId;
@(tagName = "ItemDiscountPercentage")
double(2) discount;
double(2) maxDiscount = [0..100];
constraint( table(productId,maxDiscount,Channel,SalesforceTable("Discount_Cap__c","Product__c, MaxDiscount__c, Channel__c")) );
message(discount > maxDiscount, "Approval required", "Warning");
}
type Laptop : BaseProduct;
type Mouse : BaseProduct;
Three moving parts do the work:
.png)
The behaviour is easiest to see side by side. Same product, same discount percentage, two channels:
1. Distributor channel
.png)
2. Direct channel
.png)
⚠️ Note: When using the direct channel, applying the same discounts does not trigger a warning message.
The data side is the whole game. When the commercial team raises a product's distributor cap, they edit one record in Discount_Cap__c. No CML change, no redeploy – just a model reactivation to refresh the cached data.
If you want the full breakdown of SalesforceTable syntax, permissions, and its failure modes, we cover it in depth in our guide to Table Constraints in CML.
To surface the warning itself when a cap is exceeded, pair the constraint with a message rule so the user sees a clear explanation rather than a silent block.
The requirement: across US, EU and APAC regions, a Laptop product has different valid combinations of attributes.
Valid combinations live in a custom object ProductVariant__c.
@(contextPath='SalesTransaction.Region__c')
extern string Region;
type Laptop {
@(defaultValue = "13 Inch")
string Screen_Size = ["27 Inch", "13 Inch", "24 Inch", "15 Inch"];
@(defaultValue = "1080p Built-in Display")
string Display = ["2k Built-in Display", "1080p Built-in Display", "4k Built-in Display"];
constraint validCombinations(
table(
Region, Display, Screen_Size,
SalesforceTable("ProductVariant__c",
"Region__c, Display__c, Screen_Size__c")
),
"This combination of display size and screen is not available in the %s region.", Region
);
}
.png)
Three moving parts again:
Region, Display, and Screen_Size together against the records in ProductVariant__c, so a combination is valid only when a row for that region allows it.%s placeholder drops in the active region, so a rep sees exactly why the pairing is unavailable rather than a generic rejection.Compliance works the same way: the forbidden product-tax combinations live as records, and the constraint reads them exactly as it reads variants. Different data, identical pattern.
Strip away the syntax and one architectural rule remains: separate what changes often from what changes rarely.
Rule-based models are rarely chosen and then regretted – teams arrive at them one reasonable step at a time. The catch is that the system never stops changing, and on a rule-based model each new channel or region costs more to add than the last. A constraint model moves that cost to the start: more thought up front, far less every time the business changes its mind.
A region attribute set at the bundle level often has to reach products several levels down. How you propagate that value across the model is its own design decision worth getting right, but the principle holds throughout: keep the volatile data outside the logic.
Get this boundary wrong and even a trivial change – onboarding one new reseller channel – turns into a code change, a review, and a deployment. Get it right, and the same change is a row in an object. That difference, repeated across a global rollout, is the difference between a configurator the business can operate and one it has to queue against engineering.
Multi-region, multi-channel selling does not have to mean an unmaintainable configurator.
The complexity is real, but most of it is data complexity – prices, caps, variant lists that shift with the business – wearing the costume of logic complexity. CML lets you take that costume off: declare the structure once, read the deal context through external variables, and let the volatile values live where the business can reach them.
If your configurator has reached the stage where every policy tweak means a developer and a deployment, that is usually a sign the data-versus-logic boundary drifted. It is a fixable pattern, and often a smaller fix than it looks. If that sounds familiar, the Veloce team is happy to take a look.
Do I need separate constraint models per region?
Usually no. A single model reading region as an external variable can scope regional logic through table constraints, which keeps one model to maintain rather than several drifting copies. Separate models are worth considering only when regional catalogs diverge so heavily that they share almost no structure.
How does the model know the channel and region of a quote?
Through external variables. The contextPath annotation maps a Sales Transaction field to a CML variable, provided the field is tagged and mapped in your Context Definition. Without that mapping the variable reads empty.
Where should compliance rules live – in CML or in data?
The rule (this combination is forbidden in this country) belongs in CML as a constraint. The list it checks against belongs in data via SalesforceTable if it changes often. Stable, engineering-owned restrictions can stay hardcoded.
Does updating a discount cap in Salesforce require a deployment?
No deployment, but yes to a model reactivation. Table data is cached at activation, so record changes take effect only after the model is reactivated.
Is this hard to learn coming from CPQ?
The mental shift from procedural rules to declarative constraints is the real learning curve – it is what makes CML a genuinely different skill, more than the syntax itself.
.png)