I recently worked with a CPQ customer that had multiple facilities—each operating under its own legal entity but selling essentially the same product. The catch? Each facility used slightly different equipment or processes.
Instead of building a scalable solution, the team made a critical error that’s surprisingly common:
They created forked product configurator rulesets for each facility.
This might seem like a practical solution at first, but it creates long-term complications that are difficult to maintain, troubleshoot, or scale. In this article, we’ll explore why forking should be avoided, what it means for your configuration logic, and how to follow CPQ Ruleset best practices for better performance and maintainability.
For more information, learn about the best Business Central product configurator add-ons available today.
What Is a Ruleset?
First, let’s define what we mean by a Ruleset in the context of a product configurator.
A Ruleset is, essentially, a software program—albeit one built inside a low-code environment. These Rulesets drive the logic behind your configurator: they decide which options are valid, which components are compatible, and how pricing, BOMs, and routings are generated.
Most modern product configurator rulesets, especially those integrated with ERP systems like Microsoft Dynamics 365 Business Central, include familiar programming components:
- Variables
- Conditional logic
- Loops
- Dataset queries
- Functions or methods
These are the same building blocks you’d find in traditional programming. You don’t need to be a full-stack developer to build with them, but you do need to approach them with the same mindset as software development.
What Is Forking and Why Is It a Problem?
In software terms, a fork occurs when you copy a codebase to create a new version tailored for a slightly different use case. In CPQ terms, it’s when you copy a Ruleset to use it for another facility, product line, or customer—rather than reusing logic with some smart filtering.
At first, a forked Ruleset seems like a handy shortcut. But over time, here’s what happens:
- A bug is fixed in one version but forgotten in another
- A new feature is added to Facility A’s Ruleset but not Facility B’s
- Updates that should be global are only applied in some forks
Instead of managing one configurator, you’re now juggling five or ten nearly identical versions. Each one diverges slightly over time, doubling testing requirements, introducing inconsistencies, and creating serious technical debt.
This breaks a core principle of CPQ Ruleset best practices: maintaining a single source of truth.
What They Should Have Done: Use Branching Logic
Rather than duplicating Rulesets, the better approach is branching logic within a unified Ruleset.
For example, at the start of your Ruleset, include a prompt like:
“Which location is this configuration for?”
From that one input, you can determine:
- Which rules to apply
- What data to filter
- What pricing logic, BOMs, or routing structures to use
- Which UI options to hide or show
With branching, you build one product configurator ruleset that adjusts dynamically based on input. It takes more time to set up initially, but dramatically reduces long-term maintenance and error risk.
Why Do So Many Teams Fork Rulesets?
The short answer? It feels easier.
Forking is intuitive—especially for teams without a formal software development background. You already have a working Ruleset, so why not just copy it and make a few tweaks?
Most configurator administrators are engineers, product designers, or manufacturing experts—not coders. They’re brilliant problem-solvers, but they’re often not trained to think in terms of code reusability, branching, and technical debt.
They’re trying to solve a specific problem in front of them—and forking looks like a shortcut. But like most shortcuts in software, it becomes a detour that takes longer in the end.
How to Avoid Forks From the Start
Professional developers are trained to design before they build. That often means creating flowcharts or diagrams to map out how the logic should work before writing a single line of code.
Even if you’re not a seasoned developer, this practice can be a lifesaver.
Tools like Visio, Lucidchart, or even pen and paper are enough to get started. Map out:
- What the user will be asked
- What data is needed
- Where decision points occur
- How rules can be reused with different filters or variables
Following these steps aligns your implementation with true CPQ Ruleset best practices, ensuring long-term scalability and easier maintenance.
How CPQ 365 Can Help
At CPQ 365, we work with Configure-to-Order manufacturers to ensure their configurators follow CPQ Ruleset best practices from day one. Whether you’re starting fresh or cleaning up a legacy system, we help you:
- Map and optimize your Rulesets
- Eliminate forks and reduce complexity
- Train your team on branching logic and best practices
- Provide hands-on support across popular configurator platforms for Business Central
If you’re facing a tangled web of duplicated logic, it’s not too late to untangle it—and we’re here to help.
Final Thoughts
Forked Rulesets may feel like an efficient shortcut, but they introduce long-term complexity that’s difficult to manage. Following CPQ Ruleset best practices—including proper planning, flowcharting, and branching logic—helps you avoid duplication, reduce risk, and build a more sustainable CPQ solution.
If you’re struggling with duplicated logic, version control issues, or constant rework in your product configurator, it’s time to rethink your architecture. And if you need help? That’s exactly what we do at CPQ 365. Contact us today.
FAQ
What is a Ruleset in a CPQ system?
A Ruleset is essentially the logic engine or “program” behind your product configurator. It defines what options are available, what combinations are valid, how pricing is calculated, and what gets pushed to the ERP (like a BOM or routing). Think of it like a simplified software program built using a low-code environment.
What does it mean to “fork” a Ruleset?
Forking a Ruleset means copying an existing Ruleset and modifying the copy for a slightly different use case—like another location, product line, or customer. The problem is that the original and the copy are no longer linked. You now have two separate sets of logic to maintain.
Why is forking a bad idea in CPQ systems?
While it might seem faster at first, forking creates redundant logic that quickly becomes hard to manage. Every bug fix, update, or improvement has to be applied multiple times across each forked Ruleset. It increases the risk of errors, misalignment between versions, and configuration mistakes during quoting.
When is it okay to fork a Ruleset?
In general, you should avoid forking unless the second version is truly a separate product with almost no shared logic. Even then, it’s often better to create modular or reusable components within your Ruleset framework. Forking should be a last resort, not a default.
What’s the alternative to forking?
Use branching logic within a single Ruleset. For example, prompt the user to select the location or product variant, and filter the data or logic paths based on that input. This keeps your logic centralized and easier to manage.
I’m not a developer—how can I build better Rulesets?
You don’t need to be a software developer, but it helps to think like one. Start by flowcharting your Ruleset: map out the decisions, inputs, and outputs before you start configuring. Tools like Microsoft Visio, Lucidchart, or even whiteboards work great for this.
