Salesforce Experience Cloud 架构：构建安全、可扩展的数字化体验蓝图

背景与应用场景

作为一名 Salesforce 架构师 (Salesforce Architect)，我经常被问及如何构建一个既能满足当前业务需求，又能适应未来增长的数字化平台。Salesforce Experience Cloud（前身为 Community Cloud）正是应对这一挑战的核心解决方案。它不仅仅是一个简单的门户网站工具，更是一个功能强大的平台，能够帮助企业构建与客户、合作伙伴和员工深度互联的数字化体验空间。

从架构师的视角来看，Experience Cloud 的价值在于其无与伦比的灵活性和与 Salesforce 核心平台的深度集成。它允许我们将 CRM 数据和服务安全、可控地暴露给外部用户，从而创建丰富的应用场景：

• 客户自助服务门户 (Customer Self-Service Portal): 客户可以在这里查找知识库文章、提交和跟踪服务案例、管理自己的账户信息，从而降低服务成本，提升客户满意度。
• 合作伙伴关系管理门户 (Partner Relationship Management - PRM Portal): 渠道合作伙伴可以在此注册潜在客户、更新商机、获取销售资料和接受培训，实现与企业销售流程的无缝对接。
• 品牌社区 (Brand Community): 客户和品牌爱好者可以在此交流互动，分享使用经验，为产品创新提供宝贵的反馈，增强品牌忠诚度。
• 微型网站和营销登陆页 (Microsites and Landing Pages): 快速搭建针对特定营销活动或产品发布的独立站点。

然而，构建一个成功的 Experience Cloud 站点远不止拖拽组件那么简单。一个缺乏深思熟虑的架构设计，可能会在未来导致性能瓶颈、数据安全漏洞和高昂的维护成本。因此，在项目启动之初，我们必须从宏观层面规划其核心架构，确保其安全性 (Security)、可扩展性 (Scalability) 和高性能 (Performance)。

---

原理说明

一个稳健的 Experience Cloud 架构建立在四大核心支柱之上。作为架构师，我们需要在设计阶段仔细权衡每一个支柱的决策，因为它们将直接影响整个解决方案的成败。

1. 用户许可与身份模型 (User Licensing and Identity Model)

这是架构设计的第一步，也是最关键的一步。许可类型的选择直接决定了站点的功能边界、数据访问能力和总体拥有成本 (TCO)。

• Customer Community: 这是最基础的许可类型，适用于大规模 B2C 场景，如客户自助服务。用户主要访问案例、知识库和自定义对象，但不能访问商机、潜在客户等销售对象。其数据访问模型主要依赖于 共享集 (Sharing Sets) 和 共享组 (Share Groups)。
• Customer Community Plus (CC+): 在 Customer Community 的基础上，提供了更高级的共享能力。用户可以拥有角色 (Roles)，并能通过标准的 Salesforce 共享规则 (Sharing Rules) 和手动共享 (Manual Sharing) 访问其所属客户 (Account) 下的记录。适用于需要更复杂数据共享的 B2B 场景。
• Partner Community: 功能最强大的许可类型，专为 PRM 场景设计。合作伙伴用户可以访问销售对象，如潜在客户 (Leads)、商机 (Opportunities) 和市场活动 (Campaigns)。它支持完整的基于角色的共享模型，与内部用户的共享机制非常相似。
• External Apps: 这种许可类型更侧重于通过 API 访问 Salesforce 数据，并构建高度定制化的外部应用，而不是传统的门户体验。它提供了大量的 API 调用次数，非常适合作为移动应用或外部系统的后端。

身份验证方面，我们需要设计一个无缝且安全的登录体验。除了标准的用户名密码登录，还应优先考虑集成 单点登录 (Single Sign-On, SSO)，例如使用 SAML 或 OpenID Connect 协议与企业身份提供商 (IdP) 集成。对于面向消费者的站点，社交登录 (Social Sign-On)（如通过 Google, Facebook, LinkedIn 登录）可以极大地简化注册和登录流程。

2. 数据可见性与共享模型 (Data Visibility and Sharing Model)

保护数据安全是架构师的首要职责。Experience Cloud 的共享模型与内部 Salesforce 组织有显著区别，因为它默认遵循“默认私有”的原则。

• 外部组织范围默认设置 (External Organization-Wide Defaults, OWD): 这是控制外部用户数据访问的基石。对于所有对象，其外部 OWD 必须设置为“私有”(Private)，这是比内部 OWD 更严格的设置。这意味着外部用户默认无法看到任何他们不拥有的记录。
• 共享集 (Sharing Sets): 专为 Customer Community 许可设计。它基于用户与客户或联系人之间的直接关系来授予记录访问权限。例如，一个规则可以定义为：“将与用户关联的客户 (Account) 下的所有案例 (Cases) 共享给该用户”。这是实现大规模共享的高性能机制。
• 共享组 (Share Groups): 允许将共享集授予的记录访问权限扩展到由同一客户下的其他用户组成的组，适用于需要团队协作的场景。
• Apex 托管共享 (Apex Managed Sharing): 当标准共享模型无法满足复杂的业务逻辑时（例如，基于项目角色或动态团队的共享），Apex 托管共享是最终的解决方案。它允许我们通过 Apex 代码以编程方式插入共享记录，从而实现精细化的访问控制。这为架构提供了极大的灵活性。

3. 性能与可扩展性 (Performance and Scalability)

一个响应缓慢的站点会严重影响用户体验和采纳率。架构师必须从一开始就将性能设计融入其中。

• 利用 CDN (Content Delivery Network): Salesforce Experience Cloud 内置了对 CDN 的支持。启用 CDN 可以缓存静态资源（如图片、CSS、JavaScript 文件）到离用户更近的边缘服务器，从而显著加快页面加载速度。
• 高效的组件设计: 推荐使用 Lightning Web Components (LWC) 构建自定义组件。LWC 遵循现代 Web 标准，性能优于早期的 Aura 组件。在 LWC 中，应避免在组件初始化时执行复杂的 SOQL 查询，而是采用懒加载 (Lazy Loading) 的方式，仅在需要时才获取数据。
• 数据查询优化: 对于外部用户，所有 SOQL 和 SOSL 查询都必须高效且具有选择性。避免查询大量数据，并确保关键查询字段已建立索引。对于大规模数据，考虑使用异步处理或平台事件 (Platform Events) 来解耦操作。
• 主题和品牌化: 使用 Experience Cloud 的主题布局 (Theme Layouts) 和品牌集 (Branding Sets) 进行样式定制，而不是通过大量自定义 CSS 或 JavaScript 来覆盖标准样式。这有助于保持站点的可维护性和升级兼容性。

---

示例代码

以下代码示例演示了如何使用 Apex 托管共享 (Apex Managed Sharing) 来编程共享一个名为 `Project__c` 的自定义对象记录。这在标准共享规则无法满足动态共享需求的场景中非常关键，例如，需要将一个项目记录共享给所有被分配到该项目的外部顾问。

场景: 当一个外部顾问（Experience Cloud 用户）被关联到一个 `Project__c` 记录时，我们需要授予该用户对该 `Project__c` 记录的读取权限。

// 假设有一个名为 ProjectAssignment__c 的交汇对象，用于连接 Project__c 和 User
// 当 ProjectAssignment__c 记录被创建时，触发此 Apex 逻辑

public class ProjectSharingManager {

    // 假设此方法在一个 Trigger 中被调用
    public static void shareProjectWithConsultant(List<ProjectAssignment__c> newAssignments) {

        // 1. 创建一个用于存储共享记录的列表
        List<Project__share> sharesToInsert = new List<Project__share>();

        // 2. 遍历新的项目分配记录
        for (ProjectAssignment__c assignment : newAssignments) {

            // 检查是否分配给了有效的用户和项目
            if (assignment.Consultant__c != null && assignment.Project__c != null) {

                // 3. 创建一个新的 Project__share 对象
                // Salesforce 会为所有启用了共享的自定义对象自动创建一个 __share 对象
                Project__share projShare = new Project__share();

                // 4. 设置被共享的记录 ID
                // ParentId 字段总是指向被共享的主记录
                projShare.ParentId = assignment.Project__c;

                // 5. 设置被授予访问权限的用户或组的 ID
                // UserOrGroupId 字段可以是一个用户 ID、一个公共组 ID 或一个角色 ID
                projShare.UserOrGroupId = assignment.Consultant__c;

                // 6. 设置访问级别（Read 或 Edit）
                projShare.AccessLevel = 'Read';

                // 7. 设置共享原因 (RowCause)。这是 Apex 托管共享的关键。
                // 我们需要先在对象的 Sharing Reasons 中创建一个自定义原因。
                // Schema.Project__share.RowCause.Consultant_Assignment__c 是引用自定义共享原因的最佳实践
                projShare.RowCause = Schema.Project__share.RowCause.Consultant_Assignment__c;

                sharesToInsert.add(projShare);
            }
        }

        // 8. 批量插入共享记录，并处理潜在的异常
        if (!sharesToInsert.isEmpty()) {
            try {
                // 设置 allOrNone 为 false，允许部分成功，这在批量操作中是最佳实践
                Database.SaveResult[] saveResults = Database.insert(sharesToInsert, false);

                // 迭代结果并记录任何错误
                for (Database.SaveResult sr : saveResults) {
                    if (!sr.isSuccess()) {
                        for(Database.Error err : sr.getErrors()) {
                            System.debug('Error sharing project: ' + err.getStatusCode() + ': ' + err.getMessage());
                        }
                    }
                }
            } catch (DmlException e) {
                // 记录 DML 异常
                System.debug('An unexpected DML exception occurred: ' + e.getMessage());
            }
        }
    }
}

---

注意事项

• 权限与安全 (Permissions and Security):

  始终遵循最小权限原则 (Principle of Least Privilege)。外部用户的配置文件 (Profile) 和权限集 (Permission Sets) 应尽可能严格。避免授予他们“查看所有数据”或“修改所有数据”等系统权限。特别注意对 Guest User Profile 的安全设置，Salesforce 近年来已强制实施了多项安全强化措施，必须仔细审查。

• API 限制 (API Limits):

  高流量的 Experience Cloud 站点会消耗大量的 API 调用。架构设计时必须考虑到这一点，通过缓存、使用高效的 LWC 和避免不必要的服务器调用来减少 API 消耗。对于需要与外部系统集成的场景，应评估总体 API 使用情况，考虑是否需要购买额外的 API 调用包。

• 数据倾斜 (Data Skew):

  在 B2B 场景中，如果单个客户 (Account) 拥有大量联系人 (Contacts) 或其他相关记录（例如，成千上万个案例），可能会导致数据倾斜。这会严重影响共享计算的性能，导致页面加载缓慢或超时。在设计阶段，应识别潜在的数据倾斜风险，并考虑采用数据归档策略或通过 Apex 托管共享等方式优化共享逻辑。

• 混合 DML 错误 (Mixed DML Errors):

  在一个事务中，不能同时对设置对象（如 User, Profile）和非设置对象（如 Account, Case）执行 DML 操作。一个常见的错误是在创建 Experience Cloud 用户的同时，还创建了相关的联系人或客户记录。这会导致 `MIXED_DML_OPERATION` 错误。架构师应确保通过使用 future 方法或队列化 Apex (Queueable Apex) 将这些操作分离到不同的事务中。

---

总结与最佳实践

作为 Salesforce 架构师，设计 Experience Cloud 解决方案是一项涉及多方面权衡的系统工程。一个成功的架构不仅能满足眼前的业务需求，更能为企业未来的数字化转型奠定坚实的基础。

以下是我的核心最佳实践建议：

1. 将共享模型置于设计的中心: 在编写任何代码或配置任何页面之前，首先绘制出详细的数据共享模型。明确哪个用户角色需要访问哪些对象的哪些记录，并选择最合适的共享机制。
2. 正确选择许可类型: 许可类型的选择是成本和功能的双重决策。深入理解每种许可的限制和能力，避免过度购买（成本过高）或购买不足（功能受限）。
3. 性能优先: 从第一天起就为性能而设计。启用 CDN，采用 LWC，优化 SOQL 查询，并对关键页面进行负载测试。
4. 安全是不可妥协的底线: 严格配置外部用户的配置文件和权限集。定期审查 Guest User 的访问权限，并遵循 Salesforce 的安全建议。
5. 拥抱声明式工具，审慎使用代码: 尽可能利用 Experience Cloud Builder、Flows 和标准共享规则。仅在标准功能无法满足复杂需求时，才诉诸 Apex 和 LWC，以确保解决方案的可维护性。

通过遵循这些架构原则和最佳实践，我们可以构建出安全、可扩展且用户体验卓越的 Experience Cloud 解决方案，从而真正释放 Salesforce 平台连接万物的巨大潜力。