Salesforce Platform

为什么选择 Salesforce Platform？

Salesforce Platform 的独特之处在于应用的运行环境。开发团队无需从零开始构建数据库或手动搭建身份验证、授权、工作流、审计、API 和管理层，而是直接基于 Salesforce 现有的数据模型和运营控制体系进行构建。

当应用需要处理账户、联系人、商机、工单、服务流程、合作伙伴关系或其他成熟的 Salesforce 领域数据时，这一优势尤为明显。自定义应用可以接入组织现有的权限、自动化、报表和记录历史，无需维护一套平行的客户数据逻辑。

目前的 Salesforce 官网越来越多地在 Headless 360 和 Agentforce 360 战略下展示这一基础能力。但对于开发者、管理员和采购者而言，Salesforce Platform 仍是惯用的正式名称，因此在评估和实施过程中，这两个名称可能会交替出现。

该平台采用元数据驱动架构。对象、字段、布局、验证规则、自动化、权限、组件以及大部分应用配置均表现为可部署的元数据。这建立了一种共享协作模式：管理员可以通过可视化方式配置流程，而开发者则可以用代码扩展同一流程，并将生成的元数据提交至源代码控制系统。

核心工作流

成功的实施通常始于领域建模，而非界面设计。团队需要确定某个需求是属于现有的标准对象、需要创建自定义对象，还是应该留在外部系统中。重用正确的标准模型通常能显著提高与报表、自动化、预装应用以及 Salesforce 未来版本的兼容性。

安全设计应与数据模型同步进行。对象访问权限、字段可见性、记录共享、所有权、角色和权限集几乎会影响后续的每一个决策。在构建完用户界面后再去补救这些控制逻辑，往往会导致昂贵的返工，并可能通过报表、集成、自动化或生成的 AI 响应泄露数据。

随后，开发可以遵循“声明式优先”的原则。表单、审批、记录更新、通知和引导式流程在可视化工具中通常更易于维护。当逻辑涉及事务处理、计算密集、跨多个入口重用或难以通过可视化自动化安全表达时，使用 Apex 和自定义组件则更为合适。

专业开发仍应遵循传统的软件生命周期。元数据应被提取到项目中，在 Git 中进行审查，在测试环境中验证，并通过受控环境进行发布。虽然基于浏览器的构建器便于探索和管理，但生产环境的变更不应依赖于单个组织中无记录的手动编辑。

适用场景

Salesforce Platform 特别适合记录需要流转于特定业务流程的操作型应用。典型案例包括：入职流程、审批流转、账户计划、合作伙伴管理、现场检查、客户投诉升级、合规审查、合同交接以及内部申请系统。

对于扩展现有的 Salesforce 部署也同样有效。例如，公司可能需要为服务主管提供专用控制台，或建立一个关联商机数据的合作伙伴门户，亦或是为现场员工提供移动端工作流。将这些体验保留在同一平台上可以减少数据同步逻辑，并沿用现有的访问模型。

对于高并发的公共消费级服务、媒体处理、科学计算、实时多玩家系统或需要无限制后台执行的任务，该平台则不那么契合。常见的架构方案是将业务流程和受控记录保留在 Salesforce 中，而将重度计算、流处理或特殊基础设施转移到通过 API 或事件连接的外部服务中。

明确这一界限至关重要。将 Salesforce 视为所有任务的通用运行环境会导致代码复杂化，并频繁触碰多租户限制。反之，仅将其视为被动 CRM 则会浪费其工作流和元数据系统的价值。务实的中庸之道是：将感知客户的编排逻辑保留在 Salesforce 附近，而将基础设施密集型工作委托给专门为此设计的服务。

AI 辅助开发的实践

Agentforce Vibes 为 Salesforce 开发引入了更具 AI 原生特性的路径。在规划或生成变更时，它可以利用组织的架构、元数据、代码模式和项目指令作为上下文。这比只懂 Apex 语法但会臆造不存在的字段、对象或权限假设的通用代码生成器有用得多。

最可靠的工作流始于“计划”而非直接请求修改项目。计划应识别受影响的元数据、安全性变更、数据访问路径、服务端逻辑、界面组件、测试以及部署依赖项。开发者可以在允许 Agent 生成代码之前先审查这些逻辑边界。

生成的 Apex 代码需要像人工编写的代码一样经过审查。测试应覆盖批量记录处理、失败行为、共享规则、字段级安全、外部调用、异步执行和资源限制消耗。生成的组件应检查其可访问性、数据访问安全性、加载状态以及在真实数据量下的表现。

AI 辅助在重复性元数据创建、初始测试脚手架、组件结构、文档编写以及在大型组织中导航方面具有极高价值。但它并不能取代开发者对事务边界、安全强制执行、部署顺序或修改共享自动化后果的理解。

Salesforce 还支持通过 BYOLLM（自带模型）连接外部托管的语言模型。这让企业在模型供应商和商业协议上有更多选择，但不应将其与本地离线推理混淆。连接的模型仍需要可访问的托管端点、适当的凭据、监控以及通过审批的数据处理设计。

竞品对比

对于以 Microsoft 365、Dataverse、Dynamics 365、Azure 和 Teams 为中心的组织，Microsoft Power Apps 是最直接的对比对象。当身份、文档、协作和业务数据已存在于 Microsoft 生态系统时，Power Apps 具有组织架构上的优势。相应地，当客户记录、服务流程、收入流和合作伙伴运营已在 Salesforce 中时，Salesforce Platform 则是更优选。

ServiceNow App Engine 侧重于围绕 IT 服务管理、运营、员工服务和 ServiceNow 配置数据库构建的企业工作流。对于面向客户和与收入相关的流程，Salesforce 通常是更自然的基础，而对于 IT 和内部服务交付，ServiceNow 可能是更强大的运营中心。

Mendix 和 OutSystems 是更广泛的低代码应用平台，与特定 CRM 数据模型的绑定较弱。它们在多样化的应用组合和自定义用户体验方面可能提供更多灵活性。而 Salesforce 则为其自身的业务数据、安全、自动化和应用市场提供了更深层次的原生访问。

Appian 经常被用于流程编排、个案管理和文档密集型工作流的评估。选择的关键在于：主要需求是一个跨多系统的流程平台，还是一个直接在 Salesforce 客户与权限模型内运行的应用。

Oracle APEX 对于拥有大量 Oracle 数据库经验和以 SQL 为核心的应用团队非常有吸引力。它提供的开发模式与 Salesforce 的元数据、事件、对象及 Apex 架构完全不同。在这种决策中，现有的数据归属权往往比通用的功能对比更重要。

配置建议

在自定义规模扩大之前就应建立源代码控制。即使管理员承担了大部分实施工作，重要的元数据也应流经代码仓库和可重复的验证流程。这提供了审计历史，使环境差异透明化，并减少了对单一生产环境作为系统唯一记录的依赖。

大型实施项目受益于清晰的领域界限。不要让每个团队都去修改同一套未分区的元数据，而应按业务能力对组件、自动化、权限和代码进行分组。基于包的开发可以使权责和部署更清晰，但在高度自定义的组织中后期引入包开发需要周密的规划。

权限集应承载大部分功能访问权限，而配置文件（Profiles）在实际操作中应作为最小基准。这使得访问权限具有可组合性且更易于审计。命名规范同样重要，因为大型组织会积累数以千计的字段、Flow、类、组件和权限产物，否则将变得难以维护。

建立明确的策略来选择使用 Flow 还是 Apex。策略应考虑事务复杂性、重用性、测试、错误处理、记录量和所有权，而不是盲目认为可视化自动化总是更简单。少量经过良好测试的代码可能比多个重叠的 Flow 更安全，而日常由管理员维护的变更可能并不值得动用自定义 Apex。

生产数据不应随意复制到开发环境中。应根据实施的敏感程度使用代表性测试数据、数据脱敏或受控的数据植入流程。AI 开发工具的引入是另一个需要记录哪些数据和元数据可作为上下文的原因。

AI 生成的变更应与人工代码一样通过拉取请求（PR）、静态分析、自动化测试、安全审查和部署控制。自动批准设置在实验阶段很有用，但在 Agent 可以修改元数据、执行命令或与连接组织交互时，应保持保守。

运营治理不应仅限于用户许可证。监控 API 消耗、自动化执行量、存储空间、外部登录、Data 360 使用情况、Agentforce 操作以及连接模型的成本。一个在原型阶段看似廉价的方案，在处理生产流量后可能会表现出完全不同的成本结构。

迁移建议

从电子表格、旧版 CRM 或自定义数据库迁移，应从数据所有权和流程梳理开始。导入每一个历史字段并重建每一个旧工作流，通常只会产生一个昂贵且难以维护的旧系统翻版，而不是一个现代化的 Salesforce 应用。

数据迁移需要明确的加载顺序。父记录、参考数据、用户、所有权、关联关系、活动、文件和依赖事务都有不同的要求。使用稳定的外部 ID 可以使过程可重复，并在测试迁移期间减少对 Salesforce 生成的记录 ID 的依赖。

在初始数据加载期间，自动化通常应保持禁用或受控状态。否则，导入操作可能会触发通知、生成重复记录、触发非预期的重新计算或调用外部系统。迁移计划应定义哪些验证和自动化适用于历史数据，哪些仅在上线后生效。

现有的 Salesforce 客户可能面临另一种迁移：从 Classic 界面、旧版 Visualforce、工作流规则、Process Builder 或无管理的生产环境变更，转向 Lightning 组件、Flow、源码驱动开发和现代打包模式。这应围绕业务领域逐步进行，而非一次性大规模重写。

应用的可移植性有限。虽然记录和元数据可以导出，但 Apex、Flow 定义、Lightning 组件、权限模型和包依赖无法直接在其他平台上运行。在将无关任务或不可替代的业务逻辑完全置于 Salesforce 内部之前，团队应充分意识到这种架构上的深度绑定。

运营权衡

Salesforce 的多租户运行环境通过强制执行资源限制来保护共享基础设施。开发者必须设计批量安全的事务，避免重复的数据库操作，控制异步任务，并理解多个自动化如何在单个事务中组合。这些约束虽然有助于提升代码规范，但也增加了从传统服务器环境转岗的开发者必须学习的新概念。

当允许许多团队进行重叠的变更时，管理的灵活性可能会演变成治理问题。一个字段或 Flow 在某个部门看来是局部的，实际上可能会影响集成、报表、Agent 以及预装应用。随着组织规模增长，清晰的所有权归属、依赖分析、发布协调和停用程序变得愈发重要。

平台的发布节奏也要求持续维护。Salesforce 通常会保持兼容性，但季节性版本发布、API 停用计划、浏览器更新以及托管包的更新仍需进行测试。预览版沙盒（Preview Sandboxes）和自动化回归测试可以降低在生产环境升级后才发现问题的风险。

因此，评估 Salesforce Platform 时应将其视为一种运营模式，而不只是一个应用构建器。只有当组织准备好将元数据、访问控制、发布、数据质量、许可和业务归属权作为一套长期运行的企业系统来管理时，该技术才能发挥最大效能。