Winter ’25 Release: Converting Business Rules Engine Rules into CML
If you loved the Constraint Modeling Language (CML) introduced in Summer ’25, you’re going to love what Salesforce has done next.
In Winter ’25, Salesforce Revenue Cloud Advanced has quietly unlocked one of the most powerful bridges yet — the ability to convert rules created in the Business Rules Engine (BRE) into CML code.
This update is a next step for anyone who’s been building complex product logic, guided selling flows, or constraint models. It marks the true convergence of the Business Rules Engine and the Constraint Rules Engine under the Advanced Configurator framework.
What’s New
Until now, admins and architects could build product logic in BRE — defining defaults, dependencies, and validations in an intuitive UI.
But the real power of CML lies in expressiveness and integration — the ability to write constraint logic programmatically, interlink it with context definitions, and drive real-time configurator behavior.
With Winter ’25, Salesforce now lets you:
- Export your BRE rules as JSON data.
- Convert them into CML syntax using an npm-based CLI plugin.
- Import those CML files directly into the Constraint Rules Engine.
In other words — you can now migrate your BRE logic into a full-blown CML-based constraint model.
How It Works (Step-by-Step)
You’ll need two npm plugins to make this magic happen:
@salesforce/plugin-data@salesforce/plugin-bre-to-cml
Here’s the workflow:
1️. Export Rules from BRE
Use the Salesforce CLI to export your BRE rules into a JSON file:
sf data export bulk --target-org breSourceOrg --sobject ProductConfigurationRule__c --output-dir data
This gives you a file like:data/ProductConfigurationRules.json
2️. Convert BRE Rules to CML
Now use the converter plugin to transform your JSON into CML code:
sf cml convert prod-cfg-rules --pcr-file data/ProductConfigurationRules.json --cml-api MY_TEST --workspace-dir data --target-org breMigOrg
This creates:
- A CML Expression file
- An Association file
These files contain the converted rules ready for import into your target org.
3️. Import into Constraint Rules Engine
Finally, bring the CML logic into your target org using:
sf cml import as-expression-set --cml-api MY_TEST --context-definition PricingTransactionCD2 --workspace-dir data --target-org tgtOrg
Once imported, your rules become native CML expressions — ready to interact with constraint models, decision sets, and context definitions.
What Changes in CML vs BRE
While the conversion is powerful, there are some key differences to remember:
| Behavior | Business Rules Engine | Constraint Modeling Language |
|---|---|---|
| Conditional Defaults | ✅ Supported | ❌ Not supported |
| Auto-add Multiple Instances | ✅ Adds multiple | ⚠️ Only adds one |
| Message Duration | Event-based | Persists as long as condition is true |
So when you migrate, review how your logic behaves at runtime — particularly where defaulting and auto-add rules are used.
Why This Matters
This feature signals Salesforce’s deeper vision:
To make Constraint Rules Engine (and CML) the single, unified home for configuration intelligence.
It lets solution architects move away from disjointed rule engines — toward a structured, code-friendly, version-controllable model.
And if you’ve already started experimenting with Advanced Configurator, this integration makes your logic portable, transparent, and easier to evolve.
Permissions & Editions
You’ll need:
- Enterprise, Unlimited, or Developer Edition
- Product Configurator enabled
- Product Configuration Constraints Designer permission set
Final Thoughts
The introduction of Constraint Modeling Language was the turning point in Summer ’25 — and this Winter ’25 enhancement makes it truly production-ready.
As Salesforce continues to blend the worlds of BRE, CML, and Advanced Configurator, architects can expect a future where every configuration rule is modular, portable, and fully context-aware.
