把坏数据挡在门外
另有 28 种语言版本
English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)
第 2 个模块，共 6 个，属于 Data Architect 课程第 5 章数据质量与治理。每个模块都可以单独阅读。 上一篇：治理要设计进 org · 下一篇：了解你的数据
**本模块回答的问题：**如何让数据保持良好，并一直保持下去？
处理坏数据有两种方式：在它进来之前拦住，或者事后清理。两种你都会做一些。但如果可以选，我宁愿预防问题，也不愿围绕着永无止境的清理去建立一个组织。重复、错误的标识符、缺失的信息、不标准的值、用户修改了另一个系统拥有的字段、集成用坏数据覆盖了好数据：这一切都会变成某人的清理项目。所以设计问题是：**我从一开始能合理地把哪些坏数据挡在门外？**而“合理”很重要，因为答案并不是把每个字段都锁死，直到系统没法用。
足够好是一个业务定义
Section titled “足够好是一个业务定义 ”在防止坏数据之前，先定义什么是好。没有唯一的定义。好可能意味着：完整到足以运行流程，准确到足以据此决策，新到足以满足工作负载，一致到足以与其他系统结合，唯一到足以知道我们说的是哪个客户，标准到足以支持自动化，可追溯到足以知道它从哪里来。这取决于数据。如果 Steve Trucking 要给一个零售合作伙伴开票，合作伙伴的法定身份就必须正确。如果一位销售代表在会后随手记笔记，没人需要一个委员会来批准每一句话。**足够好是一个业务定义；**架构师让它变得可度量、可执行。
预防代价高昂的错误
Section titled “预防代价高昂的错误 ”并不是每个坏字段都值得同样的关注。我最关心的是会在下游造成后果的错误。一个重复的客户意味着两份销售历史、两份服务历史、两组联系人、两个外部 ID、两个同步同一家公司的集成、数据仓库和 Data 360 里的两个版本，最终还有一个智能体要决定哪个客户才是真的。这比描述里的一个错别字代价高得多。所以不要从“我们如何验证每一个字段？”开始。要从**哪些坏数据会造成最大的业务或架构问题？**开始，把最强的控制放在那里。
开放还是锁定？
Section titled “开放还是锁定？ ”客户的创建是一个经典的例子。每个销售人员都应该能创建客户吗？我的回答是：**这取决于数据周围的治理。**对大多数中小型 org 来说，开放创建就可以。销售代表遇到一个潜在客户，创建客户记录，开始工作；这正是 CRM 的用途。重复规则、必填信息和数据专员负责管理质量。我不会因为治理听起来很负责任，就加上一套繁重的审批流程。
现在改变一下全景。法定客户在 ERP 中主控，带着一个 ERP 标识符流入 Salesforce，而 ERP 是权威的。这时，开放创建就意味着创建同一个受治理实体有两种途径。当 ERP 和一位销售代表都创建了同一家公司时，以哪个为准，集成用哪个标识符，哪条记录保存历史？开放创建就不再是一个可用性问题，而是一个主数据问题。当客户在 ERP 中主控或与 ERP 同步时，就锁定创建。
但完全锁死也会失败。销售代表遇到了一个不在 ERP 里的潜在客户，想开一个业务机会，而治理模型说“你不能建客户”。于是他们要么等财务部门三天，要么把业务机会挂到错误的客户上，要么把潜在客户记在备注字段或电子表格里。我们保护了数据模型，却伤害了业务。
折中的做法：临时记录类型
Section titled “折中的做法：临时记录类型 ”这是我喜欢的折中做法。**让销售在一个特定的记录类型下创建客户，即潜在客户或临时类型，并控制它向受治理类型的转换。**销售录入公司并开始销售。记录清楚地表明：尚未在权威系统中确立。然后一个受控的流程来转换它：由财务部门批准，或者由集成提交给 ERP，ERP 要么把它与一个已有客户匹配上，要么创建一个新客户，并回传权威的标识符。现在，这条记录跨越了一条边界：临时 → 受治理，这与两个系统各自创建它们认为是主记录的东西截然不同。
记录类型是我讲授的机制。不管你用什么，都要让这个状态在数据中可见：记录从哪里来，它是否已经跨越了边界，现在谁可以修改它，以及把它与权威系统联系起来的标识符。只有在转换之后才存在的 ERP 客户 ID，是所有信号中最清晰的一个。
每个数据流一个记录类型
Section titled “每个数据流一个记录类型 ”把整个数据流放进一张图里，你就会明白为什么这样做行得通。客户和产品从 ERP 流入。业务机会及其行项目流出，成为 ERP 的订单。那客户呢？有些流入，有些流出。所以我在各个实施项目中见过的一种常见模式，是在客户上设两个记录类型，每个方向一个。Sales 客户诞生在 Salesforce 中：销售代表创建它、编辑它、向它销售，当它成为正式客户时，就被发送到 ERP。ERP 客户（我曾把它叫作 Customer，或者干脆叫 SAP）诞生在 ERP 中，通过集成流入。除了集成，没有人会创建这个记录类型，而它的主数据字段（法定名称、地址、付款条件）对用户是只读的。记录类型告诉你记录朝哪个方向流动，所以主控的方向就直接写在记录上。
每个数据流一个记录类型：Sales 客户流出，ERP 客户流入。
这并不能消除那个难办的情况。一位销售代表为 Steve’s Plumbing 转换了一个潜在客户，但 Steve’s Plumbing 早已作为 ERP 客户存在，而重复检查不知怎么没有发现它。现在你得合并记录、给子记录重设父级，并决定哪条记录存活下来（第 6 章，模块 3）。
也不要纠结于记录类型本身。通常，除非有充分的理由，我会避免使用记录类型。我在这里用它，是因为在 Dynamic Forms 出现之前，记录类型决定页面布局，而一个布局可以把 ERP 字段显示为只读。有了 Dynamic Forms，可见性规则可以按某个字段的值显示或隐藏字段，一个字段可以在特定页面上设为只读，而且 Salesforce 自己也说 Dynamic Forms 能减少你需要的页面布局和记录类型的数量（Break Up Your Record Details with Dynamic Forms (opens in a new tab)（英文）；Required and Read-Only Fields in Dynamic Forms (opens in a new tab)（英文））。但页面上的只读只在那个页面上只读：API、一次数据加载或一个集成仍然可以写入这个字段。真正的执行靠的是字段级安全性或验证规则；界面验证不等于数据验证（第 3 章，模块 9）。当两类客户需要不同的选项列表值或业务流程时，记录类型仍然有它的价值。真正重要的是，有某个字段清楚地说明记录来自哪里：ERP 键本身、一个主数据标志，或一个来源选项列表。然后由这个字段来决定能否编辑。
从临时到受治理：销售立即开始销售；只有权威流程才能让记录变为受治理。
保护受治理的记录
Section titled “保护受治理的记录 ”一旦客户从 ERP 回来，它的 ERP ID、法定名称、税号和计费详情就是受治理的属性。销售代表应该修改它们吗？如果 ERP 拥有它们，就不应该。这就是模块 1 中那项需要执行点的策略：ERP ID 只读，法定身份受控，而销售代表仍然可以编辑区域、关系备注和 Salesforce 自己的分类。目标不是一个碰不得的客户记录，而是在Salesforce 拥有的数据和Salesforce 引用的数据之间划出一条清晰的界线。（第 4 章的 erp_ 前缀让这条界线在结构中可见。）
最终你得到的黄金记录其实是一个混合体。ERP 的主数据字段流入：法定名称、账单地址和送货地址、付款条件。然后 Salesforce 加上自己那些永远不会回传的字段：销售评级、最近订单日期，以及营销用到的几乎所有东西。同一个客户，两类字段，每一类都只有一个来源。
最难的是双向同步。假设一位销售代表需要把 ERP 中的法定名称从 Steve’s Plumbing 改成 Steve’s Plumbing LLC。就在同样的五分钟里，ERP 中有人把它改成了 Steve’s Plumbing L.L.C.。谁的修改胜出？思路是这样的：如果一个字段在 ERP 中主控，**你不是在修改这个字段，而是在请求修改它。**决定请求发生冲突时会怎样：ERP 胜出；如果值在此期间已经改变，就拒绝请求；或者等待一个人来解决。还要决定相关字段是作为一次变更一起传递，还是逐个传递。第 6 章会更深入地讨论冲突（循环与冲突）。
在门口拦住重复
Section titled “在门口拦住重复 ”重复会不断累积。在创建之前拦住一个，它是个小问题。两年后才发现它，而两边都挂着业务机会、个案、联系人、发票、集成和分析，它就是个大问题了。第 3 章的模块 7 讲过这些机制（匹配规则、重复规则、唯一的外部 ID），我就不再重复了。治理问题是：**我们必须在哪里防止重复，又在哪里容忍它、之后再解决？**一个随意的营销线索可以容忍模糊。一个有财务交易、受 ERP 治理的客户则不行。
把机器要读的东西标准化
Section titled “把机器要读的东西标准化 ”自由文本对人来说很棒，但当系统必须解读它时就很糟糕。在一个驱动路线安排的字段里放上 Arizona、AZ、Ariz.、Phoenix area 和 Southwest，你就有了一个质量问题。如果一个值驱动自动化、集成、报表、安全、分配或智能体的行动，就要认真想一想它必须标准到什么程度。不是每个文本字段都要变成选项列表，但要区分给人读的信息和**让机器据此做决定的信息。**后者值得更强的控制。
不要让必填字段制造假数据
Section titled “不要让必填字段制造假数据 ”我们认定一个字段很重要，于是把它设为必填。用户不知道答案，系统又不让他们继续，于是他们输入 N/A、Unknown、999999 或 test@test.com。字段是完整了；数据却是垃圾。在要求必填之前，先问用户在那个时间点是否真的知道它。如果不知道，就在流程的后面再要求它，让另一个系统来提供它，使用临时状态，或者在“未知”是一个合理答案时，提供一个明确的未知选项。验证规则可以执行一项策略，但它没法让人知道他们不知道的东西。
每一条数据边界都需要一个质量决定
Section titled “每一条数据边界都需要一个质量决定 ”坏数据的来源不只是人；集成产生坏数据的速度更快。一个零售合作伙伴的装货清单到了，有几百行。其中几行邮政编码无效，有两行写的是一个未知的配送中心，还有两行重复了同一个订单编号。怎么办？拒绝整个文件？接受好的行，退回坏的行？全部加载，之后再清理？把例外隔离起来？通知谁，合作伙伴如何得知哪些失败了？没有通用的答案，但必须有一个答案。第 4 章说每一个箭头都需要一个机制。再加一句：**每一条数据边界都需要一个质量决定：**我们接受、拒绝还是隔离什么，以及谁拥有这个例外。
每一条数据边界都需要一个质量决定。
历史数据不一样
Section titled “历史数据不一样 ”RouteDesk 存着 Steve Trucking 八年的历史，而它的质量因配送中心而异。我们应该在迁移之前把八年的数据都清理到今天的标准吗？多半不应该自动这样做。它是用来做什么的：日常运营、参考、索赔、报表、趋势分析？它是否都需要放在 Salesforce 里，还是有一部分可以留在别处？迁移那一章会深入讨论。治理上的要点是：**历史数据并不自动需要和活跃数据同样的标准。**如果你要根据它做决定，质量就很重要。如果你保留它只是为了参考，一个不同的标准也许就够了。在花大钱清理过去之前，先弄清楚它的用途。
度量有人会据此行动的东西
Section titled “度量有人会据此行动的东西 ”治理永远做不完，所以你需要看到质量何时下滑：重复率上升，被隔离的记录增多，集成拒收增多，占位值蔓延，绕过请求增多，报表不再对得上。但不要建 150 个指标然后忽略其中的 143 个。对 Steve Trucking 来说，也许是：没有有效合作伙伴编号的配送，没有可用地址的配送，重复的订单编号，被拒绝的合作伙伴报文，卡在临时状态的客户。一个满是绿色圆圈的仪表板并不意味着数据是好的。度量那些有人准备据此行动的东西。
**考试之外：AI 改变了什么。**坏数据越来越多地变成坏行动。一个人在拨打电话之前也许会注意到号码看起来不对；智能体则直接使用它拿到的值。重复的客户、过时的状态、虚假的必填值和错误的标识符，会直接变成错误的消息或错误的更新。这提高了预防的价值，但并没有消除对数据专员的需要。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”- 哪些质量问题造成的危害大到足以证明需要预防性的控制。
- 受治理的记录是自由创建、只能由权威系统创建，还是通过一条从临时到受治理的路径创建。
- 哪些属性归 Salesforce 所有，哪些它只是引用。
- 没通过检查的入站数据会怎样（接受、拒绝还是隔离），以及谁拥有这个例外。
- 度量哪些质量信号，让数据专员看到下滑。
你永远无法阻止每一条坏记录。这份工作不是追求完美的数据，而是**防止可以避免的坏数据变成代价高昂的数据。**在重复记录积累两年历史之前拦住它。在十个集成依赖上错误的标识符之前保护好它。让销售创建潜在客户，但在它真正成为受治理的客户之前，不要假装它是。而当有坏东西漏进来时，确保有人能看到它、负责它、修复它。
- Salesforce Help，Things to Know About Duplicate Rules (opens in a new tab)（英文），查阅日期 2026-10-14。
- Salesforce Help，Break Up Your Record Details with Dynamic Forms (opens in a new tab)（英文）和 Required and Read-Only Fields in Dynamic Forms (opens in a new tab)（英文），查阅日期 2026-10-14。