# architect 精心设计 (well-architected) - Full Documentation ## 导言 Salesforce 精心构建代表 Salesforce 和整个生态系统的专家的指导和最佳实践。感谢为良好架构贡献资源和 Knowledge 的每个人。 我们每年更新两次精心设计的文档。我们将在下一个维护时段宣布如何为“良好架构”做出贡献。 您可以随时在[此](https://sfdc.co/bxNtvh)提供对 Well-Architected 的反馈。 ## 告诉我们您的想法 帮助我们保持 Salesforce 架构合理与您相关;参加我们的[调查](https://sfdc.co/bxNtvh),以提供有关此内容的反馈,并告诉我们您接下来想要看到的内容。 > 在[这里](/docs/architect/zh-cn/well-architected/guide/contributors)阅读我们的更新计划。 ## 导言 系统通过使人们能够轻松访问和使用应用程序、让用户感觉他们正在完成更高质量的工作以及让人们希望在系统中使用应用程序来展示引人入胜的行为。 提供吸引人的行为对业务很重要,因为它直接关系到用户的采用以及整体工作人员和客户满意度。参与行为也有助于减少支持请求,并有助于提高用户功能请求的质量。 创建吸引人的行为的挑战之一是很难仅通过客观度量来衡量。相反,它是根据用户的主观体验来衡量的;用户觉得吸引人的应用程序提供了真正的价值。参与应用程序是[可访问](/docs/architect/zh-cn/well-architected/guide/compliant#可访问性)的、非侵入性的、易于理解的。他们需要最少的入职培训和培训。他们使用明确的方法来主动防止用户错误。 另一个挑战是,参与目标通常会随着系统中不同类型的用户交互而变化。例如,对于管理个案的内部用户,您可能有一组目标,对于通过网站上的表格提交信息的外部用户,您可能有一组目标。要设计参与系统,您需要仔细考虑您尝试创建的参与类型,以及用户为什么希望在您开始组装功能和页面之前参与。 与用户体验 (UX) 设计师合作将有助于您在交付引人入胜的应用程序时做出更有效的决策。从架构的角度来看,用户采用和保留是健康系统的重要组成部分。采用架构可以减少用户匆忙完成流程或跳过步骤以避免在不喜欢使用的系统中花费时间而导致数据质量问题的可能性。对于面向外部的系统,引人入胜的架构可以提高收入和留住客户,因为发现您的系统更易于使用的客户会选择与贵组织开展更多业务。 您可以通过专注于提供简化和有帮助的体验来创建更吸引人的应用程序。 ## 简化 简化的应用程序易于导航,清晰显示信息和数据输入任务,并适应各种外形规格。简化的应用程序还具有用户在其他常用应用程序中已经习惯的体验模式。例如,当用户右键单击链接时,大多数 Web 浏览器会将“在新选项卡中打开”显示为顶部选项。包含选项卡的简化应用程序将遵循相同的模式。 低效应用程序体验的影响可能远远超出单个应用程序。糟糕的应用程序体验会削弱用户的 Trust。随着更多类型的业务关键型和面向客户的应用程序转向数字渠道,这会损失公司的关键利益相关者的忠诚度。 您可以通过有意处理应用程序复杂性、外形设计和外形规格来更好地简化您的应用程序。 ### 应用程序复杂性 最小化应用程序复杂性意味着用户只能看到相关的菜单项、选项卡和导航控制。您需要创建用户组、用户权限和正确应用程序体验之间的映射。使用这些映射来了解要向给定用户提供的应用程序体验,然后确保您的应用程序具有提供这种体验所需的逻辑控制。 为用户呈现过于复杂的应用程序会导致各种不良体验: - 用户经常看到不必要或不相关的选项卡,导航到空白屏幕,并遇到禁用或阻止的链接。 - 不必要或无帮助的说明,例如“如果您的角色是 X...,请忽略此选项卡”显示在培训和支持材料中。 - 混乱的导航菜单迫使用户花费额外的时间来查找完成工作所需的项目。 这些糟糕的体验导致采用率和满意度低。 在确定应用程序复杂性的正确级别时,请考虑以下事项: - 根据用户所需工作的优先级,组织菜单、选项卡和其他导航控件。 - 避免引入用户必须单独学习的新行为,以便他们可以使用您的应用程序。 - 请勿删除对允许用户自定义用户界面各方面的功能的访问权限。 - 使用权限集提供扩展或减少导航选项。 - 简化 Lightning 页面[激活分配](https://help.salesforce.com/s/articleView?id=sf.lightning_page_getting_into_salesforce1.htm)。最小化每个应用程序的活动 Lightning 页面数量。使用动态表单、权限集和条件渲染将项目添加到应用程序中的 Lightning 页面。执行此操作,而不是维护由简档激活和分配的多个 Lightning 页面。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/engaging#简化的应用程序模式和反模式)列表显示了 Salesforce 组织中正确(和差)的应用程序复杂性管理。您可以使用这些来验证或改进您的应用程序设计。 要了解有关可帮助您管理应用程序复杂性的 Salesforce 工具的更多信息,请参阅[相关工具](/docs/architect/zh-cn/well-architected/guide/engaging#与参与相关的工具)。 ### 表格 简化的表单将信息组织成逻辑序列,支持快速数据输入,并最大限度地减少所需的步骤。它们还允许[有用](/docs/architect/zh-cn/well-architected/guide/engaging#有用)的客户端数据验证消息,并消除重复的表单提交周期。 在设计表单时考虑以下事项: - 将**相关字段分组**。对与流程或数据输入任务中的相同步骤相关的字段进行分组。删除与当前任务没有直接关联的字段。 - **尽早输入和验证数据**。需要用户输入数据的字段应尽早显示在表单中。最佳实践是在字段级别尽快显示数据格式化或缺失数据的问题(即在用户尝试导航到下一步或提交表单之前)。此外,避免在用户有机会将数据输入字段之前显示字段级错误。 - **最小化数据输入任务**。预填写或自动填写尽可能多的字段,以最大限度地减少数据输入错误并提高效率。仅要求用户输入重要或关键数据。消除任何与当前业务流程无关的数据输入。尽可能使用选项列表而不是自由格式文本字段来强制选择有效选项,并减少相同答案的变体。 - **最小化对服务器的提交**。请勿让多步骤表单多次向服务器提交数据。确保所有自定义 [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.apex_result_caching) 或 [Aura](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/controllers_server_storable_actions.htm) 组件使用客户端缓存来处理导航或分页操作。(Salesforce Lightning Experience 和 Salesforce 移动应用程序默认使用客户端缓存。)设计表单,以便用户仅向服务器提交一次数据。在提交表单之前,验证客户端的用户输入。这将最大限度地减少意外的用户提交,防止重复或脏事务在后端消耗带宽,并帮助您设计更好的[数据处理](/docs/architect/zh-cn/well-architected/guide/automated#数据处理)。 - **管理表单状态**。客户端缓存不仅有助于导航和分页等行为,还有助于最大限度地减少间歇性连接问题导致的数据丢失。有效地管理状态还意味着应用程序可以适当地编排向服务器提交的数据,防止重复事务,以及根据服务器端操作的状态向用户提供相关和及时的消息。简化的表单仅提交一次数据操作,不需要用户等待服务器上长时间运行的操作完成。 - **遵循无障碍标准**。为了最大化应用程序的受众并帮助确保它们包括所有客户,请在表单设计中强制执行[可访问性](/docs/architect/zh-cn/well-architected/guide/compliant#可访问性)标准。 简化的表单有助于提高应用程序中[的数据完整性](/docs/architect/zh-cn/well-architected/guide/automated#数据完整性),以及应用程序对用户的[帮助](/docs/architect/zh-cn/well-architected/guide/engaging#有用)。它们还可以减少支持票证和请求,因为用户能够更好地处理错误并清楚地了解他们的表单提交状态。此外,简化的表单支持快速高效的数据输入,并确保用户无需等待运行时间更长的流程才能完成进一步的工作。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/engaging#简化的应用程序模式和反模式)列表显示了 Salesforce 组织中正确(和糟糕)的表单设计。您可以使用这些来验证或改进您的表单设计。 要了解有关 Salesforce 工具的更多信息,这些工具可以帮助您构建更简化的表单,请参见[相关参与工具](/docs/architect/zh-cn/well-architected/guide/engaging#与参与相关的工具)。有关为您的用例选择正确表单工具的更具体的指导,请查看[架构师使用 Salesforce](/docs/architect/zh-cn/decision-guides/guide/build-forms#重要外卖) 构建表单的决策指南。 ### 外形规格 参与应用程序可以优雅地适应不同的设备和交互类型,或外形规格。根据设备类型,不同类型的用户交互将更容易(或更难),表单和字段的可读性将发生变化。请记住,除了屏幕尺寸之外,外形规格也是指您的用户如何与屏幕交互。越来越多的设备现在拥有触摸屏,一些用户也可能使用特殊设备实现[无障碍](/docs/architect/zh-cn/well-architected/guide/compliant#可访问性)。在设计表单时,请确保考虑这些因素。 不考虑外形规格的变化会导致各种问题,包括: - 数据质量差 - 不可用的应用程序界面 - 支持客服人员的更多故障排除或“代表”会话 - 用户采用率低、活跃用户数量少,以及应用程序“放弃”率高 要在 Salesforce 应用程序中设计跨外形规格的互操作性,请考虑以下事项: - **确定每个应用程序支持的外形规格** - **确定用户的输入方法和可访问性需求。**有关更多信息,请查看[可访问性](/docs/architect/zh-cn/well-architected/guide/compliant#可访问性)。 - **使用[标准功能](/docs/architect/zh-cn/well-architected/guide/intentional#标准与自定义功能),尽可能跨设备提供自适应体验。** - Salesforce 提供的 [Lightning 页面模板](https://help.salesforce.com/s/articleView?id=sf.lightning_page_templates.htm&type=5)默认支持不同的外形规格。如果您选择使用 Aura 开发自定义 Lightning 页面模板,开发人员将需要将外形规格信息合并到组件设计文件中。 - Salesforce 提供的[标准页面组件](https://help.salesforce.com/s/articleView?id=sf.lightning_page_components.htm&type=5)可为您处理跨支持的外形规格的渲染。如果您使用 LWC 或 Aura 创建自定义组件,开发人员将需要处理宽度感知([Aura](https://developer.salesforce.com/docs/atlas.en-us.238.0.lightning.meta/lightning/components_config_for_app_builder_width_aware.htm?q=width) 和 [LWC](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/use_width_aware) 之间存在实施差异),并在组件的设计文件中声明外形规格支持。 - **请遵循[所有设备上](/docs/architect/zh-cn/well-architected/guide/engaging#表格)**的简化表单指南。 - **为关键外形规格创建测试计划(和良好测试)。**理想情况下,您会为所有应用程序测试所有设备和外形规格。但是,为外形规格测试设置正确的设备(或设备模拟器)是一项重大投资。如果您知道某个应用程序或一组应用程序将在移动设备或平板电脑上拥有大量用户,请优先考虑在移动设备和平板电脑外形规格上对这些应用程序进行准确测试。 以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/engaging#简化的应用程序模式和反模式)列表显示了 Salesforce 组织中正确(和差)外形规格意识的外观。您可以在构建之前使用这些来验证您的设计,或者确定需要重构的页面。 要了解有关适用于有效外形设计的 Salesforce 工具的更多信息,请参阅[相关工具](/docs/architect/zh-cn/well-architected/guide/engaging#与参与相关的工具)。 ### 简化的应用程序模式和反模式 下表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。 ✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/easy-streamlined)器中,发现简化应用程序的更多模式。
| 模式 | 反模式 | |
|---|---|---|
| 应用程序复杂性 | 在您的组织中:
- 在管理员提供的默认配置中,应用程序的选项卡少于 10 个 - 没有应用程序将“禁用此应用程序中导航项目的最终用户个性化”设置为 true |
在您的组织中:
- 在管理员提供的默认配置中,应用程序通常拥有超过 10 个选项卡 - 许多应用程序将“禁用此应用程序中最终用户对导航项目的个性化”设置为真,或在组织范围内禁用自定义导航项目的权限 |
| 表格 | 在您的应用程序中:
- 字段遵循逻辑分组 - 数据输入字段以五个或更少的组显示在一起 - 在用户导航离开或提交数据之前,数据输入错误已清除并显示在字段级别 - 分页控件支持在步骤之间移动 - 数据提交仅发生一次 - 操作和导航的标签清晰 - 提供及时和可视的反馈,以确认用户操作,例如按钮单击 - 导航按钮(例如,“转到”、“下一步”和“返回”)在整个 UI 中一致放置 |
在您的应用程序中:
- 数据输入字段没有逻辑分组,需要填写表单的用户进行大量的上下文切换 - 数据输入错误包含只能由了解系统内部工作原理的人员解释的加密信息 - 数据输入错误仅在单击表单的提交按钮时显示 - 步骤和分组未明确定义,导致导航困难 - 在整个数据输入过程中多次提交数据 - 操作和导航的标签会使不熟悉基础系统功能的用户感到困惑 - 未提供用户操作的视觉确认 - 导航按钮出现在整个 UI 的任意位置 |
| 在表单逻辑中:
- 字段尽可能预填或自动填写 - 用户无需等待长时间运行的服务器端操作完成 - 自定义组件对不涉及数据操作的基于服务器的操作使用 cacheable=true
- 数据操作仅执行一次 - 在 LWC @wire 适配器中,处理所有不涉及数据操作的操作 |
在表单逻辑中:
- 可以预填写或自动填写的字段需要手动输入 - 用户必须在提交过程中停止工作,以等待服务器端操作完成 - 自定义组件集 cacheable=false |
|
| 外形规格 | 在您的组织中:
- Salesforce 提供的 Lightning 页面模板用于所有或大部分页面 - 自定义 Lightning 页面模板在 Aura 组件设计文件中使用 design:supportedFormFactors 和 design:supportedFormFactor
- 应用程序生成器中可用的自定义 LWC 或 Aura 组件在各自的设计文件中声明支持的外形规格,并实施宽度感知样式模式 |
在您的组织中:
- Classic 仍处于活动状态 - 自定义 Lightning 页面模板在 Aura 组件设计文件中没有统一使用 design:supportedFormFactors 和 design:supportedFormFactor
- 应用程序生成器中可用的自定义 LWC 或 Aura 组件未在各自的设计文件中一致声明支持的外形规格 - 在自定义 LWC 或 Aura 组件中,Salesforce 提供的界面不会实施宽度感知样式 - 在自定义 LWC 或 Aura 组件中,不同外形规格的样式完全由 CSS 中的硬编码 px 或 % 值驱动 |
| 在桌面上:
- 数据输入字段和导航控件适合屏幕,并可按照预期进行交互 - 根据页面激活分配规则,记录和应用程序页面正确显示 |
在桌面上:
- 数据输入字段和导航控件不会显示在屏幕上的预期位置 - 与数据输入字段和导航控件的交互不匹配所需行为 - 缺少页面激活分配规则意味着所有用户都可以看到相同的记录和应用程序页面 |
|
| 在手机和平板电脑上:
- 数据输入和导航控件正确显示 - 用户可以轻松输入数据 - 显示专为更小外形优化的移动导航菜单 - 紧凑布局显示在记录级别 |
在手机和平板电脑上:
- 数据输入和导航控制呈现不一致或不正确 - 用户无法轻松输入数据 - 移动导航菜单无法与桌面导航区分 - 紧凑布局未在记录级别配置 |
| 模式 | 反模式 | |
|---|---|---|
| 通知和消息 | 您的设计标准包括:
- 批准通知、吐司和通知的用例 - 吐司变体和通知的设计模式 - 错误消息的设计模式 |
如果定义了设计标准,它们不会解决错误和通知 |
| 在您的组织中:
- 通知是主要的消息传递格式 - 吐司消息使用变体 - 模式设置为粘滞的吐司消息不存在
- 通知很少使用(如果有的话) - 生成式响应始终标识使用的数据源 - 机器人在与用户的第一次交互之前清楚地标识自己 - 与生成式 AI 相关的风险免责声明会在首次交互前向用户显示 - AI 免责声明以清晰易懂的语言供用户使用 |
在您的组织中:
- 电子邮件是主要的消息传递格式 - 消息类型没有一致的方法 - 吐司消息没有一致使用变体 - 存在 模式设置为粘滞的吐司消息
- 通知是临时使用的 - 生成式回复不会识别使用的数据源 - 机器人在第一次与用户交互之前没有清楚地标识自己 - 不会向用户显示生成性 AI 风险的免责声明 - AI 免责声明没有以清晰易懂的语言呈现给用户 |
|
| 在您的应用程序中:
- 没有人员参与点,不会直接将生成式响应发送到最终用户 |
在您的应用程序中:
- 生成式响应直接发送到最终用户,无需人工参与 |
|
| 另请参阅:错误处理 | ||
| 应用程序内指导 | 您的设计标准和文档包括:
- 应用程序内指导的批准用例 - 提示和逐步解说的设计模式 - 用户、应用程序和活动应用程序内指导的明确矩阵 |
如果存在设计标准和文档,将:
- 不处理应用程序内指导 - 请勿包含显示用户、应用程序、有效应用程序内指导的明确矩阵 |
| 在您的组织中:
- “应用程序内指导之间的延迟”设置使用默认值或长于 Salesforce 提供的默认(24 小时)周期的自定义值 - 没有应用程序包含多个有效逐步解说 - 没有逐步解说的“显示时间”设置高于 10 - 未激活“任何页面、任何应用程序”或“此页面、任何应用程序”的提示 |
在您的组织中:
- “应用程序内指导之间的延迟”设置设置为短于 Salesforce 提供的默认(24 小时)期间 - 应用程序有多个活动逐步解说 - 许多逐步解说都有高于 10 的“显示时间”设置(有些的最大值为 30) - 提示是临时激活的,许多具有“任何页面、任何应用程序”或“此页面、任何应用程序”设置 |
|
| 荣誉和奖励 | 在您的组织中:
- 应用程序使用嵌入式分析向用户显示相关目标进度和生产力统计数据 - 路径庆祝仅在用户同意下启用 - 通知和消息传递包括用户识别,并在通知对象和触发通知的内容的设计中反映用户首选项 |
在您的组织中:
- 与目标进度和生产力统计数据相关的 Analytics 仅在报表或经理仪表板中可用 - 在未检查用户同意的情况下启用路径庆祝 - 通知和消息传递不包括任何类型的用户识别,或者不反映用户的首选项,并且感觉噪音或噱头 |
| 工具 | 描述 | 简化 | 有用 |
|---|---|---|---|
| 激活 Lightning 应用程序页面 | 管理页面可用性、命名、可见性和定位 | X | |
| 采用仪表板 | 查看登录历史、功能采用率和生产力 | X | X |
| 提醒 | 在会话上保留提醒,并在用户不启动的情况下显示提醒 | X | |
| 客户端缓存 Apex 方法结果 | 使用缓存的客户端数据评估性能 | X | |
| 动态表单 | 仅向用户显示必填字段和页面部分 | X | |
| 参与见解 | 监控最近的用户活动,并根据需要采取操作 | X | X |
| 应用程序内指导 | 利用提示和逐步解说进行培训和入门 | X | |
| 学习路径 | 个性化用户学习体验 | X | |
| Lightning应用程序生成器 | 创建没有代码的自定义移动和 Lightning 页面 | X | |
| Lightning数据服务 | 跨组件缓存和共享数据 | X | |
| VS Code Lightning 设计系统验证器 | 根据 SLDS 指南验证标记 | X | X |
| Lightning 页面模板 | 为不同外形构建 Lightning 页面 | X | |
| 查找筛选器 | 查找、主-详细信息和层次结构的筛选值 | X | |
| 管理多币种 | 在交易中使用多币种 | X | |
| 消息 传递 | 发送短信、Facebook Messenger 或 WhatsApp 消息 | X | |
| Mobile Publisher | 创建 Lightning 应用程序和 Experience Cloud 站点的移动版本 | X | |
| 移动就绪组件 | 构建在移动体验中表现出色的组件 | X | |
| 多语言站点 | 创建站点的不同语言版本 | X | X |
| 通知生成器 | 创建自定义通知以显示信息 | X | |
| 路径 | 指导用户完成业务流程并庆祝成功 | X | X |
| 平台缓存 | 缓存数据时提高性能和可靠性 | X | |
| 在 Lightning 应用程序生成器中预览移动应用程序页面 | 在移动设备上预览记录和应用程序页面 | X | |
| 提示 | 提醒用户系统相关问题和更新 | X | |
| 荣誉徽章 | 确认并庆祝用户的成就 | X | |
| 使用 WDC 进行识别 | 为技能背书并致谢 | X | |
| 记录类型 | 个性化业务流程、选项列表值和页面布局 | X | X |
| 声誉概览 | 认可参与和Knowledge共享 | X | |
| 限制规则 | 阻止用户访问可能包含不必要数据的记录 | X | |
| 标准页面组件 | 了解标准 Salesforce Lightning 组件 | X | |
| 翻译 | 管理全局用户的翻译 | X | X |
| 验证规则 | 在保存前验证数据是否符合指定标准 | X |
| 资源 | 描述 | 简化 | 有用 |
|---|---|---|---|
| 建筑表单架构师指南 | 评估表单设计注意事项,并选择最佳工具 | X | |
| 为不同的外形规格配置组件 | 配置组件以在桌面和手机中呈现 | X | |
| 自定义帮助内容 | 根据您的独特实施定制帮助内容 | X | |
| 默认字段值 | 定义默认、动态或静态字段值 | X | |
| 设计指南 | 创建符合最佳实践的用户界面 | X | X |
| 设计标准模板 | 为您的组织创建设计标准 | X | X |
| 设计测试技能 (Trailhead) | 计划验证和测试设计的方法 | X | X |
| 应用程序内反馈指南 | 查看指南,以收集系统内的反馈 | X | X |
| Lightning设计系统Android静态库 | 使用 Lightning 页面的外观构建本地 Android 应用程序 | X | |
| Lightning 设计系统 iOS 静态库 | 使用 Lightning 页面的外观构建本地 iOS 应用程序 | X | |
| 消息传递指南 | 交流相关信息,创造欢乐时刻 | X | |
| 消息传递类型 | 根据用户交互了解不同的消息传递类型 | X | |
| 导航指南 | 帮助用户在页面之间移动并在应用程序中定位 | X | |
| 测试网络可访问性 (Trailhead) | 使用自动和手动测试来确保可访问性 | X | X |
| 用户参与指南 | 查看入门、采用、帮助和学习指南 | X | X |
| 安全 | ||
|---|---|---|
| 安全的系统保护业务、利益相关者和数据。安全架构确保只有批准的用户才能获得访问权限,将用户访问权限限制为完成工作所必需的内容,并保护系统中的数据不被泄露。 | ||
| 组织安全性 | 会话安全性 | 数据安全性 |
| 身份验证 授权 |
会话管理 设备访问权限 威胁检测和响应 |
共享和可见性 加密的使用 |
| 合规 | ||
| 合规解决方案遵循法律和道德准则。合规架构遵守法律法规和行业标准,维护道德政策,并公平地为所有用户提供服务。 | ||
| 法律遵守 | 道德标准 | 可访问性 |
| 数据隐私 本地化 |
公司策略 人工智能 |
数据输入 导航 |
| 可靠 | ||
| 可靠的解决方案可在一系列条件下高效可靠地运行。可靠的架构在用户期望、一致执行和随业务扩展的时间和地点可用。 | ||
| 可用性 | 性能 | 可扩展性 |
| 风险管理 故障缓解 |
吞吐量 延迟 |
数据建模 数据量 |
可组合系统:
## 分离问题
*关注点分离*是软件工程和系统架构中的一个基本概念,它要求在一个更大的系统中识别各种关注点,这些关注点可以分为模块单元。要在系统中实现问题的强烈分离,需要为整个系统的应用程序逻辑和功能创建有意义的单元。更小的单元使应用程序交付和维护团队更容易理解如何以及在哪里进行更改,而对更大的系统的中断最少。更小的单元还使得解决[技术债务](/docs/architect/zh-cn/well-architected/guide/intentional#技术债务)时如何以及在哪里集中工作变得更加清晰,并有助于提高系统的整体[可读性](/docs/architect/zh-cn/well-architected/guide/intentional#可读性)。
通过面向业务能力和管理状态,您可以将问题更好地分离到您的 Salesforce 组织中。
### 功能单元
对于 Salesforce 系统,分离问题的最佳方式是应用面向业务的视角来识别和组织系统中的模块化单元(或功能)。这与专注于工程的视图不同,后者根据单位的技术功能来识别单位。分离问题的面向业务的视角需要根据代码和自定义为业务和业务用户提供的服务来组织系统中的代码和自定义。采取这种方法并不意味着忽略系统中冗余或重复技术功能的可能性。相反,这意味着技术服务被清楚地映射到最终对业务透明的组织原则。
面向业务功能有助于确保业务分析和发现团队与交付团队之间的交接尽可能简单。如果应用程序构建者不知道他们的工作单位映射到您的可组合架构中的位置,您会看到一团糟,而不是可组合的应用程序环境。业务所需的最终状态与组织中模块化单元之间的映射不明确,也会增加开发团队或供应商在系统中构建冗余功能的可能性。
请考虑以下事项,以将职能单位定向到业务能力:
- **从要完成的工作开始**。关注用户和业务本身要完成的工作 (JTBD)。JTBD 方法由 Tony Ulwick 倡导,它侧重于理解人们试图通过使用产品或服务实现的“工作”或真正目的。它比用户的角色相关任务或业务流程中的单个步骤更抽象。例如,重复检查和地址验证等任务可能属于“建立客户的单一视图”的更高级别功能。在您清楚了解这些更高级别的业务功能后,您可以开始将系统的一部分映射到它们。
- **面向功能,而不是报告结构**业务部门的内部层次结构不是有意义的功能或要完成的工作的代理。业务的内部层次结构的确对流程和团队结构有重大影响(更不用说预算了)。这些都是重要的后勤考虑。但业务的功能需求在比物流更高的抽象级别上运作。如果您正在创建模块来为报表结构提供服务,而不是为更高级别的功能提供服务,请注意,您可能必须采取额外的步骤来确定该模块与业务功能的关系。
- **迭代**。从与企业合作开始,确定哪些功能可用于最低可行产品 (MVP)。在您确定功能时,开始构建该 MVP。在构建时,确定对您正在创建的功能单元至关重要的流程、元数据和[事件或消息](/docs/architect/zh-cn/well-architected/guide/composable#消息传递和事件)。识别任何具有外部依赖性的进程、元数据和事件或消息。随着更多功能单元的设计,实施 [API 管理](/docs/architect/zh-cn/well-architected/guide/composable#api-管理)和[依赖性管理](/docs/architect/zh-cn/well-architected/guide/composable#依赖性管理)来构建彼此良好协作的单元(而不是构建孤立的单元 ) 。
以下[模式和反模式](/docs/architect/zh-cn/well-architected/guide/composable#关注模式和反模式分离)列表显示了 Salesforce 解决方案中业务功能的正确(和不佳)方向。您可以在构建之前使用这些来验证您的设计,或者确定您的系统需要重构的区域。
要了解有关 Salesforce 可用工具的更多信息,以帮助您更好地定位业务功能,请参阅[相关工具](/docs/architect/zh-cn/well-architected/guide/composable#与可撰写相关的工具)。
### 状态管理
状态管理以整个系统中不同时间点的信息移动为中心。有效的状态管理使应用程序能够以最少的计划外或不确定的结果处理复杂的数据流或交互。在模块化 Salesforce 组织中管理状态意味着为单位内部和单位之间的逻辑流构建清晰的路径,以及为计划外的执行行为构建优雅的路径。通过状态管理,可以从模块化 Salesforce 应用程序单元形成一致的逻辑流。在大多数情况下,这需要[互操作性](/docs/architect/zh-cn/well-architected/guide/composable#交互性)来构建单位之间的信息流。
松耦合单元之间管理状态的困难通常会导致 Salesforce 中的单片应用程序开发。您可以在大型“单层流”中看到这一点,这些“单层流”是为了在单个流中编排复杂的流程而构建的。另一个例子是大型 Apex 类 , 它们通过*意大利面代码* , 或一长串一次性方法来编排复杂的过程。这些类型的应用程序架构使重构和调试变得困难,并增加了新团队成员或供应商的入职时间。它们还降低了交付给企业的应用程序的价值,因为功能不可重复使用。
考虑以下事项,以在模块化 Salesforce 组织中管理状态:
- **决定何时使用有状态与无状态模式。**有状态模式会保留整个执行路径中的信息,而无状态模式不会。在松耦合的系统中,无状态模式使得组件的重构更快,副作用更少。然而,无国籍模式并非适用于所有用例。如果您正在为数据操作构建组件,状态模式有助于整个系统的数据完整性和一致性。如果您的组件满足以下任何条件,请使用有状态模式:
- 了解放置在更大的执行路径中对于组件的行为至关重要
- 组件的行为需要根据下游操作的结果进行更改(例如,需要根据下游组件的回滚/错误/成功消息更改执行)
- 组件需要等待来自外部或下游系统的响应才能完成工作
- **为状态信息创建有意义的类别。**_State_ 是一个模糊的术语,可以应用于 Salesforce 组织内部(及外部)如此广泛而深入的信息,以至于该术语本身几乎没有意义。因此,构建有状态模式的必要第一步是为系统中最重要的有状态执行路径(或各种有状态行为)创建有*意义*的类别。需要考虑的一些类别:
- 导航和表单
- 数据库操作
- 批处理和批量操作
- 错误
- **从数 [据库事务](/docs/architect/zh-cn/fundamentals/guide/architecture-basics#数据库操作)的角度定义数据相关的状态**。平台的内置行为将限制 Salesforce 中数据的大多数状态注意事项。请勿尝试针对或规避此行为。为它设计并使用它。设计最小化或消除分布式事务逻辑的解决方案。(有关更多详细信息,请参阅[数据处理](/docs/architect/zh-cn/well-architected/guide/automated#数据处理))。
- **识别功能单元内部(和之间)发生的状态。**当您将功能单元组装成更大的系统时,请注意您何时混合了无状态和有状态的组件行为,并防止可能在处理中产生无限循环或间隙的组合。
- **定义切换**。请考虑组件将使用什么[消息传递或事件](/docs/architect/zh-cn/well-architected/guide/composable#消息传递和事件)模式将状态相关数据传输到系统的另一个部分。确保您正在将事务意识和[处理](/docs/architect/zh-cn/well-architected/guide/automated#数据处理)构建到组件中。请勿在切换中包含任何分布式事务逻辑。
- **创建进程图和状态之间的映射。**进程图详细说明了在不同时间点通过系统移动信息的步骤。状态图显示了信息(状态)的实际变化。使用 [Salesforce 图表](/docs/architect/zh-cn/reference-diagrams/guide/kit-of-parts)形状的元数据页脚部分来捕获流程中每个步骤中不断变化的信息状态。如果您分开进程图和状态图,请确保将它们链接起来。不应将这一概念与在设计和实施期间捕获流程或系统总体状况的当前和未来状态混淆,因为这与在系统中移动的信息无关。
下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/composable#关注模式和反模式分离)列表显示了 Salesforce 解决方案中正确(和糟糕)的状态管理。您可以在构建之前使用这些来验证您的设计,或者确定系统中需要重构的地方。
要了解有关用于管理状态的 Salesforce 工具的更多信息,请参见[工具相关可撰写](/docs/architect/zh-cn/well-architected/guide/composable#与可撰写相关的工具)。
### 关注模式和反模式分离
下表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。
✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/adaptable-separation-of-concerns)器中,发现更多关注分离的模式。
| 模式 | 反模式 | |
|---|---|---|
| 功能单元 | 在设计标准中:
- 命名约定解决了如何表示功能单元的问题 - 存在所有当前定义的功能单元(和相关命名约定)的列表 - 存在提议增加或更改职能单位的标准 |
在设计标准中:
- 设计标准不存在或未涉及功能单元和用例 |
| 在您的文档中:
- 系统横向图清楚显示组织中的功能单元 - 所有文档和实施图表都清楚地显示了组件的功能单元 - 单个组件的文档包含组件的功能单元映射 - 功能单元中的所有组件均可搜索并易于查找 |
在您的文档中:
- 组件文档不存在 - 组件文档描述了组件所属的功能单元,但这是该功能单元定义出现的唯一位置 - 您无法搜索特定功能单元和/或搜索无助于识别功能单元中的所有组件 |
|
| 在您的组织中:
- 可以快速识别指定元数据的功能单元对齐方式(例如,流、Apex 类或 Lightning 页面) - 职能单位使用业务友好术语进行标记 |
在您的组织中:
- 无法识别任何元数据的功能单元对齐 - 职能单位信息不一致或不准确 - 功能单元信息使用对业务用户毫无意义的工程术语进行标记 |
|
| 状态管理 | 在设计标准中:
- 有状态设计与无状态设计的用例很清楚 - 存在批准的无国籍通信模式 - 存在状态通信的批准模式 - 州/省的清除类别已存在 |
在设计标准中:
- 设计标准不存在或未处理状态/无国籍模式和用例 |
| 在您的文档中:
- 每个处理有状态和/或无状态通信的组件都指示已实施什么模式 - 可以搜索和查找实施特定有状态/无状态模式的所有组件 - 进程和交互图表提供有关状态类别和切换的详细信息 |
在您的文档中:
- 组件文档不存在 - 组件文档描述了实施的有状态/无状态模式,但这是定义出现的唯一位置 - 无法搜索特定模式和/或搜索无助于识别使用该模式的所有组件 |
|
| 在 Apex 中: - 保存点和回滚行为用于所有数据操作 |
在 Apex 中: - 不使用保存点和回滚行为 |
|
| 在流中: - 错误路径和使用回滚记录元素 |
在流中: - 未使用回滚记录元素 |
| 模式 | 反模式 | |
|---|---|---|
| 消息传递和事件 | 在设计标准中:
- 对于何时使用同步模式(消息传递)和异步模式(事件),存在明确的标准 - 事件和消息结构存在明确的标准 |
在设计标准中:
- 设计标准不存在,或者缺乏同步与异步模式的明确标准,以及消息或事件结构的明确标准 |
| 在您的组织中:
- 用于内部系统消息传递的平台事件被清楚地标记 - Salesforce 流工具引用全系统消息传递或事件服务 - 一致的消息传递和事件模式出现在流和代码中 |
在您的组织中:
- 用于内部系统消息传递的平台事件未明确标记或不存在 - 流和代码中出现不同的消息传递和事件模式策略 |
|
| 在 Apex 或 LWC 中:
- 自定义事件定义的范围有限(代码中未定义系统范围的事件或消息) - Apex 中的系统范围消息传递或事件服务以使它们在 Salesforce 流工具中可用的方式注释 |
在 Apex 或 LWC 中:
- 系统范围的消息和/或事件结构在 Apex 或 JavaScript 中定义 - Apex 中定义的系统范围事件或消息结构在流等工具中不可用 |
|
| API 管理 | 在设计标准中:
- 存在跨组件通信的清除协议(即 API) - 协议/API 在生成器可以搜索和查找的逻辑组中概述 - 协议/API 定义了变量数据类型、变量名称、必填或可选内容,并清楚地描述了何时使用 |
在设计标准中:
- 设计标准不存在或未定义 API 和用例 |
| 在您的文档中:
- 每个组件的文档都清楚地列出了哪些 API/通信协议已经实施 - 可以搜索特定 API 或协议,并确定实施该协议的组件 |
在您的文档中:
- 组件文档不存在 - 组件文档描述了在组件中实施的 API,但这是 API 定义出现的唯一位置 - 无法搜索特定 API 或协议和/或搜索无助于识别已实施 API 或协议的组件 |
|
| 在您的组织中:
- 内部通信的 API 消息格式和变量使用自定义元数据类型定义 - 内部通信的 API 消息格式和变量由平台事件定义 - 代码和声明性自定义引用适当的自定义元数据类型(或平台事件),以便发送或接收信息 |
在您的组织中:
- 系统组件之间的通信(代码和声明性自定义)是临时的 - API 专为 Salesforce 与外部系统之间的通信定义 |
不论您选择的软件包组织模式如何,请记住一些绝对值:
- **请勿在软件包之间重复元数据。**多个软件包需要的元数据应抽象为一个或多个声明为依赖项的软件包。
- **利用 Salesforce Platform 元数据的内置依赖性。**对于应用程序生成器,Salesforce Platform 提供的内置服务提供了大量可以快速配置的功能。其中许多服务具有内置的依赖性,使它们难以抽象为低级别的功能单元。对于给定的元数据类型,您需要了解它在[内置依赖关系](https://developer.salesforce.com/blogs/2018/06/lets-talk-deployment-and-reasons-why-they-succeed-or-fail)中所处的位置,并使用这种了解来[定义软件包依赖](https://developer.salesforce.com/blogs/2018/06/working-with-modular-development-and-unlocked-packages-part-2)链。不要通过尝试将松散耦合强制纳入具有大量内置依赖性的标准平台功能来开始软件包采用。当您达到更高的功能时,它将增加复杂性(而不是价值)。这也是另一种归入[标准和自定义](/docs/architect/zh-cn/well-architected/guide/intentional#标准与自定义功能)[反模式](/docs/architect/zh-cn/well-architected/guide/intentional#可维护性模式和反模式)的方法。从底部(最低的依赖性)向上封装元数据,并随着时间的推移进行迭代。
- **留意依赖链**。避免创建软件包依赖链,这将要求开发人员在任何时候将他们所做的更改拆分成许多不同的软件包。
- **想想什么对源控制有意义**在源控制中管理软件包有两种基本方法。第一个是单个*monorepo*,软件包隔离在文件夹中。第二个是多个存储库,软件包隔离在自己的存储库中。长期管理每种源策略都很复杂。就开发人员入门而言,垂直边界在多个存储库模式中效率更高。水平边界在单层建筑中更容易理解。同样,随着架构的成熟,您可以混合和匹配策略。
下面的[模式和反模式](/docs/architect/zh-cn/well-architected/guide/composable#可封装性模式和反模式)列表显示了 Salesforce 软件包中正确(和差)的依赖管理是什么样子的。您可以在构建之前使用这些来验证您的设计,或者确定您的系统需要重构的区域。
要了解有关适用于依赖管理的 Salesforce 工具的更多信息,请参阅[工具相关可撰写](/docs/architect/zh-cn/well-architected/guide/composable#与可撰写相关的工具)。
### 可封装性模式和反模式
下表显示了在您的组织中要查找(或构建)的模式的选择,以及要避免或针对补救的反模式。
✨ 在[模式和反模式探索](/docs/architect/zh-cn/well-architected-tools/guide/adaptable-packageability)器中,发现更多可封装性模式。
| 模式 | 反模式 | |
|---|---|---|
| 松耦合 | 在设计标准中:
- 命名约定解决了如何表示软件包单位的问题 - 可以搜索并查找所有当前定义的软件包单元(和相关命名约定)的列表 - 存在建议软件包单元添加或更改的标准 -(可选)自定义设置的所有批准的用例都清楚地列出(如果有) |
在设计标准中:
- 设计标准不存在或未处理软件包单元和用例 |
| 在您的组织中:
- 自定义元数据类型为代码和声明性自定义提供动态运行时信息 - 不存在自定义设置或自定义设置很少,并且没有与封装功能相关的设置 - 不存在自定义对象,以便为代码或声明性自定义提供动态运行时信息 |
在您的组织中:
- 使用自定义设置 - 自定义对象的存在是为了提供代码或声明性自定义的动态运行时信息 - 自定义元数据类型未用于(或未一致使用)为代码和声明性自定义提供动态运行时信息 |
|
| 在 Apex 中:
- 使用抽象或虚拟 Apex 类定义常见服务和模板代码 - 依赖于动态运行时信息的方法引用适当的自定义元数据类型 |
在 Apex 中:
- 常见服务和模板代码不易与其他类区分 - 跨类和方法的内部引用难以遵循,并且在整个代码库中不一致 - 方法没有使用一致的方法来访问动态、运行时信息,或者方法没有查询运行时行为信息的自定义对象,或者代码引用自定义设置 |
|
| 在源控制和开发环境中:
- package.xml 文件仅出现在早期阶段或概念验证项目清单中 |
在源控制和开发环境中:
- package.xml 文件用于控制元数据部署 |
|
| 在软件包中:
- 依赖于组织的解锁软件包仅用于早期阶段或概念验证实验 - 在生产或 Sandbox 中未定义非受管软件包 |
在软件包中:
- 所有软件包都是依赖于组织的解锁软件包 - 非受管软件包在生产或 Sandbox 中定义 |
|
| 依赖性管理 | 在设计标准中:
- 存在声明依赖性的标准 - 存在引入或修改依赖性的标准 |
在设计标准中:
- 设计标准不存在或未涉及如何声明依赖性 |
| 在源控制中:
- 解锁软件包的软件包版本使用别名 ( LATEST) 在 sfdx-project.json 清单中声明依赖性
- 开发人员可以从源代码控制中创建临时组织并成功部署软件包元数据 |
在源控制中:
- 解锁软件包的软件包版本在 sfdx-project.json 清单中明确声明(无 lateST 别名)
- 开发人员无法使用源代码控制成功使用临时组织 |
|
| 在软件包中:
- 软件包之间没有重复的元数据 - 对于软件包开发,所有早期开发工作都在临时组织中进行 |
在软件包中:
- 通过在不同软件包中复制元数据来规避依赖性 - 早期软件包开发发生在 Developer Sandbox 中,或者早期软件包开发不能发生在临时组织中 |
|
| 另请参阅:松耦合 | ||
| 工具 | 描述 | 分离问题 | 交互性 | 可打包性 |
|---|---|---|---|---|
| Apex REST Web Services | 通过 REST 向外部应用程序公开 Apex 类和方法 | X | ||
| Apex SOAP Web Services | 通过 SOAP 向外部应用程序公开 Apex 类和方法 | X | ||
| 变更数据捕获 | 将更改发布到 Salesforce 记录 | X | ||
| 自定义元数据类型 | 定义可重用、可自定义、可封装的功能 | X | ||
| 装饰师 | 将函数或属性公开为 api | X | X | |
| Dev Hub | 管理临时组织、第二代软件包和 Einstein 功能。 | X | X | X |
| 通用事件(传统)* | 发送与 Salesforce 数据更改无关的自定义事件 | X | ||
| Lightning数据服务 | 跨组件缓存和共享数据 | X | X | |
| Metadata API | 在 Salesforce 环境之间部署自定义 | X | ||
| 元数据覆盖范围报表 | 确定几个渠道之间支持的元数据覆盖范围 | X | ||
| MuleSoft Composer | 使用单击而不是代码为数据构建流程自动化 | X | ||
| 出站消息 | 在更新字段值时向外部端点发送消息 | X | ||
| 平台事件 | 发送包含近乎实时事件数据的安全和可扩展的消息 | X | ||
| 发布/订阅 API | 订阅平台事件、变更数据捕获或实时 Event Monitoring | X | ||
| PushTopic 事件(原有)* | 发送和接收与用户定义的 SOQL 查询匹配的数据变更通知 | X | ||
| Salesforce CLI | 与 Salesforce 组织协作时开发和构建自动化 | X | ||
| Salesforce Diagrams | 创建图表以显示业务功能和技术详细信息 | X | ||
| 适用于 Visual Studio 代码的 Salesforce 扩展(展开) | 适用于 Salesforce 开发的官方 VS Code 扩展 | X | ||
| 临时组织 | 将 Salesforce 代码和元数据部署到一次性组织 | X | ||
| 第二代受管软件包 | 为 AppExchange 开发和分发应用程序 | X | ||
| 工具 API | 为 Lightning 平台应用程序构建自定义开发工具或应用程序 | X | ||
| 解锁的软件包 | 组织元数据、封装应用程序或扩展 AppExchange 应用程序 | X | ||
| *Salesforce 将继续在当前功能范围内支持 PushTopic 和通用事件,但不打算对此技术进行进一步投资。 | ||||
| 资源 | 描述 | 分离问题 | 交互性 | 可打包性 |
|---|---|---|---|---|
| 对数字集成的初步了解 | 为连接概念开发通用语言 | X | ||
| 将域驱动的设计应用于 Salesforce | 围绕业务功能定位解决方案 | X | ||
| 第二代软件包的最佳实践 | 了解 2GP 打包模式和实践 | X | ||
| 受管软件包中可用的组件 | 了解受管软件包元数据组件 | X | ||
| 设计标准模板 | 为您的组织创建设计标准 | X | X | X |
| 事件驱动架构决策指南 | 比较事件驱动的架构模式和工具 | X | ||
| 事件反模式 | 确定使用事件时要避免的反模式 | X | ||
| 如何设计消息驱动和事件驱动的 API | 阅读 MuleSoft 开发指南中的差异 | X | X | |
| 了解要完成的作业框架 | 在 Trailhead 上探索 JTBD | X | ||
| 在 B2C Commerce 中管理全球状态 | 在组件之间轻松传递数据以保持状态 | X | ||
| 消息传递指南 | 交流相关信息,创造欢乐时刻 | X | ||
| 消息传递类型 | 根据用户交互的性质了解不同的消息传递类型 | X | ||
| 元数据类型 | 了解 Salesforce 组织中不同类型的元数据 | X | X | |
| 移动应用程序通知类型 | 了解 Salesforce 移动应用程序的通知类型 | X | ||
| 优化视图状态 | 在 Visualforce 页面中维护状态 | X | ||
| Salesforce 开发人员体验 (DX) | 在 Lightning 平台上管理和开发应用程序 | X | X | X |
| 不支持的元数据类型 | 识别在元数据 API 中不可用的组件 | X |
| 弹性 | ||
|---|---|---|
| 弹性解决方案可以很好地处理变化。弹性架构能够以可预测的方式快速恢复到预期行为和运营。 | ||
| 应用程序生命周期管理 | 事件响应 | 连续性计划 |
| 发布管理 环境策略 测试策略 |
恢复时间 分类能力 监控和警报 |
业务连续性 技术连续性 |
| 可合成 | ||
| 可组合解决方案调整快速,稳定性更高。可组合架构构建在彼此正常操作的单元中,并且可以在服务中交换和停用。 | ||
| 关注分离 | 交互性 | 可打包性 |
| 功能单元 状态管理 |
消息传递和事件 API 管理 |
松耦合 依赖性管理 |
| 触发器分类/类型 | 缓解 |
|---|---|
| 人员 | 策略 |
| 进程 | 行动手册、连续性计划 |
| 技术 | 冗余 |
| 触发器 | 缓解 | 基本 | 中间 | 成熟 |
|---|---|---|---|---|
| 新员工或离职员工的用户访问权限更改 | 服务级别协议 (SLA) 和配置或取消配置用户的要求 | 根据手动更改的 SLA,手动配置和取消配置用户。 | 根据计划更改的 SLA,通过计划作业处理用户更改。 | 通过 SSO/IDM 解决方案自动配置和取消配置用户。 |
| 模式 | 反模式 | |
|---|---|---|
| 风险管理 | 在您的业务中:
- 正在使用既定风险评估框架。 - 风险分为人员、流程和技术领域。 |
在您的业务中:
- Salesforce 的风险评估框架是临时的。 - 风险未明确识别。 |
| 在您的文档中:
- 根据客户影响对风险严重性进行分类和评估。 - 风险缓解和应对计划优先。 |
在您的文档中:
- 评估风险严重性或类别时,不考虑客户视角。 - 风险缓解和响应计划尝试捕获可以想象的每个风险。 |
|
| 故障缓解 | 在您的组织中:
- 故障点触发器及其相应的缓解计划按人员、流程和技术分类。 - 缓解控制立即到位,随着时间的推移而成熟,并尽早纳入自动化。 - 为了确保最佳可扩展性,在将更改发布到生产之前,需要完成全面的测试和优化。 - 在业务关键事件之前,根据 SLA 进行规模测试和优化。 |
在您的组织中:
- 故障点触发器未分类。缓解方法不存在或仅临时使用。 - 缓解控制措施未重新审核或改进。 - 自动化不用于缓解。 |
| 监控和可观察性 | 在您的组织中:
- 对于检查和异常检测,启用 Proactive Monitoring。 - 为保持可见性,Proactive Monitoring 警报与规模中心集成。 |
在您的组织中:
- 仅执行手动健康检查,没有持续监控。 |
| 模式 | 反模式 | |
|---|---|---|
| 吞吐量 | 在设计标准中:
- 有关如何使用平台缓存的指导符合平台缓存最佳实践 |
在设计标准中:
- 如果平台缓存使用有指导,则不清楚或与最佳实践不一致。 |
| 在您的组织中:
- 批量化用于数据和系统操作。 - DML 或数据库方法始终针对 Apex 中的集合进行操作。 - DML 期间用于缩短数据库中已过去时间的字段有限。 - 所有通配符条件在 SOSL 中使用。 - SOQL 语句具有选择性: -- 它们不使用 LIKE 比较或部分文本比较。 -- 比较运算符使用正逻辑(换句话说,INCLUS 或 IN)作为其主要逻辑或唯一逻辑。 --= NULL 和 != NULL 仅用于很少总是跟在正比较运算符后面的。 – 为了最大限度地减少数据负载和最大限度地提高性能,仅检索 SOQL 查询中所需的字段。 -- 不使用 LIMIT 1 语句。 -- 不使用 ALL ROWS 关键字。 - 尽可能支持异步处理。 - 配置平台缓存分区。 |
在您的组织中:
- DML 语句未批量化。 - DML 或数据库方法针对 Apex 中的单个记录进行操作。 - SOSL 很少或没有一致地用于通配符选择条件。 - SOQL 语句是非选择性的: -- 它们包括 LIKE 和通配符筛选条件。 -- 使用 !=、NOT 或 NOT IN 条件的比较用作主要或唯一比较运算符。 -- 使用 = NULL 和 != NULL 条件作为主要或唯一比较运算符。 -- 使用 LIMIT 1 语句。 -- 使用 ALL ROWS 关键字。 - SOQL 显示在循环中。 - 支持同步进程。 |
|
| 延迟 | 在您的组织中:
- 报表服务于单一特定目的,并包含决策所需的最小行数和列数。 - 筛选器使用“等于”和“不等于”。 - 筛选器不包含公式字段。 - 共享模式尽可能简化。 - 自定义 UI 组件使用 Lightning Web 组件 (LWC)。 - LWC 使用 Lightning 数据服务进行数据操作。 - 排序和筛选列表数据在客户端使用 JavaScript 处理。 - Salesforce Edge 已启用。 |
在您的组织中:
- 报表用于多种目的,或包含决策不需要的额外行和列。 - 筛选器使用“contains”(包含)和“not contain”(不包含)。 - 筛选器包含公式字段。 - 共享模型很复杂。 - 自定义 UI 组件使用的框架可能会导致呈现效率低于 LWC(例如 Aura 或 Visualforce)。 - LWC 使用 Apex 进行数据操作。 - 使用 Apex 在服务器端处理列表数据的排序和筛选。 - Salesforce Edge 未启用。 |
| 模式 | 反模式 | |
|---|---|---|
| 数据建模 | 在设计标准中:
- 存在业务理由支持自定义对象的标准和指南。 |
在设计标准中:
- 不存在创建自定义对象的标准。 |
| 在您的数据模型中:
- 尽可能使用标准对象。 - ApexGuru 对反模式的检查确认 SOQL 查询是选择性的,并避免低效的模式使用。 - 表格因规模而去标准化。 |
在您的数据模型中:
- 您已复制标准对象。 - 表格标准化,以避免冗余。 |
|
| 在您的业务中:
- 低代码生成器了解 Salesforce 支持的不同字段类型,并在选择字段数据类型之前评估报表和加密要求。 - 在决定建立对象之间的主-详细信息关系之前,您需要评估该关系的共享和数据偏差影响。 |
在您的业务中:
- 低代码生成器选择数据类型,而不评估下游报告和加密要求。 - 在决定建立对象之间的主-详细信息关系之前,您不会评估该关系的共享和数据偏差影响。 |
|
| 数据量 | 在您的数据中:
- 没有父级记录包含超过 10,000 个子级记录。 - 没有用户被分配到超过 10,000 个相同对象类型的记录。 - 实例不包含超过 10,000 个具有指向相同记录的查找字段的记录。 - 根据 ParentId 字段值,批量数据加载会分批排序。 - 为了确保批处理策略不会在并发下中断,扩展测试用于验证生产规模的批量加载模式。 - 将数据批量加载到生产中不会在高峰工作时间发生。 - 批量数据加载仅包含业务决策所需的最少数据。 |
在您的数据中:
- 存在超过 10,000 个子记录的记录。 - 用户被分配到超过 10,000 个相同类型的记录。 - 存在超过 10,000 个记录具有指向相同记录的查找字段的实例。 - 批量数据加载不会根据 ParentId 字段值进行批量排序。 - 将数据批量加载到生产中发生在工作高峰时段。 - 批量数据加载不限于业务决策所需的最少数据。 |
| 在 Flow 和 Apex 中:
- 在数据偏差令人担忧的情况下,存在在多个父级记录之间分配子级记录数量的逻辑。 - 当通过集成导入或复制记录时,逻辑会将它们分配给适当的人工用户。 - 对于 Apex 集合,例如列表和集,存在处理多个记录的逻辑,以最大限度地减少查询并优化数据处理。 - 编写和部署遵循可扩展代码标准和最佳实践的高效 Apex 代码。 |
在 Flow 和 Apex 中:
- 子记录被任意分配给父记录,而不管已经分配的子记录的数量。 - 通过数据加载或集成创建的记录被分配给通用“集成用户”。 - 来自同一对象的多个递归 SOQL 查询处于同步事务中,导致高堆使用率。 当开发人员编写 Apex 代码时,他们会引入低效率和性能反模式。 |
|
| 在您的业务中:
- 您已记录并实施数据归档和清除策略 |
在您的业务中:
- 您没有数据归档和清除策略,或者您的策略已记录但未实施 |
| 工具 | 描述 | 可用性 | 性能 | 可扩展性 |
|---|---|---|---|---|
| 大对象 | 在平台上存储和管理大量数据。 | X | ||
| 代码扫描仪 | 扫描 Apex 代码是否存在性能问题。 | X | ||
| 自定义索引 | 使用自定义索引提高查询性能。 | X | ||
| 删除数据 | 删除不必要的数据以提高性能。 | X | X | |
| 分部 | 分区数据以限制查询和报表中的记录计数。 | X | ||
| 扩展测试 | 测试系统性能并解释结果。在部署到生产之前,为了验证可扩展性和性能,请使用 Playwright 或 JMeter 脚本模拟大规模 UI 和 API 工作负载。 | X | X | |
| 比例中心 | 获取关于系统性能的自助和实时见解。查找长时间运行的事务、异常热点和吞吐量瓶颈。在开发周期的早期诊断规模问题。 | X | X | |
| ApexGuru | 在 Scale Center 中使用此基于 GenAI 的功能,以在运行时检测 Apex、SOQL 并测试类反模式。通过 ApexGuru 与 Salesforce Code Analyzer 的集成,在开发工作流中获得 AI 支持的推荐和内联修复。使用这些建议和修复来解决热点问题,并提高查询选择性、批量化、缓存使用和测试质量。 | X | X | |
| Salesforce 代码分析器 | 使用 IDE、CLI 或 CI/CD 扫描代码,以确保符合最佳实践。通过 Salesforce Code Analytics 与 ApexGuru 的集成,直接在开发人员工作流中获取有关性能反模式的见解。 | X | ||
| Salesforce Edge 网络 | 通过 Salesforce Edge 网络路由 My Domain,改善下载时间和用户体验。 | X | ||
| 瘦桌子 | 避免在具有频繁使用字段的表上连接。 | X | ||
| 主动监控 | 持续监控记录增长、所有权倾斜和性能回归中的异常。在规模问题变得重要之前发出警报。 | X | X |
| 资源 | 描述 | 可用性 | 性能 | 可扩展性 |
|---|---|---|---|---|
| 规模挑战成本数百万 — 以下是如何面向未来发展业务 | 了解实施可扩展性如何实现可持续增长和长期成功。 | X | X | |
| 使用规模中心构建和部署可扩展应用程序 | 了解如何主动评估和解决 Salesforce 实施中的性能问题。 | |||
| 分析复杂 Salesforce 应用程序中的性能和规模热点 | 解决贵组织中的性能和可扩展性问题。 | X | X | |
| 在交通高峰时段,应用程序不应惊慌 - 以下是如何准备 | 了解成功规模测试的四个关键步骤。 | |||
| ApexGuru AI 引擎解释 | 了解 ApexGuru 如何使用自定义训练模型、真实组织遥测和智能筛选来提供精确、上下文和可操作的见解。 | X | X | |
| 使用 ApexGuru 优化 Apex for Apps 和 Agentforce | 了解 ApexGuru 如何帮助开发人员检测和修复性能反模式,包括 SOQL、DML、调试和测试低效率。 使用 ApexGuru 作为 AI 支持的教练,以进行应用程序的可扩展开发和 Agentforce 的实施。 | X | X | |
| ApexGuru 反模式 | 了解 ApexGuru 检测到的反模式的官方库,该库会在每个主要 Salesforce 版本中更新。 | X | X | |
| 大数据量部署的最佳实践 | 了解大数据量对流程的影响。 | X | ||
| Salesforce Edge 网络的注意事项 | 了解如何准备贵组织使用 Salesforce Edge 网络。 | X | ||
| 设计标准模板 | 为您的组织创建设计标准。 | X | X | X |
| 数据模型设计注意事项 | 为规模和维护优化数据模型。 | X | X | |
| 设计企业级的记录访问权限 | 通过配置优化访问控制性能。 | X | ||
| 大数据量系统的基础架构 | 了解支持大数据量部署的系统性能的功能。 | X | ||
| 适用于批处理的学习资源 | 了解批次管理。 | X | X | |
| Lightning Experience 性能优化 | 改善贵组织中的 Lightning Experience,以帮助用户更快地工作。 | X | ||
| 在 Salesforce 中管理查找偏差以避免记录锁定异常 | 了解如何最小化查找偏差的影响。 | X | X | |
| SOQL 和 SOSL 最佳实践 | 对于大数据量部署,遵循 SOQL 和 SOSL 最佳实践。 | X | X | |
| 大规模重新校准的工具 | 有效计划和执行重新校准。 | X | ||
| 使用 Mashups | 在不同的应用程序中维护大型数据集。 | X | X |
| 模式 | 反模式 | |
|---|---|---|
| 数据隐私 | 在您的文档中:
- 您拥有包含字段级名称、描述和分类的最新数据字典 - 您拥有最新的安全矩阵,可确定哪些用户可以访问哪些数据 - 您拥有最新的设计文档,包括为满足监管要求而创建的任何自动化的标准和图表 |
在您的文档中:
- 数据字典不存在或未保持最新 - 共享和可见性文档不存在或未保持最新 - 满足监管要求的自动化设计标准、图表和文档不存在或未保持最新 |
| 在您的组织中:
- 所有包含敏感信息或受数据隐私条例约束的对象和字段都配置了合规分类、数据所有者、数据敏感级别和字段使用情况 |
在您的组织中:
- 包含敏感信息或受数据隐私条例约束的对象和字段缺少合规分类、数据所有者、数据敏感级别或字段使用情况的配置 |
|
| 本地化 | 在您的文档中:
- 您的组织策略概述了数据的存储和维护位置,以符合所有适用的数据驻留要求 - 您有一个集成策略,它概述了跨境复制数据的可接受场景和流程 - 您有一个概述区域、国家和全球级别的粒度报表和仪表板的分析策略 |
在您的文档中:
- 您没有组织策略,或者您的组织策略没有解决数据本地化和驻留要求 - 您没有集成策略,或者您的集成策略没有解决数据本地化和驻留要求 - 您没有 Analytics 策略,或者您的 Analytics 策略没有解决数据本地化和驻留要求 |
| 模式 | 反模式 | |
|---|---|---|
| 公司策略 | 在设计标准中:
- 标准包含受公司政策影响领域的明确指导 |
在设计标准中:
- 设计标准不存在,或未对受公司政策约束的领域提供明确指导 |
| 在您的文档中:
- 配置和自定义文档包括对受支持公司值的引用 |
在您的文档中:
- 配置和自定义文档不引用公司价值或策略 |
|
| 在您的组织中:
- 受公司策略相关合规性约束的所有对象和字段都配置了合规性分类、数据所有者、数据灵敏性级别和字段使用情况 |
在您的组织中:
- 受公司策略相关合规性约束的对象缺少合规性分类、数据所有者、数据灵敏性级别或字段使用情况的配置 |
|
| 人工智能 | 在设计标准中:
- AI 应用程序的策略和批准的用例清晰易懂 - 确保用于 RAG 的数据和文档具有代表性、完整性、准确性和最新性。查找数据集或文档中可能存在的偏见、毒性和其他有害内容 - 生成式响应始终识别 AI 模型使用的数据源 - 已记录可用于/不可用于提示工程的数据集 - 向用户明确识别机器人和生成式 AI 响应 - 明确定义了何时及如何使用生成式 AI 免责声明的标准 - 对如何记录 AI 解决方案设计中的人员参与点有明确要求 - 存在用于记录 AI 解决方案设计中直接和间接反馈路径的标准 - 必须为用户识别 AI 的点被明确界定 - 让人员掌舵,特别是在受监管或高风险用例中 |
在设计标准中:
- 设计标准不存在或不包含明确的策略和批准的 AI 应用程序用例 - 生成式响应不会识别 AI 模型使用的数据源 - 未记录用于提示工程的数据集 - 机器人和生成式 AI 响应未向用户识别 - 缺少有关生成式回复的免责声明 - 没有记录 AI 解决方案设计中人员参与点的要求 - 没有记录 AI 解决方案设计的直接和间接反馈路径的标准 - 设计标准未指明必须向用户识别 AI 的点 |
| 在您的文档中:
- 涉及 AI 功能的配置和自定义文档包含所有流程逻辑的详细描述,并存储在法律团队或审核员可以访问的中心位置 - 您构建或带到 Salesforce 的模型有明确的文档记录,包括任何适用的数据段 - 对话逻辑和客服人员对话已完整记录 - 流程到位,以监控贵组织的 AI 模型的数据漂移、公平和偏见分数的变化、准确性和稳健性 - 为所有 AI 流程使用的培训、评估和测试数据保留描述 - 保留任何 AI 相关数据清理的描述,以及偏见测试、相关结果和性能/准确性分数(例如,F1 分数) |
在您的文档中:
- 涉及 AI 功能的配置和自定义文档缺失、不完整或存储在无法访问的位置 - AI 模型或系统在贵组织中实施,但没有模型文档 - 客服人员在贵组织中实施,无需消息和对话流文档 - AI 监控流程不存在或未记录 - 有关所有 AI 流程使用的培训、评估和测试数据的信息不清楚或不可用 - 有关 AI 相关数据清理、偏见测试和结果的信息不清楚或不可用 |
| 模式 | 反模式 | |
|---|---|---|
| 数据输入 | 在设计标准中:
- 列出可用于标准键盘和鼠标之外的数据输入的所有设备 - 列出文本值及其翻译成所有支持的语言 |
在设计标准中:
- 仅列出部分或未列出可用于标准键盘和鼠标之外的数据输入的设备 - 支持的语言与要翻译的 UI 元素一起列出 |
| 在您的测试计划中:
- 测试步骤包括使用多种类型的输入设备输入数据 - 测试步骤包含多种语言的数据输入 |
在您的测试计划中:
- 不包括可访问性测试,或对可访问数据输入的测试是临时进行的 |
|
| 在您的组织中:
- 支持语言的翻译存储在翻译工作台中 |
在您的组织中:
- 翻译存储在自定义标签中 |
|
| 导航 | 在设计标准中:
- 明确列出可用于导航的所有设备(而不仅仅是标准键盘和鼠标) - UI/UX 标准指定所有导航控件的类型和样式 - 明确列出批准传达含义或状态的视觉提示类型,颜色不是主要提示 |
在设计标准中:
- 设计标准不存在或未考虑导航控制的可访问性要求 - 导航的 UI/UX 标准不一致 - 意义或状态的视觉提示依赖于颜色,或者没有生成器视觉提示的明确列表 |
| 在您的测试计划中:
- 测试步骤包括使用多种类型的输入设备进行导航 - 测试计划包括使用 UI/UX 测试来确保一致的导航路径 |
在您的测试计划中:
- 不包括可访问性测试,或对可访问导航的测试是临时进行的 |
| 工具 | 描述 | 法律遵守 | 道德标准 | 可访问性 |
|---|---|---|---|---|
| Agentforce Analytics | 深入了解客服人员的表现 | X | ||
| Agentforce 测试中心 | 运行最多 10 个测试作业,每个测试最多 1000 个测试用例,因此您可以快速创建和评估多个场景。 | X | ||
| 引用 | 引用有助于您识别生成的回复中潜在的不准确或幻觉,提高您使用 AI 工具的信心。 | X | ||
| 同意 API | 跟踪客户同意的首选项 | X | ||
| 同意事件流 | 发送同意或联系信息更改通知 | X | ||
| 同意管理对象 | 管理客户隐私和同意首选项 | X | ||
| 数据访问和可移植性 | 应要求导出客户相关数据 | X | ||
| 数据分类 | 对象字段的记录密钥合规性和审计信息 | X | ||
| Data 360 报表 | 监控客服人员指令遵守情况 | X | ||
| 数据删除 | 删除数据以遵守法律条例 | X | ||
| 数据隐私首选项 | 存储客户数据隐私首选项 | X | X | |
| 数据翻译 | 翻译向用户显示的数据 | X | X | |
| 数据检测 | 将类别和敏感度级别与实际数据保持一致 | X | ||
| Data 360 资源管理器 | 管理数据科学家的项目和对象权限 | X | X | |
| Einstein Data Prism | Salesforce 中生成式 AI 应用程序的基准解决方案,提高了使用其基准功能的 AI 解决方案的准确性 | X | ||
| Einstein Trust 层 | 旨在保护数据隐私、提高 AI 准确性并促进在整个 Salesforce 生态系统中负责任地使用 AI 的功能、流程和政策集合 | X | ||
| 增强事件日志 | 事件日志捕获客服人员会话中的事件和用户消息,以查看说明遵守情况、测试客服人员并排除故障。 | X | ||
| 文件连接 | 从 Salesforce 浏览、搜索和共享外部文件 | X | ||
| Hyperforce | 符合本地数据存储要求 | X | ||
| 元数据翻译 | 翻译语言以本地化应用程序 | X | X | |
| 可移植性 API | 编译可移植性策略中识别的客户数据 | X | X | |
| 首选项中心 | 收集客户通信首选项 | X | X | |
| 隐私中心 | 满足客户请求和数据隐私法 | X | X | |
| 数据处理限制 | 限制个人数据处理方法 | X | X | |
| 被遗忘的权利 | 应要求删除单个客户数据 | X | ||
| Salesforce 文件 | 专用共享和存储文件 | X | ||
| 安全中心 | 查看多个组织的安全性和隐私设置 | X | ||
| Shield Platform Encryption | 加密静态和传输中的数据 | X | ||
| 翻译工作台 | 维护元数据和数据标签的翻译值 | X | X |
| 资源 | 描述 | 法律遵守 | 道德标准 | 可访问性 |
|---|---|---|---|---|
| 负责任 AI 设计的 5 个原则 | 以合乎道德的方式设计人工智能 (AI) 功能 | X | ||
| 无障碍基本知识 (Trailhead) | 了解可访问性为何重要 | X | ||
| 可访问性一致性报告 (ACR) | 了解 Salesforce 如何满足可访问性标准 | X | ||
| 可访问性概览 | 了解 Salesforce Lightning 中的可访问性 | X | ||
| AI 道德成熟度模型 | 制定实施道德原则的路线图 | X | ||
| AI 红色团队:测试 Trust | 了解 Salesforce 的“道德黑客”如何通过红色团队合作开发负责任的 AI。 | X | ||
| 自动化对手:为红色团队 AI 设计可扩展框架 | 了解 Salesforce 如何自动化对抗性提示生成和响应验证,fuzani 有助于保护 AI 交互,同时减少人类接触有害内容的风险。 | X | ||
| 对话设计的最佳实践 | 在设计聊天机器人时遵循最佳实践 | X | X | |
| 可持续设计的最佳做法(Trailhead) | 将可持续性融入您的设计 | X | ||
| 同意管理 | 跟踪并遵守同意和选择退出请求 | X | ||
| Einstein的数据策略 | 控制 Einstein 功能中的数据使用 | X | X | |
| 设计标准模板 | 为您的组织创建设计标准 | X | X | X |
| 符合道德的黑客实践在构建可信 AI 产品方面证明是成功的 | 通过测试恶意使用、故意完整性攻击、良性滥用以及识别负责任的 AI 问题,了解 Salesforce 如何使用红色团队合作来提高 AI 产品的安全性。 | X | ||
| 符合道德的领导和业务 | 对技术、平等和道德的见解 | X | ||
| 符合道德的使用策略 | 了解 Salesforce 关于产品和服务道德使用的政策 | X | ||
| 设计的伦理学(Trailhead) | 将道德设计融入技术发展 | X | ||
| 探索 Salesforce 的文化和价值观 (Trailhead) | 探索 Salesforce 的核心价值 | X | X | |
| 遵循无障碍移动设计指南 | 遵循最佳实践,使您的设计可访问 | X | X | |
| 开始使用网络可访问性 (Trailhead) | 了解如何访问网站和应用程序的基础知识 | X | ||
| Salesforce 如何构建可重复的红色团队基础设施 | 在设计、实施和执行对抗性测试时,我们推荐四个组件 | X | ||
| 如何运行结果扫描研讨会 | 在创新时考虑所有可能的结果 | X | ||
| 实施数据保护和隐私 | 评估数据保护和隐私要求 | X | ||
| 包容性设计 (Trailhead) | 通过包容性设计原则促进创新 | X | X | |
| KPI 电子表格模板 | 为您的组织设置关键绩效指标 (KPI) | X | ||
| 法律信息 | 探索 Salesforce 的法律信息中心 | X | ||
| LWC Cookie 同意模块 | 控制 Experience Cloud 站点中的用户 Cookie 访问权限 | X | X | |
| 隐私概览 | 按地区和行业了解数据隐私 | X | ||
| 促进负责和讲道德的客服人员 | 了解如何实施道德的红色团队和测试策略,并为贵组织制定指导原则和标准。 | X | ||
| 负责任的客服人员 AI 指南 | X | |||
| 负责地创建 AI Trailhead 模块 | 了解如何从数据和算法中消除偏见,以在贵公司创建符合道德的 AI 系统。 | X | ||
| 负责任的生成式 AI 指南 | 我们在可信 AI 原则的基础上提出了一套新的准则,侧重于负责任地开发和实施生成式 AI。 | X | ||
| Salesforce 合规认证 | 查看 Salesforce 的合规认证和证明 | X | ||
| 可持续设计 (Trailhead) | 加强企业与社会的关系 | X | ||
| 测试网络可访问性 (Trailhead) | 利用自动和手动测试来确保可访问性 | X | ||
| 受信客服人员 AI | 了解 Agentforce 如何使用保障措施和负责任的 AI 原则来创建符合道德的 AI。 | x |
| 模式 | 反模式 | |
|---|---|---|
| 身份验证 | 在设计标准和文档中:
- 明确定义并列出批准的安全角色 - 安全矩阵中存在安全角色和允许的身份验证方案(UI、API)之间的映射 |
如果存在设计标准和文档,它们:
- 不包括安全角色 - 请勿包含具有安全角色和允许身份验证方案明确映射的安全矩阵 |
| 在您的组织中:
- 登录配置符合 Salesforce MFA 检查 - 登录 Salesforce 的用户和实体之间的关系是 1:1(没有共享用户) - API 访问控制阻止用户通过未经授权的连接的应用程序进行身份验证 - 如果启用了 SSO,批准的管理员用户具有直接登录访问权限 |
在您的组织中:
- 登录配置与 Salesforce MFA 检查不一致 - 登录 Salesforce 的用户和实体之间的关系不是 1:1(存在共享用户帐户) - 如果用户从防火墙后访问 Salesforce,防火墙会使用硬编码的 IP 地址来保护进出 Salesforce 的通信 - 未启用 API 访问控制 - 如果启用了 SSO,则没有批准的管理员用户拥有直接登录访问权限 |
|
| 在LWC, Apex, Aura中:
- 执行身份验证的方法使用命名凭据来处理用户名/密码流 - 用户名或密码不会以可读的格式显示在代码中(没有硬编码的值或字符串) - 如果存在自定义登录流,所有相关自定义代码会使用适当的 SessionManagement 方法 |
在LWC, Apex, Aura中:
- 身份验证是临时处理的 - 用户名和密码显示在代码中 |
|
| 授权 | 在设计标准和文档中:
- 有权访问 Salesforce 的每个用户和系统都映射到安全矩阵中的一个或多个角色 - 安全矩阵明确列出元数据权限和分配的用户角色 - 明确列出了授予提升权限的用例,包括: -- 修改所有数据权限 -- 查看所有数据权限 |
如果存在设计标准和文档,它们:
- 不包括安全矩阵 - 未明确列出权限 - 未明确列出授予提升权限的用例 |
| 在您的组织中:
- 权限集和权限集组用于控制对元数据的访问 - 权限集和权限集组与业务功能保持一致 - 分配给用户的权限遵循安全矩阵定义 - 简档仅用于控制登录 IP 范围和登录时间 - 为每个集成配置唯一的仅 API 集成用户 |
在您的组织中:
- 权限集小组未配置为允许基于业务功能的访问权限 - 权限集是临时配置的 - 权限集是冗余的或大量重复;难以理解清晰的功能逻辑和集之间的差异 - 分配给用户的权限不遵循安全矩阵定义 - 简档包含元数据的访问控制 - 仅 API 用户未配置或在多个集成中共享 |
|
| 在 Apex 中:
- 数据库操作适当地执行字段和对象级访问权限检查,包括: -- DML 和数据库 DML 语句声明数据操作的用户或系统模式和/或 -- DML 和数据库 DML 语句在数据操作之前使用 stripInaccessible 方法
-- SOQL 和 SOSL 语句 与 USER_MODE 和 System_MODE 关键字 AND/OR 一起使用
-- stripInaccessible 方法用于筛选查询和子查询结果
-- sObject 描述结果方法(即 isAccessible、isCreateable、isUpdateable 和/或 isDeletable)被谨慎使用 |
在 Apex 中:
- DML、数据库类方法、SOQL 和 SOSL 在默认系统模式下运行 - 数据库操作未正确执行访问权限检查,包括: -- DML 或数据库类方法仅使用 isAccessible、isCreateable、isUpdateable 和/或 isDeletable 检查进行 sObject 和字段级访问
-- SOQL 查询仅使用 with SECURITY_ENFORCED 关键字进行访问限制 |
|
| 在流中(流设计安全注意事项):
- 流使用最严格的执行上下文,理想情况下是用户模式 - 子流执行安全敏感或特权数据访问,以最小化执行上下文 - 在记录触发的流中执行的限制逻辑 - 验证流输入,以确保仅将允许的负载作为输入传递 |
在流中:
- 流以系统模式或不带共享的系统模式运行,无论流执行什么操作 - 所有流逻辑都在单个大型流中执行 - 流输入未经验证,未经验证就传递给消费者 |
| 模式 | 反模式 | |
|---|---|---|
| 会话管理 | 在设计标准和文档中:
- 安全角色清楚地列出每个角色批准的会话类型和超时/持续时间设置 - 已指定登录时间(或标识为不需要) - 需要提升会话级安全性或权限的操作清晰可查 - 连接的应用程序范围和令牌管理策略清晰可查 |
在设计标准和文档中:
- 安全角色不存在或缺少有关会话类型和超时/持续时间设置的信息 - 安全策略不包含有关连接的应用程序范围或令牌管理的信息 |
| 在您的组织中:
- 会话审计显示用户仅通过预期的会话类型访问 Salesforce - 对于“仅 API 用户”访问权限,有一个清晰有效的权限集(“仅 API”权限集设置为真),并且所有集成和自动化用户都被分配 - 如果用户从防火墙后访问 Salesforce,防火墙会使用必填域的允许列表,而不是 IP 地址来保护与 Salesforce 的通信 - 非活动会话超时间隔不超过默认值(2 小时) - 启用以下所有设置: -- 设置页面的点击劫持保护 -- 非设置 Salesforce 页面的点击劫持保护 -- 跨站点请求伪造 (CSRF) 保护 -- 跨站点脚本 (XSS) 保护 -- 启用内容嗅探保护 -- 推荐人 URL 保护 -- 在用户重定向到 Salesforce 外部之前警告他们 |
在您的组织中:
- 没有定期会话审计 - 没有定义用户应该拥有哪些会话类型 - 集成和自动化用户中的“仅限 API”权限不明确或缺失 - 如果用户从防火墙后访问 Salesforce,防火墙会使用硬编码的 IP 地址来保护进出 Salesforce 的通信 - 非活动会话超时间隔超过默认值(2 小时) - 禁用以下任何设置: -- 设置页面的点击劫持保护 -- 非设置 Salesforce 页面的点击劫持保护 -- 跨站点请求伪造 (CSRF) 保护 -- 跨站点脚本 (XSS) 保护 -- 启用内容嗅探保护 -- 推荐人 URL 保护 -- 在用户重定向到 Salesforce 外部之前警告他们 |
|
| 在LWC, Apex, Aura中:
- 如果存在自定义登录流,所有相关自定义代码会使用适当的 SessionManagement 方法来分配会话级安全性 |
在LWC, Apex, Aura中:
- 如果存在自定义登录流,没有分配会话级安全性的逻辑 |
|
| 设备访问权限 | 在设计标准和文档中:
- 设备策略清晰可发现 - 安全角色明确映射到适当的设备使用情况和策略 |
在设计标准和文档中:
- 安全策略不存在或不包含有关设备访问权限的信息 |
| 在您的组织中:
- Salesforce 移动连接的应用程序配置需要在不活动后解锁 PIN/密码 - 如果业务需求需要严格控制可以访问 Salesforce Mobile 的用户,将启用 API 访问控制,并将权限集分配给 Salesforce 移动应用程序的所有用户 |
在您的组织中:
- Salesforce 移动连接的应用程序未配置为需要 PIN/密码解锁才能不活动 – 业务需求需要严格控制可以访问 Salesforce Mobile 的用户,但未启用 API 访问控制,或权限集未用于控制对 Salesforce 移动应用程序的访问 |
|
| 威胁检测和响应 | 在设计标准和文档中:
- 安全策略包含应触发响应的事件列表以及适当的响应类型 - 已为数据模型中的所有对象指定审计级别 - 记录查看 Salesforce 中可用日志的步骤 - 所有自动回复都有清晰的记录 |
在设计标准和文档中:
- 安全策略不存在或不包含有关威胁检测和警报的信息 - 自动回复的文档不存在或不清楚 |
| 在贵公司内:
- 审计数据在业务利益相关者可以理解和访问的报表中可用 - 定期审查审计历史和报告 |
在贵公司内:
- 审计数据只能通过需要主题专业知识才能访问和解释的日志文件获得 - 没有审核审计信息的流程 |
|
| 在您的组织中:
- 如果检测到异常使用,自动化可通过停用用户帐户或阻止访问资源来响应威胁 - 通知和警报被配置为通知适当的用户异常活动 - 对包含专用或敏感数据的所有字段启用字段历史跟踪 |
在您的组织中:
- 没有自动化来应对威胁 - 通知和警报未配置为通知适当用户异常活动,或存在一些与异常活动相关的通知和警报,但它们是临时的 - 未始终为包含专用或敏感数据的字段启用字段历史跟踪 |
| 模式 | 反模式 | |
|---|---|---|
| 共享和可见性 | 在设计标准和文档中:
- 安全矩阵概述每个用户角色有权访问的数据 - 对外部用户和内部用户使用不同的数据访问标准(如果适用) |
在设计标准和文档中:
- 设计标准和文档不存在或不包含安全矩阵 - 如果存在安全矩阵,则不会概述用户角色的数据访问权限 |
| 在您的组织中:
- 由于合规性要求,内部用户的组织范围默认设置 (OWD) 是公用读取,或内部用户的 OWD 是专用 - 外部用户的 OWD 是专用的 - 生成式 AI 仅在用户模式下操作,或选择用于系统访问的用途具有明确的业务理由 |
在您的组织中:
- 内部用户的 OWD 设置为专用,没有业务理由,或者内部用户的 OWD 设置为公用读/写 - 外部用户的 OWD 设置为专用以外的任何内容,而没有业务理由 - 生成式 AI 在无业务理由的系统模式下运行 |
|
| 在 Apex 中:
- 访问数据 (SOQL/SOSL) 或执行数据操作 (DML/Database Class 方法) 的所有代码 与共享关键字一起使用 |
在 Apex 中:
- 共享关键字的使用不一致 |
|
| 使用加密 | 在设计标准和文档中:
- 传输中和(如果需要)静态数据加密的用例清晰易懂 - 明确列出批准的加密协议 - 代码文档明确指出加密的使用位置和使用的协议 |
在设计标准和文档中:
- 批准的加密协议不明确或未列出 - 代码没有文档记录,或者文档记录不清楚在代码中使用加密的位置和方式 |
| 在您的组织中:
- 如果发现安全风险需要更大的静态数据保护,Hyperforce 或 Salesforce Shield 会提供静态加密 |
在您的组织中:
- 业务需求需要更大的静态数据保护,但未使用 Hyperforce 或 Salesforce Shield |
|
| 在 Apex 中:
- 如果业务需求需要在传输过程中加强数据保护,集成涉及的所有代码都会使用加密类方法执行逻辑,以在传输前加密数据或在接收时解密数据 |
在 Apex 中:
- 业务需求要求在传输过程中加强数据保护,但集成涉及的代码在传输前或接收时执行逻辑而不加密数据,或者临时使用加密类方法 |
| 工具 | 描述 | 组织安全性 | 会话安全性 | 数据安全 |
|---|---|---|---|---|
| Apex 加密类 | 在 Apex 中加密和解密数据 | X | ||
| API 访问控制 | 管理对 Salesforce API 和连接的应用程序的访问权限 | X | X | X |
| API 异常事件 | 跟踪用户如何进行 API 调用的异常 | X | ||
| 浏览器安全设置 | 保护敏感数据并监控 SSL 证书 | X | ||
| 基于证书的身份验证 | 使用唯一数字证书验证个人 | X | X | |
| 证书和密钥 | 验证来自 Salesforce 的外部网站请求 | X | X | |
| 代码扫描仪 | 扫描 Apex 代码以了解安全漏洞 | X | X | |
| 连接的应用程序 | 通过 API 和标准协议集成 | X | X | |
| 凭据填充事件 | 跟踪使用被盗用户凭据的尝试登录 | X | ||
| CSP 受信站点 | 防止代码注入攻击(即跨站点脚本) | X | ||
| 自定义登录流 | 控制用户的登录业务流程 | X | ||
| 客户身份 | 控制网站和应用程序登录和验证 | X | ||
| Data Mask | 自动屏蔽 Sandbox 中的敏感数据 | X | ||
| 调试日志 | 跟踪贵组织发生的事件 | X | ||
| 委派管理 | 将有限的管理员权限分配给非管理员用户 | X | X | |
| 设备激活 | 验证从不可信浏览器、设备或 IP 范围登录 | X | ||
| 增强事务安全性 | 拦截事件,监视和控制用户活动 | X | ||
| 字段访问权限 | 控制字段级的数据访问权限 | X | ||
| 字段审计跟踪 | 定义策略以保留归档的字段历史数据 | X | ||
| 字段历史跟踪 | 跟踪和显示字段历史 | X | ||
| Frontdoor.jsp | 允许使用现有会话 ID 和服务器 URL 进行访问 | X | ||
| Heroku Connect | Heroku 和 Salesforce 之间的双向同步 | X | ||
| Heroku Shield | 构建 HIPAA 或 PCI 兼容应用程序 | X | ||
| 高保证会话安全性 | 敏感操作需要额外安全性 | X | ||
| Identity Connect | 将用户记录映射到 Active Directory 帐户 | X | ||
| 身份验证历史 | 审计用户身份验证尝试 | X | ||
| 集成用户许可证 | 仅通过 API 授予对数据和功能的访问权限。 | X | X | |
| Lightning Login | 防止弱或忘记密码和锁定帐户 | X | ||
| 登录访问权限 | 允许支持用户以其他用户身份登录 | X | ||
| 登录取证 | 识别可能表明身份欺诈的行为 | X | ||
| 登录历史 | 监视组织和 Experience Cloud 站点登录尝试 | X | ||
| 移动设备跟踪 | 跟踪和监控移动设备对贵组织的访问权限 | X | ||
| 移动 SDK | 在独立移动应用程序中连接到 Salesforce 平台 | X | X | X |
| 监控用户权限 (Shield) | 权限集和权限集组更改 | X | X | |
| 多重身份验证 | 登录需要两种或更多验证方法 | X | X | |
| 相互身份验证 | 强制执行 SSL 或 TLS 相互身份验证 | |||
| My Domain | 配置登录页面和策略、SSO 和社交登录 | X | ||
| 命名凭据 | 指定端点 URL 和身份验证参数 | X | ||
| OAuth 授权 | 通过令牌交换授权客户端应用程序访问权限 | X | ||
| 密码策略 | 设置密码历史、长度和复杂性 | X | ||
| 权限集分配到期 | 设置权限集和权限集组分配的到期时间 | X | X | |
| 权限集事件 | 监视对权限集和权限集小组所做的更改 | X | X | |
| 权限集小组 | 支持复杂访问权限要求的捆绑权限集 | X | ||
| 权限集 | 控制用户访问元数据、功能和应用程序的方式 | X | ||
| 专用连接 | Salesforce 和 Amazon Web Services 之间的安全集成 | X | ||
| 简档 | 控制登录 IP 范围和登录时间 | X | ||
| 实时 Event Monitoring | 在 Salesforce 中监视和检测标准事件 | X | ||
| 远程站点设置 | 为 Apex 或 JavaScript 调用注册外部站点 | X | ||
| 报告异常事件 | 跟踪用户运行或导出报表方式的异常 | X | ||
| 限制规则 | 防止用户访问不必要的记录 | X | ||
| Salesforce 代码分析器 | 通过 IDE、CLI 或 CI/CD 扫描代码,以确保符合最佳实践 | X | X | |
| 范围规则 | 控制用户可以看到的默认记录 | X | ||
| 安全中心 | 查看所有组织的安全设置,并配置状态变化的警报 | X | X | |
| 安全健康检查 | 识别安全设置中的漏洞 | X | ||
| 会话劫持事件 | 通过被盗会话标识符识别未经授权的访问 | X | ||
| 会话管理类 | 自定义活动会话的安全设置 | X | ||
| 会话安全设置 | 配置会话以防范恶意攻击 | X | ||
| 设置审计跟踪 | 跟踪管理员最近的设置更改 | X | ||
| 共享设置 | 在记录级别控制数据访问权限 | X | ||
| Shield Platform Encryption | 加密静态和传输中的敏感数据 | X | ||
| 单点登录 | 通过单点登录提供对多个应用程序的访问权限 | X | X | |
| 跨域身份管理系统 (SCIM) | 通过 REST API 跨系统管理身份 | X | ||
| 威胁检测 | 使用统计信息和机器学习来检测威胁 | X | ||
| 受信 IP 范围 | 定义不需要额外验证的 IP 地址 | X | ||
| 用户访问报表 | 获取用户对象、记录和权限访问权限的统一视图 | X | X |
| 资源 | 描述 | 组织安全性 | 会话安全性 | 数据安全 |
|---|---|---|---|---|
| 共享架构指南 | 了解有关访问工具、共享模型和用例的更多信息 | X | ||
| 设计标准模板 | 为您的组织创建设计标准 | X | X | X |
| 如何构建用户安全模型 | 更好地了解用户安全模型 | X | X | |
| 如何在 Salesforce 中实施最小权限原则 | 了解在 Salesforce 中应用 PoLP 数据访问控制 | X | X | |
| 监控用户会话 | 查看有效会话并结束可疑会话 | X | ||
| 多重身份验证 | 从 Salesforce 访问官方 MFA 资源 | X | ||
| 权限集小组 (Trailhead) | 开始使用权限集小组 | X | X | |
| REST API 架构 | 了解 REST API 术语和概念 | X | X | X |
| 安全性和 SOAP API | 了解 SOAP API 术语和概念 | X | X | X |
| API 和内部系统用户的安全最佳实践 | API 用户和安全内部系统用户对 Salesforce 的安全访问 | X | ||
| 安全实施指南 | 全面了解 Salesforce 安全性 | X | X | X |
| 安全策略模板 | 为您的组织设置安全策略 | X | X | X |
| 会话类型 | 确定用于访问贵组织的会话类型 | X | ||
| 威胁建模基础知识 (Trailhead) | 了解安全威胁以及如何预防它们。 | X |
| 临时组织 | Developer Sandbox | Developer Pro Sandbox | 部分复制 Sandbox | 完全 Sandbox | |
|---|---|---|---|---|---|
| 支持组织形状 | 是 | 没有 | 没有 | 没有 | 没有 |
| 支持源跟踪 | 是 | 是 | 是 | 没有 | 没有 |
| 寿命 | 1–30 天 | 手动控制 | 手动控制 | 手动控制 | 手动控制 |
| 刷新间隔 | 不可用 | 1 天 | 1 天 | 5 天 | 29 天 |
| 发布预览支持 | 开发人员控制 | 基于 Sandbox 实例 | 基于 Sandbox 实例 | 基于 Sandbox 实例 | 基于 Sandbox 实例 |
| 配置时间 | > 5 分钟 | 小时或天 | 小时或天 | 小时或天 | 小时或天 |
| 元数据确定人 | 源控制 | 生产 | 生产 | 生产 | 生产 |
| 数据确定人 | 手动数据加载 | 手动数据加载 | 手动数据加载 | Sandbox 模板 | 生产 |
| 数据限制 | 200 MB | 200 MB | 1 GB | 5 GB | 与生产相同 |
| 任务 | 组织形状 | 源跟踪 | 频繁刷新 | 发布预览支持 | 来自生产的所有元数据 | 来自生产的部分元数据 | 来自生产的大型数据集 | 来自生产的部分数据集 | 兼容的环境 |
|---|---|---|---|---|---|---|---|---|---|
| 原型 | X | X | X | X | X | X | X | 临时组织、Developer 和 Developer Pro Sandbox | |
| 新功能调查或概念验证开发 | X | X | X | X | X | X | X | 临时组织、Developer 和 Developer Pro Sandbox | |
| 用户验收测试 | X | X | X | X | X | X | Developer、Developer Pro 和 Partial Copy Sandbox | ||
| 性能和规模测试 | X | X | X | 完全 Sandbox | |||||
| 用户培训 | X | X | X | X | X* | X | Developer Pro、部分复制和*完全 Sandbox | ||
| *如果需要完成特定类型的工作,否则使用资源密集度较低的环境 | |||||||||
| 模式 | 反模式 | |
|---|---|---|
| 版本管理 | 在生产中:
- 元数据显示了稳定发布机制的使用情况,例如: -- 元数据被组织成解锁的软件包 -- DevOps Center 已启用并安装 -- 使用源格式通过元数据 API 进行部署 - 部署日志显示可用历史记录中没有失败的部署。 - 部署历史记录显示了明确的发布节奏和发布窗口中相当统一的部署集群。 |
在生产中:
- 元数据表示使用基于组织的发布机制,例如: -- 有效使用更改集 -- 使用 package.xml 格式通过元数据 API 进行部署 - 部署日志显示可用历史记录中失败部署的重复实例。 - 部署没有明显的节奏或显示不均衡的部署集群,这是热修复和临时回滚的迹象)。 - 未启用并安装 DevOps Center。 |
| 在路线图和文档中:
- 发布名称很清楚 - 功能明确与特定的命名版本相关联。 - 发布名称可搜索和发现。 - 团队可以找到并遵循标记工件、开发项目和具有正确发布名称的其他工作的明确指南。 - 可以通过版本名称清晰地查看版本清单。 - 生成式 AI 应用程序的质量阈值是为不同的开发阶段定义的。 |
在路线图和文档中:
- 不包括发布名称。 - 功能未明确绑定到特定版本。 - 发布名称是临时使用或不存在。 - 团队以不同的方式引用工件、开发项目和其他工作。 - 使用版本名称无法清晰查看版本清单。 - 未定义生成式 AI 应用程序的质量阈值,或者如果定义,也未针对不同的开发阶段定义。 | |
| 环境战略 | 在您的组织中:
- 采用源驱动的开发和发布模式。 - 为 Developer 和 Developer Pro Sandbox 启用源跟踪。 - 给定环境中的元数据独立于发布工件。 - 环境不直接对应于发布路径。 - 变更的发布路径取决于变更的类型(高风险、中度风险或低风险)。 - 拥挤的环境不存在。 - 风险配置更改不会直接在生产中实施。 - 在工作高峰时段不会出现发布。 - Data 360 Sandbox 用于正确测试需要 Einstein 数据库、Knowledge 文章和非结构化数据的客服人员用例 |
在您的组织中:
- 采用基于组织的开发和发布模式。 - 源跟踪未为 Developer 和 Developer Pro Sandbox 启用。 - 给定环境中的元数据是发布工件。 - 环境直接对应于发布路径。 - 每个更改的发布路径相同,无论更改类型如何。 - 存在过度拥挤的环境。- 直接在生产中实施危险的配置更改。 - 发布发生在高峰工作时间。 - 需要使用 Einstein 数据库、Knowledge 文章和非结构化数据的 Agentforce 客服人员未使用 Data 360 Sandbox 进行测试 |
| 信号策略 | 在您的组织中:
- 团队协作定义和标准化健康检查 API 和 SLO。 - 定期审查和改进信号战略是事后和行动准备情况审查的一部分。 在生产中: - 对所有应用程序实施健康检查。 - 应用程序提供有关其运行状况的明确信号,例如负载和功能。 - 当依赖性不健康时,应用程序会正常降级。 - 负载脱落用于防止级联故障。 在您的设计中: - 背压和负载减少机制防止流量淹没服务。 - 假设依赖性最终失败。信号处理器旨在减少故障。 |
在您的组织中:
- 团队在孤岛中工作,创建不一致和不兼容的健康信号机制。 - 信令策略是一种事后的想法,仅在事件发生时解决。 在生产中: - 组件以静默方式失败,而不指示其健康状况。 - 应用程序会无限期重试对不健康服务的请求。 - 所有请求都以相同的优先级处理,无论其重要性如何。 - 要识别问题,运营商仅依赖反应性措施,例如用户投诉或关键系统故障。 在您的设计中: - 假设所有依赖性始终可用,并且不考虑网络分区、延迟峰值或其他常见问题。 - 应用程序接受所有传入请求,即使它们过载,也会导致延迟增加和失败的可能性增加 |
| 测试策略 | 在您的业务中:
- 可用性测试使用各种设备和辅助技术。 - 模拟器用于复制类似生产的条件,以实现可扩展性和性能测试。 - 当更改进入源控制时,测试会自动运行。 - 在应用程序开发周期中,耐久度、压力、性能和规模测试以若干间隔运行,并视为持续任务。 - 当您拥有 B2C 规模的应用程序、大量用户或大量数据时,您可以将规模测试作为 QA 流程的一部分。 - 规模测试侧重于系统的高优先级方面。 - 规模测试有定义明确的标准。 - 在完全 Sandbox 中执行规模测试。 - 即时工程包括由人工进行的质量审查。 - Agentforce 测试中心用于强大的客服人员测试。 |
在您的业务中:
- 不会进行可用性测试,或者如果进行了可用性测试,也会在有限的设备上执行。 - 不会测试类似生产的用户请求量、API 流量和网络速度的变化。 - 测试自动化不到位。 - 耐力、压力、性能、规模测试被视为一个发展阶段。 - 您没有在 QA 流程中执行规模测试,您拥有 B2C 规模的应用程序、大量用户或大量数据。 - 规模测试未确定优先级。 - 规模测试没有定义明确的标准。 - 您可以在部分复制或 Developer Sandbox 中执行规模测试。 - 提示工程不包括人工的质量审查。 - Agentforce 客服人员未测试,或者如果测试,仅使用客服人员生成器进行临时测试。 |
| 在您的组织中:
- 所有测试数据会清除敏感和识别数据。 |
在您的组织中:
- 测试数据与生产数据相同。 | |
| 在 Apex 中:
- 数据工厂模式用于单元测试 - 模拟和存根用于模拟 API 响应。 |
在 Apex 中:
- 单元测试依赖于组织数据。 - 不用嘲笑小作品 | |
| 在设计标准和文档中:
- 环境按支持的测试类型分类。 - 根据风险、用例或复杂性指定适当的测试制度。 |
在设计标准和文档中:
- 不清楚每个环境支持哪些类型的测试。 - 测试方案未按风险、用例或复杂性分类。 |
| 事件类型 | 外观触发器 | 恢复策略 |
|---|---|---|
| 系统中断 | 登录错误或帐户访问权限问题 | 客户恢复策略 |
| 服务不可用 | 激活冗余备份服务;手动解决方法 | |
| 生产错误 | 最近更改 | 部署回滚或取消部署以前的版本 |
| 一个无法解释的紧急错误 | 手动解决方法,禁用非必要功能,升级到 SME |
| 模式 | 反模式 | |
|---|---|---|
| 恢复时间 | 在您的业务中:
- 定期练习恢复协议。 - 团队知道他们拥有和负责生产中的哪些服务。 - 团队了解支持问题诊断的相关工具。 |
在您的业务中:
- 恢复协议不存在或未定期实践。 - 不清楚哪些团队拥有并负责生产中的不同服务。 - 团队没有支持问题诊断的工具指南或标准。 |
| 在您的文档中:
- 恢复策略按事件类型和触发器定义和分类。 - 事件响应的退出标准包含在 SLO 中,并且是明确的。 - 事件期间提升权限的激活条件和分配逻辑很清楚。 - 事件响应权限集和授权已明确列出。 - 存在帮助识别和诊断常见问题的故障排除指南。 |
在您的文档中:
- 事件响应是临时执行的。 - 事件响应的退出条件不存在。 - 未分配提升的权限,或者,如果是,将临时分配。 - 事件响应权限集和授权未列出。 |
|
| 在您的组织中:
- 存在基于会话的事件响应权限集,可以在恢复期间分配给支持人员。 - 设置审计跟踪显示指定的恢复测试人员在商定的时间登录测试环境,并遵循恢复测试脚本。 |
在您的组织中:
- 事件响应不存在基于会话的权限集,或者如果存在,支持人员无权使用。 - 设置审计跟踪显示指定的恢复测试人员未登录测试环境或未遵循恢复测试脚本 | |
| 在您的测试计划中:
- 存在用于恢复测试的测试脚本,并且可以重复。 - 事件模拟的环境已明确列出。 |
在您的测试计划中:
- 恢复测试的测试脚本不存在。 - 未建立事件模拟的环境。 |
|
| 分类能力 | 在您的业务中:
- 应在事件发生前确定应提醒中小企业或利益相关者支持复杂问题。 - 交付和支持团队之间的切换是上线的一部分。 - 如果咨询,Salesforce 架构师会快速响应,并帮助团队专注于恢复。 |
在您的业务中:
- 在事件发生之前,不会确定应引起警报的中小企业或利益相关者。 - 交付团队和支持团队之间的切换不是发布过程的一部分。 - Salesforce 架构师认为事件响应超出了他们的工作范围。 |
| 在您的文档中:
- 支持人员可以发现和读取给定解决方案中使用的系统和设计模式。 |
在您的文档中:
- 给定解决方案中使用的系统和设计模式对支持人员不可用。 |
|
| 在您的组织中:
- 记录和自定义错误消息被合并到整个系统的执行路径中。 |
在您的组织中: - 不使用日志记录和自定义错误消息。 | |
| 监控和警报 | 在您的组织中:
- 警报仅用于通知用户需要人为干预的场景;其他故障将被记录并报告。 - 向能够响应警报的用户发送警报。 - 在可能时,在潜在故障前发送警报。 |
在您的组织中:
- 当任何类型的故障发生时,都会发送警报,无论是否需要后续行动。 - 向业务用户提供需要技术解决方案的问题提醒。 - 仅针对已发生的故障发送警报。 |
| 在您的文档中:
- 提示调整警报的准入条件基于直接和间接生成式 AI 反馈度量定义。 |
在您的文档中:
- 没有定义触发生成式 AI 应用程序的提示调整警报的条件。 |
| 模式 | 反模式 | 业务连续性 | 在您的业务中:
- 采用“恢复优先”的思想,重点是尽快使优先级最高的业务功能和功能失去影响。 - 有一个用于审查 BCP 测试计划的维护计划。 |
在您的业务中:
- “解决问题”的心态是事件管理的唯一方法。 - BCP 测试计划不会定期刷新。 |
|---|---|---|
| 在您的文档中:
- 存在 BCP,其中包含在 Salesforce 不可用时继续处理或分类数据的步骤,触发使用 BCP 的事件列表,以及 BCP 测试的步骤和间隔。 - BCP 包括上游和下游系统和依赖性。 |
在您的文档中:
- BCP 不存在、不完整或仅包含 Salesforce。 |
|
| 在您的测试计划中:
- 考虑 BCP 中与流程和人员相关的区域。 |
在您的测试计划中:
- 未考虑 BCP 中与流程和人员相关的区域。 | |
| 技术连续性 | 在您的业务中:
- 您已评估是否需要构建有意冗余或故障转移系统 - 事件恢复策略尽可能自动化。 |
在您的业务中:
- 您没有评估有意冗余或故障转移系统的必要性 - 事件恢复策略全部是手动操作。 |
| 在您的文档中:
- BCP 考虑了团队可能需要的额外资源或打破常规的程序,以有效应对事件。 |
在您的文档中:
- BCP 不包括运营支持需求。 |
|
| 备份和还原 | 在您的文档中:
- 数据和元数据都存在备份和还原策略。 |
在您的文档中:
- 备份和还原策略不存在,或者如果存在,则不完整,仅应用于数据或元数据,而非两者。 |
| 在贵公司:
- 备份存储在只有授权用户才能访问的安全位置。 - 测试计划和测试日志显示,每年至少两次在完全或部分复制 Sandbox 中测试数据还原。 |
在贵公司:
- 备份不是人类可读的。 - 备份存储在未经授权的业务用户可以访问的位置。 - 没有数据还原过程,或数据还原过程未经测试。 |
| 工具 | 描述 | 应用程序生命周期管理 | 事件响应 | 连续性计划 |
|---|---|---|---|---|
| Apex锤子测试 | 了解当前和新版本中的 Salesforce Apex 测试。 | X | ||
| Apex 小作品 API | 构建模拟框架,简化测试。 | X | ||
| 备份和恢复 | 自动生成备份以防止数据丢失。 | X | ||
| 大对象 | 在平台上存储和管理大量数据。 | X | ||
| 字段历史跟踪 | 跟踪和显示字段历史。 | X | ||
| 获取贵组织的采用和安全见解在新窗口中打开链接 | 监控 Lightning Experience 在贵组织中的采用和使用。 | X | ||
| 管理批量数据加载作业 | 使用批量 API 创建更新或删除大量记录。 | X | ||
| 管理实时 Event Monitoring 事件 | 管理事件监控流和存储设置。 | X | ||
| 数据和存储资源 | 查看 Salesforce 组织的存储限制和使用情况。 | X | ||
| 监控调试日志 | 监视日志并设置标记以触发日志记录。 | X | ||
| 使用登录取证监控登录活动 | 识别可能表明身份欺诈的行为。 | X | ||
| 使用设置审计跟踪监控设置更改 | 跟踪管理员最近的设置更改。 | X | ||
| 监控培训历史 | 查看用户已参加的 Salesforce 培训课程。 | X | ||
| 监控后台作业 | 监视贵组织的后台作业。 | X | ||
| 监控计划作业 | 查看报表快照、计划 Apex 作业和仪表板刷新。 | X | ||
| 扩展测试 | 测试系统性能并解释结果。 | X | ||
| 主动监控 | 通过使用 Salesforce 监控服务,最大限度地减少中断。 | X | ||
| Salesforce Data Mask | 自动屏蔽 Sandbox 中的数据。 | X | ||
| 系统概览页面 | 查看贵组织的使用数据和限制。 | X | ||
| 使用 force:lightning:lint | 通过 Salesforce CLI 分析和验证代码。 | X |
| 资源 | 描述 | 应用程序生命周期管理 | 事件响应 | 连续性计划 |
|---|---|---|---|---|
| 性能和规模测试中的 7 种反模式 | 在性能和规模测试中避免常见的反模式。 | X | ||
| 分析复杂 Salesforce 应用程序中的性能和规模热点 | 了解解决贵组织中性能和可扩展性问题的方法。 | X | ||
| 制定灾难恢复计划 (Trailhead) | 构建灾难恢复计划。 | X | ||
| 业务连续性不仅仅是备份和还原 | 全面了解 BCP。 | X | ||
| 设计标准模板 | 为您的组织创建设计标准。 | X | ||
| Salesforce 中的诊断和监控工具 | 了解如何提高实施的质量和性能。 | X | ||
| 业务连续性计划的指导原则 | 查看有效 BCP 的基本原则。 | X | ||
| 如何在 Salesforce 上扩展测试 | 了解规模测试生命周期的五个阶段。 | X | ||
| 性能测试简介 | 了解如何开发性能测试方法。 | X | ||
| 监控您的组织 | 了解自助监控选项。 | X | ||
| 测试策略模板 | 创建并自定义规模和性能测试计划。 | X | ||
| 测试策略模板 | 请确保测试策略完整。 | X | ||
| 了解源驱动的开发 (Trailhead) | 了解软件包开发和临时组织。 | X |
| 模式 | 反模式 | |
|---|---|---|
| 优先级 | 在您的文档中:
- 所有新工作项目都有明确的业务价值度量(例如,收入增加、流程优化的成本节约等) - 路线图显示基于业务价值的工作优先级 |
在您的文档中:
- 与工作关联的业务价值不明确或不存在 - 路线图不存在 |
| 在贵公司内:
- 已确定所有工作项目的实施和维护费用 - 根据业务影响、交付所需的新工作量和维护所需的工作量确定功能请求的优先级 |
在贵公司内:
- 实施和维护功能的相关成本不明确 - 请求以临时或先进先出的方式传递 |
|
| 路线图 | 路线图:
- 传达专为受众定制的信息(业务或技术) - 以正确的详细程度传达信息 - 显示开始和结束日期 - 显示先决条件和依赖性 |
路线图(如果存在):
- 用作项目启动材料,而非交付的工件 - 请勿帮助利益相关者和交付团队保持一致 - 混合详细信息级别(例如,通过在同一路线图中包含系统和组件) - 包含并非针对受众定制的信息(例如,同一路线图中的业务功能和系统) |
| 在您的业务中:
- 利益相关者了解工作项目的“原因” - 交付团队知道如何根据长期优先级评估待办事项 - 团队知道谁在做什么以及如何管理依赖性 - 工作是有意的,即使优先级需要快速更改 |
在您的业务中:
- 工作从待办事项中提取,没有明确的“原因” - 团队难以协调相互依赖的工作,并且经常在不知不觉中重复工作 - 工作往往是反应性的 - 利益相关者通常对正在做的事情感到沮丧和困惑,并且对何时交付新功能感到忌惮 |
|
| 治理 | 在您的业务中:
- 用户可以轻松报告错误并请求功能 - 记录工作项目的优先级过程,并对所有利益攸关方透明 - 环境战略有明确的文档记录,开发环境与文档记录相匹配 - 发布计划可以预测,对所有交付团队成员透明 - 团队成员知道谁在整个应用程序生命周期中负责什么 - 用户和交付/维护团队清楚了解版本 - 生产支持流程清晰,热修复程序有清晰的生产路径 - 团队和项目仅使用为业务用途批准的 AI 模型 |
在您的业务中:
- 错误报表和功能请求是临时的 - 工作项目没有明确的优先级 - 环境是临时配置的,可能不会以可预测的方式刷新;开发人员通常没有他们需要的环境和访问权限 - 交付团队和用户无法预测发布 - 团队不知道谁负责什么 - 热修复是临时解决的 - 您的待办事项已成为过时和停滞的“意见库” - 治理机构充当帮助台,对支持请求进行故障排除 - 文档不容易访问 - 团队会临时选择 AI 模型 |
| 模式 | 反模式 | |
|---|---|---|
| 标准与自定义 | 在设计标准中:
- 有一个明确的指导原则来避免不必要的自定义解决方案 - 解决方案的指导原则使用以下优先级:1.使用内置平台服务,2.在构建自定义解决方案之前,请考虑 AppExchange 应用程序。在编写代码之前使用低代码自定义 |
在设计标准中:
- 设计标准要么不存在,要么没有明确的理由来避免不必要的自定义和代码 |
| 在您的文档中:
- 决策记录显示选择构建或购买解决方案时的短期和长期成本计算 |
在您的文档中:
- 决策记录在选择构建或购买解决方案时不考虑短期和长期成本 |
|
| 在数据模型中:
- 没有对象的名称或功能与标准对象重复 - 标准对象未用于超出预期范围的目的 |
在数据模型中:
- 对象与标准对象的名称和/或功能重复 - 标准对象用于远远超出预期范围的目的 |
|
| 在LWC、Aura或Visualforce中:
- 不存在覆盖标准页面视图机制的代码 |
在LWC、Aura或Visualforce中:
- 代码用于覆盖标准页面视图机制,通常以单页面应用程序的形式存在 |
|
| 在LWC、Aura或Apex中:
- 没有代码尝试覆盖或规避平台执行顺序 |
在LWC、Aura或Apex中:
- 代码尝试覆盖或规避平台执行顺序 |
|
| 技术债务 | 在路线图中:
- 计划解决技术债务问题 - 交付件和开始/结束日期明确 |
在路线图中:
- 没有计划解决技术债务问题的工作 - 交付品不明确;开始/结束日期不明确 |
| 在您的决策记录中:
- 技术前/技术后债务补救的 KPI 有明确记录 - 关于作为和不作为的权衡讨论侧重于业务成本或收益 |
在您的决策记录中:
- 技术债务补救没有可衡量的 KPI - 从技术或 IT 角度考虑技术债务,与业务无关 |
|
| 在您的组织中:
- 没有不支持的或传统技术处于活动状态,包括: -- 所有用户在 Lightning Experience 中工作 -- Apex 中没有或很少使用 @future (使用Queueable)
-- 所有第三方 Apex 属于 AppExchange 软件包 -- 没有有效的工作流规则(使用流) -- 没有有效的进程构建器进程(使用流) -- PushTopic 事件(使用变更数据捕获) -- 通用事件(使用平台事件) -- 30.0 之前的 API 版本 -- Salesforce 组织连接使用适用于 Salesforce Connect 的跨组织适配器 |
在您的组织中:
- 不支持或原有技术已启用,包括: -- 使用 Salesforce Classic 的用户 -- @future use in Apex
-- 来自非 AppExchange 源的第三方 Apex -- 工作流规则 -- 进程构建器进程 -- PushTopic 事件 -- 通用事件 -- 30.0 之前的 API 版本 -- Salesforce 到 Salesforce 的连接 |
| 模式 | 反模式 | |
|---|---|---|
| 设计标准 | 在您的组织中:
- 代码和声明性自定义具有一致的、人类可读的名称 - 数据模型的对象和字段名称一致、统一 - 审计显示字段在报表等中一致填写和引用。 |
在您的组织中:
- 代码和声明性自定义名称不一致 - 数据模型的名称不一致,许多对象和字段似乎多余 - 审计显示许多未使用的字段或各种使用级别,并且没有与报告等一致的链接。 |
| 在您的业务中:
- 团队知道使用(和不使用)什么工具完成工作 - 批准的设计模式易于按用例查找和识别 - 批准的 AI 模型被明确识别,并包含预期目的 |
在您的业务中:
- 团队使用许多不同的工具完成类似的工作 - 没有批准的设计模式 - 供应商或新员工入职需要大量时间 - 批准的 AI 模型未明确识别,预期目的不明确 |
|
| 文档 | 在您的组织中:
- 代码和声明性自定义有明确的描述 |
在您的组织中:
- 代码和声明性自定义没有描述,有难以理解的描述,或描述似乎与自定义的实际功能不匹配 |
| 在您的业务中:
- 所有解决方案都有业务功能和技术实施详细信息的图表 - 为代码和声明性自定义设置关键信息日志 - 人员可以搜索并查找相关文档 |
在您的业务中:
- 解决方案的内容/方式/原因很难找到,并且可能对大多数团队不可用 - 人们很难理解解决方案和他们正在使用的系统 - 供应商或新员工入职需要大量时间 |
| 工具 | 描述 | 策略 | 可维护性 | 可读性 |
|---|---|---|---|---|
| ApexDoc | 包含静态 HTML 页面的文档 Apex | X | X | |
| 批量删除无效选项列表值 | 从选项列表中删除无效未使用的值 | X | ||
| Lightning设计系统验证器 | 验证标记并了解如何改进代码 | X | X | |
| 迁移到流 | 将工作流规则和进程构建器进程转换为流 | X | ||
| Salesforce Labs 的项目管理工具 | 在 Salesforce 组织中管理项目 | X | X | |
| 适用于 Visual Studio 代码的 Salesforce 扩展(展开) | 使用 Visual Studio 代码扩展高效分析 Salesforce 代码 | X | X | |
| 组织检查 | 快速分析您的组织及其技术债务 | X | ||
| Salesforce 代码分析器 | 通过 IDE、CLI 或 CI/CD 扫描代码,以确保符合最佳实践 | X | X | |
| Salesforce 路线图资源管理器 | 探索 Salesforce 产品创新 | X | ||
| 设置审计跟踪 | 跟踪设置更改和审计历史 | X | X |
| 资源 | 描述 | 策略 | 可维护性 | 可读性 |
|---|---|---|---|---|
| 改进 Salesforce 组织的 5 个文档策略 | 改进 Salesforce 实施文档 | X | ||
| 选择命名约定 (Trailhead) | 了解如何应用命名约定 | X | ||
| 定义、识别和衡量技术债务 | 定义、识别和衡量技术债务 | X | X | |
| 设计标准模板 | 为您的组织创建设计标准 | X | X | X |
| Salesforce 图表入门 | 了解如何为您的用例创建正确的图表 | X | ||
| 编码惯例入门 (Trailhead) | 定义并遵循编码约定 | X | ||
| 如何处理技术债务 (Trailhead) | 在 Salesforce 组织中管理技术债务 | X | X | |
| 改进 Apex 代码 (Trailhead) | 应用测试驱动开发的基本原则 | X | ||
| 组织调整 (Trailhead) | 了解 V2MOM 校准流程 | X | ||
| 优先考虑并计划摆脱技术债务的方法 | 制定减少和删除技术债务的计划 | X | X | |
| Salesforce 命名约定模板 | 开始使用命名约定 | X | X | |
| 技术债务:它是什么以及您为什么要关心它? | 了解技术债务对贵组织的影响 | X | ||
| 在企业架构中使用业务模型画布 | 在业务模型中创建、交付和查看价值 | X |
| 受信 | ||
|---|---|---|
| 受信任的解决方案保护您的业务和利益相关者。 | ||
| 安全 | 合规 | 可靠 |
| 组织安全性 会话安全性 数据安全 |
法律遵守 道德标准 可访问性 |
可用性 性能 可扩展性 |
| 轻松 | ||
| 简单的解决方案可以快速提供业务价值。 | ||
| 意图 | 自动 | 参与 |
| 策略 可维护性 可读性 |
效率 数据完整性 |
简化 有用 |
| 可适应 | ||
| 适应性强的解决方案会随业务发展。 | ||
| 弹性 | 可合成 | |
| 应用程序生命周期管理 事件响应 连续性计划 |
分离问题 交互性 可打包性 |
|
| 模式 | 反模式 | |
|---|---|---|
| 流程设计 | 在您的组织中:
- 每个流服务于一个特定目的 - 每个步骤执行特定的精细任务 - 流以层次结构组织,包括主流和支持子流 - 所有用户输入在流中都有明确的目的 - 仅在无法使用现有系统数据时要求用户提供数据 |
在您的组织中:
- 流服务于多种目的,需要额外的输入来提供上下文 - 流需要不使用数据的输入 - 相关步骤组包含与其他流中的步骤组重叠的功能 - 流会在存储的数据可用于替代时请求用户输入 |
| 在 Apex 中:
- 每个类都服务于一个特定的目的 - 每种方法执行特定的精细任务 - 所有输入变量在类中都有明确的目的 - 代码执行需要最少的资源 |
在 Apex 中:
- 类具有多种用途 - 方法执行多个任务或方法执行的任务与其所属类的声明目的不一致 - 输入变量未在方法中实际使用 - 从数据库或外部系统检索不必要数据的方法 |
|
| 操作逻辑 | 在流中:
- 没有变量引用硬编码值(适用于记录类型、用户等) - 所有自动启动的流和进程都使用决策和/或暂停元素来评估准入条件,并防止对大量数据执行无限循环或执行 - 在大数据量上下文中,流(包括进程)将逻辑移交给 Apex - 子流用于需要在整个业务中重用的流程部分 |
在流中:
- 变量包含硬编码值 - 流(包括进程)必须在批量数据加载之前手动停用 - 流(包括进程)触发“未处理异常”通知 - 即使简单的流也会定期导致与调控器限制相关的错误 - 流的一部分在流之间重复,而不是使用子流 |
| 在 Apex 中:
- 没有变量引用硬编码值(适用于记录类型、用户等) - 所有通配符条件都显示在 SOSL 中 - SOQL 使用 try-catch 封装
- 循环中未显示 SOQL - SOQL 语句具有选择性,包括: -- 不使用 LIKE 比较或部分文本比较
-- 比较运算符使用正逻辑(即 INCLUDES、IN)作为主要或唯一逻辑
-- 很少使用 = NULL、!= NULL 和/或始终跟在正比较运算符之后
-- 未显示 LIMIT 1 语句
-- 不使用 ALL ROWS 关键字
| 在 Apex 中:
- 变量包含硬编码值 - SOSL 很少或没有一致地用于通配符选择条件 - SOQL 未封装在 try-catch 中
- SOQL 显示在循环中 - SOQL 语句是非选择性的,包括: -- 显示 点赞和通配符筛选条件
-- 使用 NOT、NOT IN 条件的比较用作主要或唯一比较运算符
-- = NULL、!= NULL 条件用作主要或唯一比较运算符
-- 显示 LIMIT 1 个报表
-- 使用 所有行关键字
| |
| 在设计标准和文档中:
- 清晰概述自动化的计划和潜在执行路径 - 自动化中同步和异步操作的用例被清楚地概述为设计标准的一部分 |
在设计标准和文档中:
- 自动化调用未记录 - 同步和异步操作的用例未处理 |
|
| KPI | 在您的文档中:
- 每个自动化的输出都是可测量和有时限的 - 为每个 KPI 列出负责任的利益相关者 |
在您的文档中:
- 自动化没有 KPI,或者测量的时间范围不明确 - KPI 没有负责任的利益相关者 |
| 在报表和仪表板中:
- 与 KPI 相关的所有度量都包含在至少一个报表或仪表板中 |
在报表和仪表板中:
- KPI 报表不存在或报表缺少与一些 KPI 相关的度量 |
| 模式 | 反模式 | |
|---|---|---|
| 数据处理 | 在您的数据字典中:
- 存在所有数据源和数据湖对象的字段级数据和优先级逻辑 - 存在从数据湖对象到数据模型对象的字段映射 |
在您的数据字典中:
- 不包括数据源和数据湖对象的字段级数据和优先级逻辑 - 不包括从数据湖对象到数据模型对象的字段映射 |
| 在 Apex 中:
- 所有同步 DML 语句或数据库类方法都在触发器执行上下文之前执行 - 异步 Apex 调用使用可排队项在事务之间“链接”复杂的 DML - 批量 Apex 专用于大数据量 - @future Apex 未用于标注或系统对象 DML 或未谨慎使用 |
在 Apex 中:
- DML 语句定期出现在将在触发器上下文后调用的代码中 - 异步 Apex 很少使用 - 异步 Apex 功能被任意使用,包括: -- 未来方法和可排队 Apex 使用不一致或互换 -- 数据库操作没有明确一致的逻辑来在需要时将执行传递给批处理 Apex |
|
| 在流中:
- 在用户上下文中启动的所有流将所有系统上下文事务抽象到子流,这些子流一致放在暂停元素之后,以创建新事务 - 使用 Orchestrator 创建相关数据操作的复杂序列(而不是调用单个流中的多个子流) - 所有记录触发的流都填充了触发顺序值 - 涉及外部系统标注或长时间运行的流程的流使用异步路径 |
在流中:
- 大型单片流尝试协调相关数据操作的复杂序列(带或不带子流) - 记录触发的流根本不使用触发顺序属性,或者没有一致使用触发顺序值 - 异步路径的使用不一致或根本不一致 |
|
| 在您的组织中:
- 身份解析协调规则遵循数据字典中的优先级逻辑 |
在您的组织中:
- 身份解析协调规则不遵循数据字典中的优先级逻辑 |
|
| 错误处理 | 在 Apex 中:
- 代码包含 try- catch 块中的所有 DML、SOQL、标注和其他关键流程步骤
- 自定义异常用于创建高级错误消息和逻辑 - 在异步和批量上下文中,使用数据库类方法,而不是 DML - 数据库类方法可以专用于所有数据操作(而不是 DML) |
在 Apex 中:
- DML、SOQL、标注或其他关键流程步骤没有一致地封装在 试用块中
- System.debug 语句出现在生产代码中(不会被注释掉)
- 不使用数据库类方法 - 数据操作仅通过 DML 完成 |
| 在 Lightning Web 组件中:
- JavaScript 将所有数据操作和关键流程步骤封装在 if ()/else if () 块中
- 所有 @wire 函数都使用 API 提供的数据和错误属性
- All if (error)/else if (error) 语句包含处理错误和提供信息性消息的逻辑 |
在 LWC 中:
- 如果 ()/如果 () 包含数据操作或关键流程步骤的块,JavaScript 不会一致使用
- @wire 函数不使用 API 提供的数据和错误属性(或没有一致使用)
- 如果使用, if (error)/else if (error) 语句实际上不包含处理错误和提供有用错误消息的逻辑 |
|
| 在 Aura 中:
- JavaScript 将所有数据操作和关键流程步骤封装在 试用捕获块中
- 在 try-catch 块中,本地 JavaScript 错误在 throw 语句中使用(不使用 $A.error())
- 所有可恢复的错误逻辑都出现在 catch 语句中,并提供明确的用户消息 |
在 Aura 中:
- JavaScript 没有一致地将数据操作和关键流程步骤封装在 尝试捕获块中
- 组件使用 $A.error()
- 可恢复的错误逻辑并不总是出现在 catch 语句中,并且对用户的错误消息不清楚 |
|
| 在流中:
- 屏幕流始终使用错误连接器向用户显示错误 - 为屏幕上显示的错误配置自定义错误消息 - 具有数据操作、标注和其他关键处理逻辑的流具有所有关键操作的错误路径 |
在流中:
- 流没有一致或根本不使用错误路径 - 未使用自定义错误消息,因此用户会看到默认“此流中发生未处理的错误”消息 |
| 工具 | 描述 | 效率 | 数据完整性 | 业务价值 |
|---|---|---|---|---|
| Apex 批处理 | 将记录批处理在一起,并处理可管理的块 | X | X | |
| Apex 未来方法 | 在后台异步执行 Apex 方法 | X | X | |
| Apex 队列 | 将 Apex 作业添加到队列并监视它们 | X | X | |
| Apex Scheduler | 在指定时间异步执行 Apex 类 | X | X | |
| 批准 | 指定批准记录所需的步骤 | X | X | |
| Asynchronous Apex | 异步运行 Apex 代码 | X | X | |
| 自动操作 | 在后台执行字段更新、电子邮件发送和其他操作 | X | X | |
| Einstein Next Best Action | 在正确的时间向正确的人显示正确的推荐 | X | X | |
| 电子邮件提醒 | 创建并发送自动电子邮件 | X | X | |
| 升级操作 | 指定对个案升级采取的自动操作 | X | X | |
| 字段更新 | 基于自动化更新字段值 | X | X | |
| 流生成器 | 使用指点单击式界面构建自动化 | X | X | |
| 流扩展 | 访问存储的变量作为流中的组件输入 | X | ||
| 流模板库 | 使用模板设计特定于行业的流 | X | X | |
| 流触发器 | 自动化复杂的业务流程 | X | ||
| 可调用操作 | 将 Apex 功能添加到流 | X | X | |
| 编配员 | 创建和管理多步骤自动化 | X | X | |
| 出站消息 | 从带有回执和重试的自动化流程发送信息 | X | ||
| 使用流发布平台事件 | 通过用户交互和自动化发布事件 | X | ||
| 查询优化器 | 使用选择性和索引改善查询、报表和列表视图性能 | X | X | |
| Salesforce 流 | 使用 Flow Builder 创建声明性流程自动化 | X | X | |
| 使用流发送通知 | 通过 SMS、WhatsApp 或 Facebook Messenger 发送消息 | X | X | |
| 通过进程发送通知 | 通过 SMS、WhatsApp 或 Facebook Messenger 发送消息 | X | X | |
| SOQL FOR UPDATE 修改器 | 锁定记录,以防止竞赛条件和线程安全问题 | X | ||
| Strategy Builder | 确定要在记录页面上显示的推荐 | X | X | |
| 子流 | 通过重复使用降低流复杂性 | X | ||
| 使用流订阅平台事件 | 接收通过自动化发布的消息 | X | ||
| 任务操作 | 确定自动化为用户提供的分配详细信息 | X |
| 资源 | 描述 | 效率 | 数据完整性 | 业务价值 |
|---|---|---|---|---|
| Apex 执行调控器和限制 | 了解 Apex 运行时引擎如何强制执行限制 | X | X | |
| 批处理管理资源 | 创建、管理、计划和监控批处理作业 | X | X | |
| SOQL 和 SOSL 的最佳实践 | 提高大数据量应用程序的查询性能 | X | ||
| 设计标准模板 | 为您的组织创建设计标准 | X | X | X |
| 事务中的流批量化 | 设计针对集合操作的流 | X | X | |
| 流数据注意事项 | 了解批处理数据的计划触发流 | X | X | |
| 流调试 | 测试流并进行故障排除 | X | ||
| 如何处理请求 | 了解 Salesforce 如何快速处理作业并最大限度地减少失败 | X | X | |
| KPI 电子表格模板 | 确定特定度量的业务价值 | X | X | |
| 从可调用操作对外部系统进行标注 | 使用 Apex 从流调用外部系统 | X | ||
| 混合 DML 操作 | 了解哪些 sObject 可以在同一事务中一起用于 DML | X | X | |
| 执行顺序 | 了解插入、更新和更新插入的事件顺序 | X | X | |
| 查询计划常见问题解答 | 优化涉及大量数据的查询 | X | X | |
| 计划触发的流注意事项 | 了解计划触发的流的特殊行为 | X | ||
| 交易控制 | 生成指定当前数据库状态的保存点 | X | X | |
| 当流失败时会发生什么? | 了解流中的错误处理 | X | X | |
| 工作流自动化最佳实践指南 | Salesforce 自动化入门 | X | X | X |
| 使用非常大的 SOQL 查询 | 编写更高效的 SOQL 查询 | X |
| 意图 | ||
|---|---|---|
| 意图性解决方案会随着时间的推移立即提供业务价值。意图架构以战略性的方式规划和交付,可以有效维护,并且易于人类阅读和理解。 | ||
| 策略 | 可维护性 | 可读性 |
| 优先级 路线图 治理 |
标准与自定义 技术债务 |
设计标准 文档 |
| 自动 | ||
| 自动化解决方案使企业能够更快地大规模完成工作。健康的自动化减少了在重复的手动任务或复杂的数据输入上花费的时间。 | ||
| 效率 | 数据完整性 | |
| 流程设计 操作逻辑 KPI |
数据处理 错误处理 |
|
| 参与 | ||
| 吸引解决方案会使用户高兴,并推动采用。参与架构意味着创建直观、有帮助的用户体验。 | ||
| 简化 | 有用 | |
| 应用程序复杂性 表格 外形规格 |
通知和消息传递 应用程序内指导 荣誉和奖励 |
|