很多 Salesforce 组织在多年的快速发展中积累了大量"捷径"——重复的字段、冗余的权限、过时的自动化。这些历史欠账不会自己消失，反而会在你引入 AI 时集中爆发：因为 AI 依赖干净、一致的数据。本篇是 Trailhead「Technical Debt」模块的中文导读，你将扮演 AW Computing 的 Salesforce 管理员，在一场并购之后调查阻挡 AI 上线的问题，并按风险排序、逐一清除技术债务。
全文分为四个单元：第一单元理解什么是技术债务、为什么必须管理它；第二单元按风险排序，用最小权限原则关闭安全漏洞；第三单元删除重复字段、统一页面布局，维护"唯一事实来源"；第四单元把遗留的 Process Builder 自动化迁移到 Flow Builder。每个小节对应一页 PPT 幻灯片并附讲解视频。
01 管理技术债务（Manage Technical Debt）
本单元建立技术债务的认知基础。学完本单元，你将能够：描述什么是技术债务，并解释为什么管理技术债务很重要。
把 AW Computing 带入 AI 时代（Bring AW Computing into the Era of AI）
AW Computing 经过多年发展已成为一家国际化公司，最近还收购了一家 AI 研究初创公司 AI-to-Z。这次收购给公司打开了许多机会，其中之一是部署一个内部 AI 智能体，帮助 AW Computing 的服务组织处理重复、耗时的支持任务。
管理层希望尽快合并两家公司的服务运营，以便在 AI-to-Z 的产品组合之上，用 AW Computing 现有的产品和流程来训练 AI 智能体。但问题潜伏在表面之下——技术债务（technical debt）。在这个徽章中，你扮演 AW Computing 的 Salesforce 管理员，调查那些阻碍项目的问题并逐一清除。
AW Computing 的并购（M&A）团队已经蓄势待发，让我们开始吧！
为过去的失误买单（Pay for Past Mistakes）
两家服务团队都在使用 Salesforce，所以 AW Computing 的管理层以为这次合并会很简单。但当你和团队仔细审视 AW Computing 的 Salesforce 部署时，你发现了一个模式：关键的数据和元数据并没有想象中那么井井有条、那么干净。而数据杂乱、脏污，几乎不可能训练 AI。你发现 AW Computing 正饱受技术债务之苦。
技术债务（technical debt），简称 tech debt，指的是在项目的设计与实现阶段，没有遵循最佳实践、走了捷径所导致的结果。它会带来组织之后必须处理的种种问题——系统响应变慢、功能不完整，或者像 AW Computing 这样：数据杂乱、自动化过时。
在这些问题被处理之前，AW Computing 用 AI 进行服务现代化的计划就无法推进。
注册带有技术债务的 Developer Edition 组织（Sign Up for the Developer Edition Org with Technical Debt）
要完成这个徽章，你需要一个特殊的 Developer Edition 组织，其中包含 AW Computing 的数据和技术债务。获取这个免费的 Developer Edition，并立即将它连接到 Trailhead，这样你就能完成徽章中的挑战。注意，这个 Developer Edition 是专为本徽章的挑战设计的，可能不适用于其他徽章。务必确认你使用的是我们推荐的 Trailhead Playground 或特殊 Developer Edition 组织。
- 注册这个免费的带有 AW Computing 技术债务的 Developer Edition 组织。
- 在 Email 字段输入一个有效的邮箱地址。
- 在 Username 字段输入一个看起来像邮箱地址、且唯一的用户名，但它不需要是真实邮箱账号（例如 yourname@example.com）。
- 填写完表单后，点击 Sign me up，会出现一条确认消息。
- 收到激活邮件（可能需要几分钟）后，打开并点击 Verify Account。
- 设置密码和密保问题完成注册。提示：把用户名、密码和登录 URL 保存在安全的地方——比如密码管理器——方便日后访问。
- 现在你已经登录到你的 Developer Edition。
将新 Developer Edition 组织连接到 Trailhead（Connect Your New Developer Edition Org to Trailhead）
把组织连接好之后，就可以开始动手挑战了。
- 确认你已登录 Trailhead 账号。
- 在本页底部的 Challenge 区域，点击组织名称，然后点击 Connect Org。
- 在登录界面，输入你刚设置的 Developer Edition 的用户名和密码。
- 在 Allow Access? 界面，点击 Allow。
- 在 "Want to connect this org for hands-on challenges?" 界面，点击 Yes! Save it。你会被重定向回挑战页面，随时可以用新的 Developer Edition 来赢取这个徽章。
现在你已经连接好组织、也拿到了凭据，接下来学习如何管理技术债务。在进入下一个单元前，记得勾选 Check Challenge to Earn 500 Points。
02 关闭安全漏洞（Close Security Gaps）
本单元正面处理技术债务。学完本单元，你将能够：对技术债务活动进行优先级排序、解释 Salesforce 安全中的最小权限原则，并标准化用户访问权限。
直面技术债务（Face Technical Debt Head-On）
无论是新手还是经验丰富的 Salesforce 管理员，技术债务都可能令人望而生畏。再加上故障自动化、多余权限、不完整的自定义等等——事情会显得非常混乱。很难弄清楚该从哪里下手。所以，让我们拆解一下 AW Computing 的技术债务类型，以及如何对修复这些问题进行优先级排序。
- 一个"精简（lite）"案例视图被部署给了管理层，还误部署给了服务团队的部分人员。这带来了混乱，并催生了一堆"添加字段"的请求，好让服务团队的每个人都能拿到所需信息。
- 重复字段被发布到了生产环境，它们捕获相同或相似的数据。有的团队成员在标准字段里录数据，有的在自定义的重复字段里录。甚至还有标着"test"和"Noah's notes"的字段。
- 给高管团队成员的权限打开了环境，带来进一步的部署和安全风险。随着组织成长，那些拥有特权的人很容易被诱惑去部署"快速修复"字段和上面提到的重复字段。
- 一些自动化构建之后就再无人维护，正造成系统臃肿。它们都用的是 Process Builder 这类老功能，你甚至怀疑当初为什么要实现它们。
总而言之，AW Computing 的 Salesforce 组织急需清理。但你不再用"乱与不乱"来思考，而是用风险来思考。
按风险排序（Prioritize by Risk）
"如果我们让这个问题继续存在，它会只是令人烦恼，还是最终会让组织崩溃、损害我们的业务？"这是一个值得问的好问题。它能帮你把问题按"应该先处理什么"的顺序组织起来。
当你深入 AW Computing 环境，你发现 Salesforce 最初是在缺乏明确治理的情况下在内部部署的。速度和增长是当时的头等大事。但由于没有明确规定的 Salesforce 维护和开发政策，一些问题随之出现。与其纠结"乱还是不乱"，不如用风险来给这些问题排序：重复字段影响报表和 AI 训练、属于高风险；多余权限是安全隐患、属于高风险；而精简视图和遗留流程的风险相对较低。
让它说得通（Make It Make Sense）
当你用风险等级来重新框定技术债务时，你就获得了组织和排序的能力。你可以评估挑战，把它们拆解成可执行的小块。而且，如果你在团队协作或向领导汇报，这种重框定能帮你引导对话，指出什么重要、为什么重要。
你可以按类别来归类：UX（用户体验）、数据与配置、安全、自动化。例如 AW Computing 的问题可以这样评估：
- "Lite"案例视图引起混乱——UX，中等风险（服务组织照常工作，但并购放缓）→ 低优先级。
- 重复且未使用的字段——数据与配置，中等风险（报表困难，团队无法正确训练 AI）→ 高优先级。
- 多余权限——安全，高风险（未来可能出现未受约束的配置和敏感数据泄露）→ 高优先级。
- 非活动和遗留流程——自动化，低风险（有些非活动可安全删除，有些适合迁移到 Flow Builder，但容量密集）→ 低优先级。
组织技术债务问题没有唯一的正确方法，也没有两个相同的组织或业务。用 1-5 分来归类优先级（1 最低、5 最高）也许更合理。而且你可以添加的考量没有上限——工作量、时间、容量也都能帮你更清楚地看到该从哪里开始，从而指导你的行动计划。
践行最小权限原则（Live by the Principle of Least Privilege）
根据你的研究和评估，权限问题是你需要最先处理的。它是个很大的安全风险，而且威胁着未来会引发更多技术债务。于是你开始动手关闭安全漏洞。
重要的是遵循最小权限原则（principle of least privilege）——只给用户完成工作所需的最少数据与功能访问权限。这对最小化安全风险、防止任何意外的用户错误至关重要。
对于 AW Computing，领导团队成员通过一个自定义配置文件（custom profile）获得了多余权限。以下是部署时本应发生的事：
- 通过标准配置文件给服务组织最小访问权限。
- 使用权限集（permission sets），根据用户的岗位增量地授予额外访问权限。
遵循这一最佳实践，即便领导团队成员通过权限集获得了额外访问权限，随着 AW Computing 的 Salesforce 实践日趋成熟，问题也会更容易被及早发现。
标准化并加固访问权限（Standardize and Secure Access）
首先，你要确保所有用户都使用限制访问的标准配置文件。
- 点击设置图标，选择 Setup。
- 在 Quick Find 框中搜索并选择 Users。
- 选择你想修改配置文件的那个用户名。
- 点击 Edit。
- 从 Profile 下拉框中选择正确的配置文件。
- 点击 Save。
对领导团队的所有用户重复上述操作……但你还没停手。
删除自定义配置文件（Delete the Custom Profile）
这个自定义配置文件已经没用了（它还给人们多余权限）。既然你已经把所有用户都分配为标准配置文件，是时候删除旧的那个了。
- 在 Setup 的 Quick Find 框中搜索并选择 Profiles。
- 在自定义配置文件旁边点击 Del。（注意：你不能删除正在使用的配置文件，所以务必确保没有用户被分配到这个配置文件。）
- 在弹出的确认框里点击 OK，确认删除这个有问题的配置文件。
你做到了！通过标准化配置文件、确保团队对案例有适当的访问权限，你提升了 AW Computing 组织的安全性。你的下一个优先事项是处理重复和多余的案例字段。
03 维护唯一事实来源（Maintain One Version of the Truth）
本单元清理重复数据和混乱的布局。学完本单元，你将能够：安排定期的技术债务清理活动、消除重复字段以实现一致的数据采集，并标准化案例布局视图。
设定技术债务管理的频率（Set a Frequency of Tech Debt Management）
在这个徽章里，你为 AW Computing 清理了有限数量的技术债务。但如果你是一个运营了很多年的组织的管理员呢？如果变更是由不同的管理员和高级用户为了实现多个组织而实施的，又该怎么办？即便你能拆解这些问题，你可能会发现清单非常庞大。虽然很容易气馁，但要振作起来。
要理解的是：存在少量技术债务是可以接受的。0% 在理论上很好，但记住，业务在增长、团队在变动、优先级在改变。这意味着项目可能启动后又被搁置，其他工作可能优先级更高，技术也在不断演进。
在现实世界管理技术债务，本质上是权衡取舍。所以，回到那个问题："什么可以保留，什么会让组织或业务崩溃？"你的清单可能很庞大，但你可以通过设定一个节奏（cadence）来从容处理它——根据手头的问题，把它做成每月或每季度的任务。
对于 AW Computing，你和服务团队及 M&A 团队进行了一系列对话来帮助你调查问题。在那些不适用的情况、或者你想更主动地管理技术债务时，你可以使用 Org Check——来自 Salesforce Labs 的免费工具，可在 AgentExchange 上获取。
调查数据问题（Investigate Data Issues）
根据你与服务团队利益相关者的对话，AW Computing 的数据混乱源于 Case 对象上一系列捕获状态和优先级信息的重复字段。这些字段的数据同时扰乱了服务流程和报表。下面是你如何评估 Case 对象：
- 在 Setup 中，选择 Object Manager，然后选择 Case。
- 选择 Fields & Relationships，仔细查看这些字段。
你发现了一系列捕获这些信息的字段，既有标准的也有自定义的——重复了。你本不想给这个任务引入"范围蔓延"，但另外几个字段引起了你的注意，它们带着 fix、test 等前缀，还有一些完全没有上下文。你向团队询问了这些字段。
似乎在某些时候，团队需要某种"修复"，结果无意中引入了重复的状态和其他字段。团队还围绕服务负责人引入了其他奇怪的自定义字段。最后，团队似乎在生产环境里做了一次本应在沙盒组织里做的测试。
你又与服务团队开了一次会，梳理出哪些字段需要保留、哪些可以删除，并研究要采取哪些步骤，让组织里的数据与新标准对齐。
实施更好的数据标准（Implement Better Data Standards）
你想删除重复字段、用正确的数据更新字段，并确保每个人看到的都是唯一的事实来源。但具体怎么做，取决于系统里的记录数量、历史记录保留的重要性，以及你有多少时间。再次回到最初的问题："这会是令人烦恼，还是会让组织或业务崩溃？"
为了让 AW Computing 的并购活动尽快回到正轨，你和服务团队达成一致：如果已关闭的案例因为使用了重复字段而缺少优先级和 SLA 数据，那也不是世界末日。但重要的是确保所有未关闭的以及未来的案例都遵循新标准——从今往后，数据问题没有任何容错空间。
你把更新历史案例记录这件事排在技术债务清单的靠后位置，留到今年晚些时候再处理。更高的优先级是清理现有的案例。
导出案例的当前状态（Export the Current State of Cases）
每当你对数据模型做重大变更（比如删除现有字段）时，导出数据都很重要。你在 Setup 中操作：
- 在 Setup 中搜索并选择 Data Export。
- 选择 Export Now。
- 勾选 Case 旁边的复选框。
- 然后选择 Start Export。导出就绪后你会收到一封邮件。
在真实场景中，数据导出后，你会在电子表格中转换数据来按需更新组织。数据转换不在本徽章范围内，你可以在 Data Management 徽章中了解更多。
删除重复字段（Delete Duplicate Fields）
你已经转换了数据——用正确的字段更新了所有未关闭的案例记录。现在是时候删除那些"害群之马"，而不必担心丢失任何重要数据了。
- 回到 Setup。
- 选择 Object Manager。
- 找到并选择 Case。
- 选择 Fields & Relationships。
- 在你想删除的字段旁边点击下拉框，选择 Delete。会弹出一个提示框，说明关于数据导出、字段可恢复时长的信息。
- 确认后点击 Delete。
如果有任何自动化依赖某个字段，在它从工作流中解耦之前，你将无法删除该字段。有时你在调查中就发现了这一点；有时你漏掉了依赖关系，直到尝试删除字段时才碰到报错。
你发现了一个使用了几个字段的旧自动化，很快就会处理它们。但眼下，还有一件事要确保不再混乱：删除精简视图。
更新标准用户的页面布局（Update Page Layout for Standard Users）
精简视图是在领导团队更深度参与每个案例的时期为它设立的。随着公司成长，团队改用了不同的流程——只在需要时请求高管复核。精简视图和重复字段一样，已经没有任何用途了。你还发现了另一件事——使用 Standard User 配置文件的团队成员也有这个精简视图！让我们把这一切都修好。
- 如果还不在 Setup，先导航到 Setup。
- 选择 Object Manager。
- 找到并选择 Case。
- 点击 Case Page Layouts。
- 然后选择 Page Layout Assignments。
- 点击 Edit Assignments。
- 点击你想更改的配置文件与页面布局那一行。
- 选择 Case Layout。
- 然后点击 Save。
删除有问题的布局（Delete the Offending Layout）
现在没有配置文件再使用那个令人困惑的案例布局，你可以安全地删除它了。
- 如果还没到，先导航到 Setup。
- 选择 Object Manager。
- 找到并选择 Case。
- 选择 Case Page Layouts。
- 在你想删除的布局旁边的下拉框中选择 Delete。
- 再次选择 Delete 确认。
服务团队现在对案例有了唯一的事实来源。干得漂亮！技术债务清单上的最后一项任务——遗留自动化。
04 更新自动化（Update Automations）
本单元现代化遗留自动化。学完本单元，你将能够：把工作流迁移到 Flow Builder、移除字段与自动化之间的依赖，并弃用非活动的自动化。
现代化工作流（Modernize Workflows）
安全漏洞已关闭，案例和案例数据有了唯一的事实来源。大多数重复字段都已处理，除了那些与工作流绑定的。
说到工作流，你发现了几个问题：
- AW Computing 的所有工作流都使用遗留自动化工具 Process Builder。
- 有些流程处于非活动状态，几乎没什么上下文说明它们是干嘛的。
- 有一个活动工作流会就高优先级案例给团队发邮件，但因为太吵，所有这些邮件现在都被路由到了垃圾邮件文件夹。
你打算如何管理所有这些事项？
让它说得通（Make It Make Sense）
仅仅因为一个自动化（或任何设置）处于非活动状态或被忽视，并不意味着它没用、应该删除。重要的是先弄清楚它当初为什么被建立——也许有一个没人想到的用例。
有时你可以追查是谁创建了字段或自动化，直接去问他们。有时组织已经存在很久了，你需要做一些"侦探工作"——核对利益相关者、审查元数据。
AW Computing 就是这种情况。与你合作的服务团队成员是很棒的干系人，他们同意你删除非活动和不完整的遗留工作流。他们也想让你在高优先级案例邮件提醒上，如果能让它更有意义，就在 Flow Builder 里更新它。
迁移到 Flow（Migrate to Flow）
那个活动工作流的用例其实很有价值，只是执行得很糟糕。最初的提醒之所以变成垃圾邮件，是因为每当案例被设为高优先级它就发邮件。问题是，案例被设为高优先级的原因太多了。
一个更好的信号是：案例是否危险地接近违反 SLA。你可以把这个工作流改成：当案例有违反 SLA 的风险时提醒团队，并请求一次"swarm"（集中响应）。
第一步是把它迁移到现代自动化工具 Flow Builder。
- 在 Setup 中搜索并选择 Migrate to Flow。
- 选择你想迁移的工作流。
- 然后点击 Migrate to Flow。
- 勾选应迁移的标准条件旁边的复选框。
- 然后选择 Migrate to Flow。
迁移过程会创建一个新的 Flow，并设为非活动状态，这样你就可以在部署前按需调整和测试。
更新 Flow（Update the Flow）
接下来，你更新这个 Flow，确保提醒在真正需要时才发出。
- 在 Setup 中搜索并选择 Flows。
- 选择你想更新的 Flow。
- 点击 Record Trigger 元素将其展开。
- 然后选择 Edit。
- 在现有的 Field 中，点击 X 将其移除。
- 用期望的 SLA 字段替换它。
- 点击对应的 Value 字段，从下拉选项中选择值。
- 接着选择 Save As New Version。
- 然后选择 Save。
- 完成后选择 Activate。
现在，当案例面临违反 SLA 的风险时，团队就会收到提醒——这是一个有意义、可执行的信号。
删除非活动 Flow 版本（Delete the Inactive Flow Version）
你创建并保存了一个新版本的 Flow。通常，维护 Flow 版本很重要——它让你能回溯参考之前的迭代、把东西拉进更新的版本等等。然而，你从 Process Builder 迁移来的那个旧版本包含了与重复字段的关系。不先删除那个非活动版本的 Flow，你就无法移除这些字段。
- 在 Setup 中搜索并选择 Flows。
- 在你想管理的 Flow 最右侧的 show actions 下拉框中，选择 View Details and Versions。
- 然后在 Flow 的非活动版本旁边选择 Del。
- 选择 OK 确认。
旧版本删除后，重复字段与旧工作流之间的依赖就被清除了。
弃用活动工作流（Deprecate Active Workflows）
现在，停用遗留流程，移除所有工作流杂物。
- 在 Setup 中搜索并选择 Process Builder。
- 在 Process Builder 中，在活动流程旁边选择 Show All Versions 箭头。
- 选择流程名称，在 Process Builder 中打开它。
- 选择 Deactivate。
- 然后选择 Confirm。
- 接着选择 Back To Setup。
- 再次搜索并选择 Process Builder。
- 在你想删除的流程旁边，选择 Show All Versions 箭头。
- 然后点击 Delete。
遗留工作流清理干净后，就可以处理剩下的重复字段了。
清理剩余重复字段（Clean Up Remaining Dupe Fields）
有几个字段你之前无法删除，因为它们与这些工作流和邮件提醒相连。现在工作流都已处理完毕，剩下的就是把这些字段从邮件提醒中解耦，最后删除这些字段。具体分三步：先删除旧版工作流规则，再删除旧版邮件提醒，最后删除剩余的重复字段。
删除旧版工作流规则（Delete Legacy Workflow Rules）
- 如果接下来出现 Understanding Workflow 信息页，勾选复选框让系统不再显示该页，然后选择 Continue。
- 然后在你想移除的规则旁边选择 Del。
删除这些规则会解除那些阻止字段删除的依赖。
删除旧版邮件提醒（Delete Legacy Email Alerts）
同理，你移除遗留的邮件提醒。
- 在 Setup 中搜索并选择 Email Alerts。
- 然后在你想移除的提醒旁边选择 Del。
现在有意义的基于 SLA 的 Flow 已经生效，那些吵闹的高优先级提醒就多余了，可以删除。移除它们后，最后一批阻止重复字段删除的自动化依赖也被清除了。
删除其余重复字段（Delete The Rest of the Duplicate Fields）
现在你可以自由删除剩下的重复字段了。
- 回到 Setup。
- 选择 Object Manager。
- 找到并选择 Case。
- 选择 Fields & Relationships。
- 在你想删除的字段旁边点击下拉框，选择 Delete。会弹出提示框，说明关于数据导出、字段可恢复时长的信息。
- 确认后选择 Delete。
随着工作流、规则和提醒的依赖全部移除，删除终于成功，AW Computing 的数据模型变得干净。
你做到了！（You Did It!）
你向服务组织和 M&A 团队汇报。最后一点技术债务已被处理。恭喜！
在这个徽章中，你管理了技术债务——从安全风险到重复字段，再到遗留自动化。你采取了一种战略性的方法，像在真实场景中那样按风险对技术债务进行优先级排序。虽然没有两个组织是相同的，但你在这里学到的最佳实践能帮你应对摆在你面前的任何技术债务。