In Odoo Parametric CPQ, compatibility rules combine multiple conditions using AND and OR, so you can express logic like “hide this option when A or B is true, but only if C is also true.” A single-condition rule (“hide X when Y equals Z”) only gets you so far, and real product logic almost always needs several conditions working together.
Two fields do this work, and most people gloss over them the first time: group_no and logical_operator. Understanding those two is the difference between a rule that behaves and a rule that silently misfires.
How Compatibility Rules in Odoo Parametric CPQ work?
A compatibility rule does not hold its logic directly. It holds one or more condition lines, each specifying an attribute, an operator, and a value or set of values to compare against. The rule fires its action, show, hide, or disable, when the combination of those lines evaluates to true.
So the unit of logic is the condition line, and a rule is one or more of them assembled together. That matters, because the way those lines are grouped is what decides the rule’s real behaviour.
Can One Condition Match Multiple Values?
Yes, and this is the simplest form of OR logic, handled inside a single condition line. A line can target one attribute with several values and a value_join_operator of OR, so the line is satisfied if the attribute matches any of them, no second line needed.
For example, a wardrobe rule can hide Handle Type when Finish equals Handleless Groove or High Gloss Acrylic, expressed as one line with both values and an OR join. You only need multiple lines when the conditions target different attributes, not different values of the same one.
How Do AND and OR Combine Separate Conditions?
Through two fields working together. Condition lines that share the same group_no are combined with AND inside that group. The logical_operator field then decides how the different groups combine with each other.
That two-level structure is what lets you express distinct shapes of logic:
- AND within a group: hide this option when (Finish = A) AND (Width > 1200), two lines in the same group.
- OR across groups: hide this option when (Finish = A) OR (Control Type = Motorized), two lines in separate groups.
Grouping is the single most common place these rules go wrong. An accidentally AND’d condition that should have been OR’d, or the reverse, fails silently rather than throwing an error, so nothing warns you it is broken. It is worth sketching the logic in plain English before you touch group_no.
Example
The grouping alone can change what a rule does, even with identical conditions. Take three condition lines, A, B, and C:
- Grouped as (A AND B) OR C: the rule fires whenever C alone is true, regardless of A and B.
- Grouped as A AND (B OR C): the rule requires A every time, with B or C as the secondary condition.
Same three lines, meaningfully different results. This is exactly why you verify a rule against a few real test configurations before publishing it live.
| Field | What it combines | Example |
| value_join_operator | Multiple values within one condition line | Finish equals A OR B |
| group_no | Lines in the same group, joined with AND | (Finish = A) AND (Width > 1200) |
| logical_operator | Separate groups, with each other | (group 1) OR (group 2) |
Frequently Asked Questions
How do AND/OR compatibility rules work in CPQ?
A rule holds condition lines. Lines sharing a group number are combined with AND, and the logical operator combines the groups with each other, letting a single rule express logic like “(A and B) or C.”
How do I test a compatibility rule before publishing it?
Run through the configurator manually with a few representative combinations, including edge cases, before relying on the rule in a live sales or e-commerce session.
Why does my compatibility rule fire when it shouldn’t?
Usually a grouping mistake. Conditions accidentally combined with AND instead of OR, or the reverse, change the rule’s behaviour and fail silently, so sketch the logic in plain English and test it against real configurations.
Can a rule have an unlimited number of condition groups?
There is no hard cap, but rules with many groups get hard to reason about. It is often cleaner to split genuinely complex logic into several simpler rules that share the same target action.
Do I need multiple condition lines to express OR?
Not always. For OR between values of the same attribute, use one line with a value_join_operator of OR. You only need separate lines and groups when the conditions target different attributes.
