Salesforce Revenue Cloud Configurators: When and How to Use Each
- Kyle Tan
- 9 hours ago
- 3 min read
If you’ve spent any time inside Salesforce Revenue Cloud, you’ve likely run into it:
Configurations that should work… but don’t.
Rules that used to work… but now conflict.
Sales reps overriding logic just to close deals.
This is where most implementations start to drift—and where the choice between configurator engines becomes critical.
The Two Paths: BRE vs. CML
At a high level, Salesforce gives you two ways to handle product configuration:
Standard Salesforce Configurator (BRE)
The Business Rules Engine (BRE) is built on sequential if-this-then-that logic.
It works well when:
Product rules are simple and predictable
Dependencies are linear
Bundles don’t require deep nesting
For many teams, this is where they start, and for good reason. It’s fast, intuitive, and effective… until it isn’t.
Note that BRE based Configuration Rules are generally not receiving new features, though they will continue to be supported going forward.
Advanced Salesforce Configurator (CML)
The Constraint Rules Engine powered by Constraint Modeling Language (CML) takes a fundamentally different approach. Instead of sequential logic, it uses a constraint-based solver to evaluate all conditions simultaneously.
This unlocks:
Complex, interdependent product relationships
Asset-based validation against existing customer environments
Soft constraints (guidance without blocking)
Scalable configuration logic for enterprise-grade catalogs
In other words: CML is built for the complexity most organizations eventually reach.
Note that CML based Advanced Configurator Rules are the path forward and are the target for new innovations and features for rules.
New Project?
The choice is simple, go CML. CML is the forward-looking approach that is getting new features and improvements each release, whereas BRE will continue to be supported but will not receive new functionality in future releases.
Existing Projects - The Tipping Point Most Teams Miss
Here’s the reality: teams don’t usually choose to move to CML. They get forced into it.
A simple decision framework we use with clients:
👉 If you answer YES to 2 of these 3, it’s time to move:
Do you have 30+ active configuration rules with cross-dependencies?
Are your bundles nested or bi-directional?
Are reps frequently overriding rules to resolve conflicts?
The Myth: “We Have to Fully Migrate”
One of the biggest misconceptions we see:
“We can’t switch because migration will disrupt everything.”
Not true. Both engines can coexist in the same org, but note for a given transaction, only one rules engine can be invoked.
That means you can:
Migrate product-by-product
Control execution using Transaction Processing Types
Allow teams to gradually adopt CML without breaking existing flows
This isn’t a rip-and-replace. It’s a controlled evolution.
Let's see it in Action
The following video outlines these concepts
Where Implementations Actually Break
The biggest risks don’t come from choosing the wrong engine. They come from:
Treating BRE like it can scale indefinitely
Migrating to CML without understanding behavioral differences
Converting rules without validating real-world outcomes
Even with tooling to convert BRE → CML, there are gaps:
Conditional defaults behave differently
Auto-add logic may not translate cleanly
Message handling changes
Translation ≠ transformation.
What High-Performing Teams Do Differently
The teams that “run better” don’t just implement—they architect for scale early:
Recognize when complexity is increasing—not just when it breaks
Introduce CML strategically, not reactively
Use shared rule execution across channels (UI, API, automation)
Treat configuration as a core system, not a feature
The Bottom Line
Configurator strategy isn’t a technical detail. It directly impacts:
Sales velocity
Quote accuracy
Operational scalability
And most importantly, your ability to grow without constantly rewriting your logic.
Next Steps
If your team is starting to feel the strain of complex configurations—or you’re unsure which direction is the right one, it’s worth a conversation.
At Stratus Carta, "We Do Not Run Projects, We Help The Projects You Run, Run Better. We work inside some of the most complex Communications and Revenue Cloud environments in the ecosystem, helping teams make decisions before they become problems.
About the Author
Kyle Tan is a Salesforce Technical Architect at Stratus Carta, specializing in Revenue Cloud. With over eight years of experience in the Salesforce ecosystem, he holds 13 Salesforce certifications. He is a recognized industry speaker at Salesforce events, sharing insights from his hands-on project work.
Comments