# Explaining CPQ logic in plain language A CPQ price rule is unreadable to anyone who didn't build it. Here's how to get it translated for a non-technical approver, and what to verify before trusting the translation. **Time:** 10 minutes **What you'll have when you're done:** A plain-language writeup of a price rule or product rule that a sales manager or finance approver can actually read and sign off on. **Before you start:** - Any AI chat tool you're allowed to use - Access to the rule's configuration: its conditions, actions, and any formulas involved ---CPQ configuration is built to be readable by CPQ, not by people. A price rule's conditions, a product rule's actions, a formula field feeding into either, all of it is precise and none of it is written for the sales manager who needs to approve a pricing change or the finance reviewer who needs to understand why a discount capped where it did. The fix isn't simplifying the rule. It's translating it, accurately, for someone who was never going to open the configuration screen. --- ## What makes this different from a regular Flow or formula CPQ logic is usually spread across several pieces that only make sense together: a price rule references conditions that might live on the quote, the quote line, or a lookup object, and its actions often feed a formula that isn't visible from the rule itself. Translating the price rule alone, without the formula it triggers, produces an accurate description of half a system. Gather all the connected pieces before asking for a translation, not partway through. --- ## Step 1: lay out every piece involved ``` Rule name: [e.g. "Volume Discount Tier"] Rule type: [price rule / product rule] Evaluation scope: [quote line, quote, or specific event, e.g. on save] Conditions: [paste each condition line exactly] Actions: [paste each action, including target field and formula if the action sets a value via formula] Any formula fields referenced by the conditions or actions: [paste each formula and what it's named] ``` A rule that looks like it has one condition often has a formula field doing real work upstream of that condition. If a condition references a formula field, that formula's logic belongs in this list, not left out because it's "just a field." --- ## Step 2: ask for the plain-language translation, structured the same way every time ``` Translate this CPQ rule into plain language for someone who has never seen the configuration: 1. When does this rule apply? (what has to be true about the quote or quote line for it to fire) 2. What does it do when it applies? 3. What's the practical effect for someone building a quote, in one sentence? No CPQ terminology (avoid "quote line," "product rule," "price rule" unless the reader needs to know the mechanism). Write for a sales manager, not an admin. ``` Structuring the answer the same way every time matters more here than it might seem. A stack of rule writeups that all follow "when, what, effect" can be scanned together to spot rules that overlap or conflict, which is hard to see across a pile of differently-shaped paragraphs. --- ## Step 3: verify the effect against an actual quote This is the step that catches wrong translations, and CPQ has more room for a plausible wrong reading than a simple formula field does, because condition logic often depends on how fields are populated at runtime, not just their type. Build or find a quote line that should trigger the rule, and one that shouldn't, as close to the condition boundary as you can get. Confirm the plain-language "when does this apply" correctly predicts both. If it doesn't, the rule reading was wrong, most often on how multiple conditions combine (all of them versus any of them) or how a formula field's blank state gets handled. --- ## When it breaks **The translation gets the condition logic backwards.** The most common cause is a condition set that combines with OR being read as AND, or the reverse. This is exactly why step 3 tests both a triggering and a non-triggering case rather than trusting the plain-English read alone. **A referenced formula field wasn't included, and the translation is confidently incomplete.** If the writeup doesn't mention a factor you know affects the price, check whether that factor lives in a formula field you didn't paste in. An incomplete input produces a confident, plausible, and wrong answer. **Two rules turn out to interact and the writeup treats them independently.** CPQ rules can fire in sequence and affect the same field. If you're translating a related set of rules, ask explicitly whether the order they evaluate in changes the outcome, rather than assuming each writeup stands alone. **The approver reads the plain-language version and it still doesn't match what they saw on a real quote.** Trust the approver's observation over the translation. That mismatch is real signal that either the rule or the writeup has a gap, and it's worth tracing before the discrepancy gets explained away. --- ## What to try next Attach the plain-language writeup to the rule's own description field, the same as a validation rule. CPQ configuration turns over people faster than it turns over logic, and a rule with no writeup outlives everyone who understood it when it was built.

Next