01 优化销售区域性能（Optimize Performance for Sales Territories）
本单元学习如何在使用销售区域（Sales Territories）时优化性能：避免过度规则评估、避免不必要的访问级别重算、定义有效的过滤条件、保持分配规则严格，以及谨慎使用账户评估。
引言：Capricorn 收购（Introduction: The Capricorn Acquisition）
几个月前，Salesforce 管理员 Maria Jimenez 为 Ursa Major Solar 设置了销售区域（Sales Territories）。她的销售团队现在能轻松跟踪谁在负责什么，业绩一路高歌。
最近，Ursa Major 收购了竞争对手 Capricorn Solar。为了处理 Capricorn 的销售区域、账户和销售代表，Maria 加了不少班。她尤其担心系统性能——她要对活动中的区域模型做这么多改动、维护这么多区域。是时候掌握一些高级技能，确保这个功能尽可能高效地运行了。
避免过度规则评估（Avoid Excessive Rule Evaluation）
Maria 的首要任务是把 Capricorn 的父区域加到 Ursa Major 活动区域模型的区域层级里，其次是把账户分配到这些区域。她想知道如何把账户分配规则相关的性能问题降到最低。
我们建议：把继承的规则应用到子区域。
把父区域加到区域层级时，最好把继承的账户分配规则应用到其子区域。把每个层级分支定义为各自的「树」，让同一层级的「兄弟」互斥。这样就能避免规则引擎评估层级中不必要的分支，从而提升性能。
要应用继承规则，在分配规则的详情页勾选 Apply to child territories（应用到子区域）。
避免不必要的访问级别重算（Avoid Unneeded Recalculation of Access Levels）
为了容纳 Capricorn 的区域结构，Maria 还要对活动区域模型做不少改动。把区域重新分配到其他父区域的最佳方式是什么，才能不影响性能？
我们建议：先从层级最低层开始，在那里做改动，然后逐层向上移动。用这种方法可以避免对账户、商机、联系人和工单重复重算访问级别。
注意：对处于规划阶段的区域模型，这种做法没有必要。
在分配规则中定义有效的过滤条件（Define Effective Filter Criteria in Assignment Rules）
现在 Maria 准备为 Capricorn 账户的新分配规则定义过滤器。有哪些最佳实践能减少性能问题？
我们建议：在数字字段上定义条件，而不是字符串字段；并且不要把数字条件定义为文本。
字符串字段上的运算符不区分大小写，会影响性能。所以与其在字符串字段上定义条件，不如考虑在数字字段上定义。同时，定义为文本的数字字段会拖慢性能——例如，在「员工数」的过滤条件里，输入 1000，而不是 one thousand。
保持分配规则严格（Keep Assignment Rules Restrictive）
Maria 继续为 Capricorn 账户定义分配规则，我们还有几条建议。
定义分配规则时，尽量让它严格。例如，避免加入大量 OR 条件，这样 Salesforce 就不会把太多账户分配到一个区域。
为获得更好的性能，请参考这些比例：
- 与一个区域关联的记录超过 10,000 条会造成性能低效。例如，12,000 个账户分配到一个区域可能太多了。
- 区域数与分配用户数的比例，经验法则是 3:1。
- 如果需要向一个区域添加超过 1,500 个用户，不要用 Setup，而是通过 API 管理用户到区域的分配。
避免在不需要时运行分配规则（Avoid Running Assignment Rules When Not Needed）
Maria 熟悉「保存时对该账户评估区域规则（Evaluate this account against territory rules on save）」这个选项，她想知道能否用它来在 Capricorn 账户上省时间。
我们建议：谨慎使用。
你可以设置 Salesforce 在账户更新时运行账户分配规则：
- 在账户编辑页设置：勾选 Evaluate this account against territory rules on save。
- 用 API 设置：在 SOAP API 或 REST API 更新调用中设置相应的 header 参数。
但因为即使只更新了一个账户，Salesforce 也会为所有账户运行分配规则，性能可能受影响。为避免性能下降，请谨慎使用这些方法。
提示：为了让区域-账户分配在整个财年期间保持稳定，把分配规则属性复制到账户页面布局新增的自定义字段里，然后在规则定义中使用这些自定义字段。这样设置能控制账户属性，让分配保持稳定。
02 掌握销售区域的技巧与窍门（Get Tips and Tricks for Sales Territories）
本单元学习更多技巧与窍门：避免重复层级结构、展示区域汇总预测、与外部单一事实来源同步、突破分配规则限制、清理数据、定义指定账户、用 API 省时省力，以及避免不必要的共享重算。
引言：Maria 的更多问题（Introduction: More Tips for Maria）
Maria 已经学到不少关于解决销售区域性能下降的知识，但她在完成 Capricorn Solar 销售区域、账户和代表的设置时，还有其他想学的东西。
本单元回答 Maria 关于层级结构、预测、数据同步、分配规则限制、数据清理、指定账户、API 和共享重算等主题的剩余问题。
避免重复层级结构（Avoid Duplicating Hierarchy Structures）
Maria 还要对 Ursa Major 的区域层级做改动，她不确定该怎么建。是否应该基于用户角色层级（role hierarchy）来建？
答案是否。销售区域提供的对账户、商机、联系人和工单的访问级别会汇总到角色层级。在角色层级的销售分支里重复区域结构是多余且冗余的。
相反，用角色层级来表示管理关系、汇报汇总、审批和其他层级工作流，把角色层级的销售分支简化到只包含这些用途的角色；然后用区域层级根据用户的区域分配来扩展对记录的访问。
当角色层级和区域层级都得到恰当使用时，它们互为补充，为企业信息的报表、分析和细分提供双重模型：角色层级适合建模管理和 HR 类汇报结构（一人只向一人汇报），区域层级最适合建模矩阵式汇报结构（一人可向多个经理汇报）。
展示区域汇总预测（Show Rolled-Up Forecasts for Territories）
Ursa Major 销售团队使用协作预测（Collaborative Forecasts），最近启用了区域预测。Maria 如何确保团队看到各自区域的汇总预测金额？
为你想要汇总预测金额的每个区域分配一个预测经理（Forecast Manager）。例如，如果你希望每个月都能看到 AMER 区域的预测，就把 AMER 区域分配给一个预测经理，即使实际上并没有人在管理它。
对于每个没有子区域的区域，决定是否要分配预测经理：
- 已分配：该区域的预测可供预测经理查看和调整；
- 未分配：分配给该区域的每个启用预测的用户各自的预测可用，这些用户只能查看和调整自己的预测，不能查看他人的。
与单一事实来源同步（Sync with a Single Source of Truth）
在设置销售区域之前，Maria 用过一个外部「单一事实来源」来管理 Ursa Major 的区域，她现在仍觉得那份数据有用。如何让销售区域与它同步？
我们建议：创建一个自定义的 External ID 类型字段，并把它加到区域页面布局上。
如果你把区域层级与外部单一事实来源集成，就可以让区域层级基于该来源、用它来管理区域。注意这个过程不是自动的——需要数据导入或调用 API。为了保持区域层级与外部单一事实来源同步，要定期维护。
注意：如果你把自定义 External ID 字段定义为唯一（unique），就不能克隆区域模型。
更充分地利用分配规则过滤条件（Do More with Assignment Rule Filter Criteria）
你可能已经注意到，分配规则限制为 10 个过滤条件字段。Maria 为 Capricorn 账户设置规则时，被这个限制束缚住了。如何绕过它？
当条件条目数不满足业务需求时，用公式字段（formula fields）把账户上的多个数据字段合并。例如，如果需要超过 10 个条件字段，可以把 Billing Country 和 Billing State/Province 合并成一个公式字段。
当条件基于账户的相关记录时，用汇总摘要字段（rollup summary fields）或触发器把数据搬到账户上，再用这些字段驱动账户分配规则条件。
虽然允许 10 个条件字段，但我们建议保持在 6 个或更少。
先清理数据（Clean Up Data First）
Maria 发现 Salesforce 数据有问题，比如重复记录。在改动区域模型时，她冒出个想法：用区域分配规则来清理数据。好主意，对吧？
实际上我们不建议用区域分配规则来清理数据，尤其是在确定把哪个账户关联到线索时。把数据清理与区域分配分开处理，让区域规则结构保持精简。
我们建议使用：
- 内置的重复管理（duplicate management）功能来管理和合并重复记录；
- Lightning Data 让记录保持最新、并找到与你最佳客户相似的新账户。
有效地定义指定账户（Define Named Accounts Effectively）
和很多公司一样，Capricorn Solar 有几个指定账户（named accounts）——分配给最能管理它们的销售代表的大客户。指定账户通常以公司命名，比如 Solar Emporium，而不是它所在的销售区域（如 San Francisco）。Maria 还没接触过指定账户，想要一些建议。
在标准账户分配规则结构中定义指定账户，我们有几个策略：
- 在规则条件中按账户名称定义。因为账户名可能很长，通常建议对区域内指定账户较少的较小客户使用这种策略。
- 按账户编号定义条件，比账户名更简洁。这种策略让销售团队能在区域内包含更多指定账户。
- 按总部账户记录中的属性定义条件。客户可以用公式字段或 Apex 把这些属性从总部账户应用到同一账户族的所有记录，确保同一账户族使用同一套条件分配。
- 如果以上方案都无法提供合适的可扩展性，则开发定制化分配方案。
用 API 省时省力（Save Time and Effort with APIs）
由于 Capricorn 的区域结构，Maria 预计区域层级会频繁变动。如何简化频繁的区域重新对齐？
有些客户每月、每周甚至每天重新对齐区域，向庞大的规则库频繁发送更新。这些客户可以从更新规则结构的自动化流程中受益。
我们建议：使用 API 自动化维护标准账户分配规则结构，不建议定制标准规则结构。
注意：Salesforce 标准规则结构是关系型的，为广泛的客户群提供了足够灵活性。虽然对大型客户来说技术上可以维护标准规则结构，但关系型结构让自动化维护变得困难。
避免不必要的共享重算（Avoid Unnecessary Sharing Recalculation）
Ursa Major 使用团队销售。Maria 需要账户所有权分配方面的帮助。「销售区域」又来救场了吗？
算是吧。销售区域不会自动分配或更改账户所有者。但当一个或多个区域分配了多个代表时，有些客户会分配一个「占位用户（dummy user）」或「集成用户（integration user）」作为账户所有者的替身，然后把代表和角色分配到区域，来建模代表到账户的关联。
这种方法减少了对共享重算的需求——也就是账户所有者更新引发的下游记录变更。你也可以用 Apex 或其他编程资源，把一个已分配区域的用户指定为账户所有者。
用销售区域完成更多工作（Get More Done with Sales Territories）
Maria 快完成了。她想知道收购 Capricorn 后，Ursa Major 是否该采用账户团队（account teams）。她能否同时使用销售区域和账户团队？
如果你在用销售区域，我们建议不要用账户团队。
两个功能都提供把合适代表分配到账户的机制、对记录的访问控制，以及报表汇总。但销售区域为汇总、预测提供了更多层级结构，还能自动把代表分配到账户。我们也听说有些客户从账户团队迁移到销售区域，以简化共享和报表需求。所以如果你想自动化流程，或销售团队预计会大幅增长，考虑使用销售区域。