一、开始使用产品规则（Get Started with Product Rules）
用产品规则让报价井然有序（Bring Order to Quotes with Product Rules）
销售代表只是普通人，有时会忘记在报价中加上必要产品，更糟的是加入不兼容的产品。错误报价变成错误订单，让客户沮丧、各方浪费时间。产品规则（product rules）就像护栏，帮销售代表在复杂的产品组合中保持正轨，第一次就把正确的产品放进报价。
适用于各种场合的产品规则（Product Rules for All Occasions）
产品规则有四种类型：
- Alert（警报）：显示潜在问题消息，但允许忽略（如提醒追加销售机会）。
- Validation（验证）：显示必须修复才能保存的问题（如选错墨盒阻止保存非法配置）。
- Selection（选择）：自动添加、移除或隐藏选项，也可自动向报价添加产品。
- Filter（筛选）：在动态选择的功能中只显示特定产品。
产品规则是团队协作（Product Rules Are a Team Effort）
产品规则记录是容器，四个相关对象查找它：
- Error Condition（错误条件）：控制规则何时触发。
- Action（动作）：保存 CPQ 如何改变捆绑包配置的指令，多用于选择规则。
- Lookup Query（查找查询）：把规则绑定到数据源对象。
- Configuration Rule（配置规则）：告诉 CPQ 规则应用于特定可配置捆绑包。
其他贡献者（Other Contributors）
还有两个对象常参与产品规则：配置属性（Configuration Attributes）（代表在配置中设置的字段，常用于错误条件）和汇总变量（Summary Variables）（跨记录汇总数值，常用于错误条件/动作）。
注册一个带 Salesforce CPQ 的 Developer Edition 组织（Sign Up for a Developer Edition Org with Salesforce CPQ）
需要带 Salesforce CPQ 和示例数据的特殊 Developer Edition 组织：注册、填表、验证邮箱、设置密码、连接 Trailhead。
二、给规则加上条件（Put Conditions on Rules）
在正确条件下（Under the Right Conditions）
产品规则通过阻止错误来帮代表创建准确报价。例如 AW Computing 的 Cloud Storage 因不符合 HIPAA，不能卖给医疗行业客户。错误条件（error condition）是「通过/失败」式测试，比较两段数据（如报价行的产品代码是否等于 CLOUDSTORAGE）。有多个错误条件时，用产品规则的 Conditions Met 字段告诉 CPQ 需满足「any」还是「all」。
创建你的第一个错误条件（Create Your First Error Condition）
创建验证规则 No cloud storage for healthcare industry（Type Validation、Evaluation Event Always、Active、Conditions Met All、Message 填错误文案）。然后创建错误条件：Tested Object Quote Line、Tested Field SBQQ__ProductCode__c、Operator equals、Filter Value CLOUDSTORAGE。
把数据拉到可测试对象中（Pulling Data into a Testable Object）
错误条件只能测试六个对象上的数据：Quote、Quote Line、Quote Line Group、Product Option、Configuration Attributes、Upgraded Asset。要测试账户行业，需在 Quote 上建公式字段 AccountIndustry__c 拉取值。第二个条件：Tested Object Quote、Tested Field AccountIndustry__c、equals Healthcare。Tested Field 是依赖选项列表，值取决于 Tested Object。
高级条件（Advanced Conditions）
用 Index 给错误条件编号，再把 Conditions Met 设为 Custom，在 Advanced Condition 中写 AND/OR 表达式，如 10 AND (20 OR 30)（产品 = Cloud Storage，且行业为 Healthcare 或 Banking）。
三、决定规则何时评估（Decide When Rules Evaluate）
每个测试的时间和地点（A Time and Place for Every Test）
错误条件评估太频繁会很烦人。好在你可以精确控制 CPQ 何时评估错误条件——例如只在代表点击 Save 时测试，而不是每次小改动都弹出。
产品配置 vs 报价行编辑器（Product Configuration vs Quote Line Editor）
一条产品规则要么在产品配置页、要么在报价行编辑器上运行，不能两者都跑。Scope 字段告诉 CPQ 规则在哪里运行：Product（配置期间）或 Quote（报价行编辑器）。
评估事件（Evaluation Event）
Scope 说「哪里」，Evaluation Event 说「何时」。不同 Scope/Event 组合支持不同规则类型：Product 的 Load（Selection/Filter）、Edit（Selection/Validation）、Save（Alert/Validation）；Quote 的 Load（Selection）、Save（Alert/Validation）。「Always」不是真的一直评估，而是「所有适用」。
别等，立即应用！（Don't Wait, Apply Immediately!）
Edit 事件规则只评估特定编辑。要让它即时触发，在选项记录或配置属性记录上勾选 Apply Immediately。还有 Apply Rules 按钮可一次性评估所有 Edit 事件规则。注意：Validation 规则若不设 Apply Immediately，至少设 Always；Selection 规则在 Save 时从不评估，别只依赖 Apply Rules。
评估顺序（Evaluation Order）
Evaluation Order 用于排序选择规则（数字顺序）。通用规则设 10、专门规则设 20，通用先跑。建议用 10 的增量，方便以后插入。
四、为特定捆绑包制定规则（Make Rules for Specific Bundles）
按自己规则玩的捆绑包（A Bundle That Plays by Its Own Rules）
有时规则只在配置特定捆绑包时需要。例如 Telecommuter Workstation 捆绑包，代表常卖出没有麦克风的配置。创建一条只在此捆绑包内运行的规则。
汇总变量（Summary Variable）
汇总变量把一组数据汇总成单一数值。创建 Microphone Sum：Target Object Product Option、Aggregate Function Sum、Aggregate Field Quantity、Filter Field Product Code、Operator ends with、Filter Value MIC。
创建捆绑包专属规则（Create a Bundle-Specific Rule）
创建验证规则 Prevent missing microphones（Type Validation、Scope Product、Evaluation Event Save、Active、Conditions Met All、Message 填文案）。错误条件用汇总变量：Tested Variable Microphone Sum、equals 0。最后创建 Configuration Rule 记录（Active、Product 选 Telecommuter Workstation），把规则关联到该捆绑包。
测试产品选项字段的局限（Limits of Testing Product Option Fields）
CPQ 对产品选项字段的测试方式是逐个遍历已选中选项。两个注意点：1) 只测试已选中选项，无法测试「未选中」的东西（所以要用汇总变量）。2) 在同一条规则里测试两个不同选项会失败（一个选项不可能同时是两者）。解决方法仍是用汇总变量计数其中一个。
五、用选择规则控制选项（Control Options with Selection Rules）
选择规则的援手（The Helping Hand of Selection Rules）
选择规则（selection rules）自动改变配置。动作类型包括：Add（勾选）、Remove（取消勾选）、Disable（置灰不可勾）、Enable（可勾）、Disable & Remove、Enable & Add、Hide（完全移除）、Show（恢复）、Hide & Remove、Show & Add。
创建两条相反的选择规则（Create Two Opposing Selection Rules）
Home Automation Hub 场景：创建汇总变量 Outlet Sum（Product Option、Sum、Product Code ends with OUTLET）。规则 1「Disable and remove electrical installation」：当 Outlet Sum = 0 时，动作 Disable & Remove Electrical Installation。规则 2「Enable and add electrical installation」：用 Clone with Related 克隆再反转——Outlet Sum > 0 时，动作 Enable & Add。给 Smart Outlet 选项勾选 Apply Immediately。
六、发现选择规则的其他用法（Discover Other Ways to Use Selection Rules）
一个动作统治一切（One Action to Rule Them All）
用动作里的筛选信息一次性影响多个产品，而不是每个产品一个动作。例如对乳糖不耐客户禁用所有含 Dairy__c 的产品：动作 Type Disable，Filter Field Dairy__c、equals true。注意：若同时填了 Product 查找和筛选，只有查找的产品受影响；用筛选就留空 Product。
用选择规则向报价添加产品（Add Products to a Quote with Selection Rules）
报价范围的选择规则可直接向报价添加产品。例如买显示器送免费 USB 拇指盘：Type Selection、Scope Quote、Evaluation Event Always、Conditions Met Any；条件 Product Code starts with monitor；动作 Type Add、Product USB Thumb Drive、勾选 Required。Add 是唯一必须勾选 Required 的动作类型（Hide/Disable/Remove 则绝不能勾）。报价范围的选择规则每次返回报价行编辑器都会运行。
选择规则 vs 选项约束（Selection Rules Versus Option Constraints）
选项约束更简单但局限。产品规则更好的理由：可应用于无限个捆绑包、可用 Add 动作勾选选项、可有多个条件评估捆绑包外信息、可作用于多个选项。
选择规则 vs 验证规则（Selection Rules Versus Validation Rules）
选择规则自动引导代表到正确配置；验证规则用消息阻止保存。根据想要的体验选择，并在试点后收集代表反馈。
七、用自定义对象的数据驱动规则（Use Data from a Custom Object to Drive Rules）
规则之山（A Mountain of Rules）
相似规则会堆积成山。例如按国家限制电源选项，为每个国家建一条规则很麻烦。改用查找查询（lookup query），一条规则处理所有变体，由自定义对象的数据驱动。
一切始于数据（It All Starts with Data）
查找规则需要一个描述所有场景的数据源。本示例用自定义对象 Outlet Locales（字段 OLCountry、OLProduct、OLType、OLRequired），记录每个国家应启用的产品。
创建查找产品规则（Create a Lookup Product Rule）
创建选择规则 Limit power options（Scope Product、Evaluation Event Load）。在 Lookup Query Information 区设置：Lookup Object OutletLocale__c、Lookup Type Field OLType__c、Lookup Product Field OLProduct__c、Lookup Required Field OLRequired__c。创建 Lookup Query：Match Type Field Value、Tested Object Quote、Tested Field SBQQ__ShippingCountry__c、equals、Lookup Field OLCountry__c。动作 Disable & Remove，Filter Field Product Code、contains power。选择规则中动作先于查找查询执行（先全禁用，再启用正确的）。
验证和警报查找规则（Validation and Alert Lookup Rules）
验证/警报查找规则更简单：只需自定义对象上的一个查找字段和一个文本字段存放消息，在规则上设置 Lookup Message Field 指向该文本字段即可，无需在规则记录里写消息。
八、用筛选规则制作动态捆绑包（Make a Dynamic Bundle with Filter Rules）
动态捆绑包的理由（The Case for Dynamic Bundles）
动态捆绑包（dynamic bundles）自动纳入新相关产品、剔除不再需要的产品。它有一个特殊功能：显示「添加选项」链接，点击进入一个筛选后的迷你选品页。优势是无需为虚拟选项创建选项记录；局限是失去了对虚拟选项行为的控制（如最大数量）。
如此出众的产品！（Such Distinguished Products!）
用一个自定义字段标识动态捆绑包应包含的产品。本示例用产品上的 Extras__c 复选框标记常见附加项。
设置后门通道（Set Up a Back Channel）
在 Product Option 对象上创建同名的 Extras 字段（名称必须与产品字段匹配），这样 CPQ 把产品数据复制到虚拟选项列表时就有地方放，才能用它筛选。
设置动态二重奏（Set Up the Dynamic Duo）
动态捆绑包需要特殊功能和筛选规则配合。创建功能 Upsells（Min Options 0、Number 50、Option Selection Method Dynamic）。创建筛选规则 Extras filter（Type Filter、Scope Product、Evaluation Event Load、Active、Conditions Met All），动作 Type Default Filter、Filter Field Extras__c、equals true。最后创建 Configuration Rule 关联到 Telecommuter Workstation 的 Upsells 功能。
默认筛选 vs 可选筛选（Default Filter Versus Optional Filter）
动作 Type 选 Default Filter 时，即使代表点 Clear Fields，筛选仍保持（列表锁定）；选 Optional Filter 时，Clear Fields 会清除筛选、显示全部产品。根据是否想锁定列表谨慎选择。
