Salesforce Partial Copy Sandbox：终极管理员指南

背景与应用场景

作为一名 Salesforce 管理员 (Salesforce Administrator)，我们日常工作的核心之一就是维护生产环境 (Production Org) 的稳定、高效和安全。然而，任何新的功能、自动化流程或配置变更，在部署到生产环境之前，都必须经过严格的测试。Salesforce 为我们提供了多种类型的沙箱 (Sandbox) 来满足不同的测试需求，它们是我们进行安全开发和测试的“隔离区”。

在 Salesforce 的沙箱生态系统中，主要有四种类型：

Developer Sandbox：仅复制生产环境的元数据 (Metadata)，不包含任何业务数据。存储空间有限，适合日常的开发和单元测试。
Developer Pro Sandbox：与 Developer Sandbox 类似，但提供了更大的数据和文件存储空间，适合更复杂的开发和集成测试。
Full Sandbox：生产环境的完整镜像，包括所有元数据和业务数据。它是进行性能测试、负载测试和模拟生产环境进行最终用户验收测试 (UAT) 的理想选择，但刷新时间长（29天），且成本高昂。
Partial Copy Sandbox：本文的焦点。它介于 Developer Pro 和 Full Sandbox 之间，复制了生产环境的所有元数据，并根据我们定义的沙箱模板 (Sandbox Template) 复制一部分生产数据样本。

那么，Partial Copy Sandbox 究竟在何种场景下能发挥最大价值呢？

主要应用场景：

1. 质量保证 (Quality Assurance, QA) 测试：当开发人员在 Developer Sandbox 中完成功能开发后，需要一个包含真实业务数据的环境来验证功能的正确性。Partial Copy Sandbox 提供了具有代表性的数据样本，让 QA 团队可以模拟真实的用户操作，测试业务逻辑、验证规则和自动化流程是否按预期工作。

2. 用户验收测试 (User Acceptance Testing, UAT)：在功能上线前，业务部门的关键用户需要在接近真实的环境中进行最后验证。Full Sandbox 固然最好，但在资源有限或刷新周期不匹配的情况下，Partial Copy Sandbox 提供了一个成本效益极高的替代方案。它能让用户在熟悉的数据上操作，提供更有效的反馈。

3. 用户培训：为新员工或即将使用新功能的用户提供培训时，一个包含真实结构和样本数据的环境远比一个空荡荡的 Developer Sandbox 更具说服力。Partial Copy Sandbox 可以作为一个逼真的培训平台，让用户在没有风险的情况下学习和实践。

4. 复杂功能调试：某些功能（如复杂的 Sharing Rules、Territory Management 或 CPQ 配置）的正确性高度依赖于数据本身及其关系。在 Partial Copy Sandbox 中，我们可以基于真实的数据样本进行调试，更容易复现和解决在生产环境中遇到的问题。

总而言之，当我们需要一个比 Developer Sandbox 更真实、但又不像 Full Sandbox 那样庞大和昂贵的测试环境时，Partial Copy Sandbox 就是管理员工具箱中一把不可或缺的利器。

原理说明

要充分利用 Partial Copy Sandbox，我们必须理解其核心工作原理，而这背后的关键就是 Sandbox Template（沙箱模板）。

与 Full Sandbox 全盘复制不同，Partial Copy Sandbox 的数据复制过程是“按需选择”的。当我们创建一个 Partial Copy Sandbox 或对其进行刷新时，Salesforce 会执行以下步骤：

复制所有元数据：与所有沙箱类型一样，它首先会完整地复制生产环境中的所有元数据，包括 Apex 类、触发器、Visualforce 页面、Lightning 组件、对象定义、字段、页面布局、权限集等等。这确保了沙箱的应用环境与生产环境在结构上保持一致。
应用沙箱模板复制数据：接下来，Salesforce 会根据我们预先配置好的 Sandbox Template 来选择性地复制数据。这个模板是一个列表，我们在其中明确指定需要复制哪些标准对象 (Standard Objects) 和自定义对象 (Custom Objects) 的记录。

Sandbox Template 的工作机制：

管理员可以在生产环境的“设置”菜单中找到“沙箱模板”并进行创建和编辑。在模板中，我们可以勾选需要包含数据的对象。

关键点在于：

记录抽样：对于每个在模板中被选中的对象，Salesforce 会最多随机抽取 10,000 条记录。这意味着即使生产环境中某个对象有数百万条记录，最多也只会有 10,000 条被复制到 Partial Copy Sandbox 中。
关系保留：Salesforce 会尽力保留记录之间的关系。例如，如果我们选择了 Account 对象和 Opportunity 对象，那么被复制到沙箱中的 Opportunity 记录会保留其与对应 Account 的关联关系（前提是该 Account 记录也被成功复制）。但是，这种关系保留并非绝对。如果一个 Opportunity 关联的 Account 没有被抽中，那么这个 Opportunity 在沙箱中可能会成为“孤儿”记录（其查找字段为空）。因此，精心设计的模板至关重要。
存储限制：Partial Copy Sandbox 的数据存储上限为 5 GB，文件存储上限同样为 5 GB。在设计模板时，我们需要考虑所选对象的数据量，避免超出存储限制导致创建失败。
刷新周期：Partial Copy Sandbox 的最短刷新间隔为 5 天。这意味着我们不能像 Developer Sandbox（1天）那样频繁地刷新它，需要更谨慎地规划刷新计划。

作为管理员，我们的核心任务就是创建一个高效的 Sandbox Template。一个好的模板应该能以最少的数据量，最大程度地还原核心业务场景，从而为测试和培训提供一个高质量的数据集。

示例代码

虽然 Partial Copy Sandbox 的创建和管理主要是通过 Salesforce 的 UI 界面完成的，但作为一名经验丰富的管理员，我们有时需要通过编程的方式来监控和管理我们组织中的所有沙箱。例如，自动化检查沙箱的状态、类型和刷新历史。这时，我们可以利用 Tooling API。

Tooling API 提供了一些 SObject，让我们可以查询有关沙箱的信息。以下是一个使用 SOQL (Salesforce Object Query Language) 查询 SandboxInfo 对象的示例，它可以帮助我们列出当前组织中所有活跃沙箱的基本信息。我们可以在 Developer Console 的 Query Editor 中，勾选 "Use Tooling API" 后运行此查询。

查询所有沙箱信息

/*
 * This SOQL query retrieves information about all sandboxes
 * associated with the production organization.
 * It uses the Tooling API, which must be enabled for the query tool.
 *
 * - Id: The unique identifier for the sandbox.
 * - SandboxName: The name of the sandbox.
 * - LicenseType: The type of sandbox, e.g., 'PARTIAL', 'FULL', 'DEVELOPER'.
 *                This is crucial for identifying our Partial Copy Sandboxes.
 * - Status: The current status of the sandbox, e.g., 'Activated', 'Processing'.
 * - IsAutoActivate: A boolean indicating if the sandbox is set to auto-activate upon refresh completion.
 * - Description: The description provided during sandbox creation.
 */
SELECT
    Id,
    SandboxName,
    LicenseType,
    Status,
    IsAutoActivate,
    Description
FROM
    SandboxInfo

通过这个查询，我们可以快速获得一个沙箱清单，并清晰地看到哪个沙箱是 PARTIAL 类型，它的当前状态是什么。这对于管理多个沙箱环境的大型组织尤其有用，可以帮助我们自动化生成沙箱健康报告或监控刷新进度。

注意事项

在使用 Partial Copy Sandbox 的过程中，管理员必须高度关注以下几点，以避免潜在的风险和问题：

1. 权限与安全

管理权限：只有拥有“管理沙箱 (Manage Sandboxes)”权限的用户才能创建、刷新和删除沙箱。作为管理员，需要谨慎分配此权限。
数据敏感性：Partial Copy Sandbox 复制的是真实的生产数据，尽管只是一个子集。这些数据可能包含客户的个人身份信息 (PII)、商业机密或其他敏感内容。因此，沙箱环境的安全级别应与生产环境同等对待。访问沙箱的用户也应该经过授权。

2. 数据匿名化 (Data Anonymization)

这是最重要但最容易被忽视的一点。直接将生产数据用于测试和开发存在巨大的隐私风险。最佳实践是在每次刷新沙箱后，立即运行数据脱敏或匿名化脚本。Salesforce 提供了官方工具 Salesforce Data Mask，它可以自动替换或屏蔽沙箱中的敏感数据，同时保持数据的格式和引用完整性。作为管理员，建立一个标准的“刷新后检查清单 (Post-Refresh Checklist)”，并把数据匿名化作为第一步，是至关重要的。

3. Sandbox Template 的设计

深思熟虑：不要随意勾选所有对象。与业务分析师和团队负责人沟通，确定哪些对象对于核心测试场景是必不可少的。
注意关系：考虑对象之间的主从 (Master-Detail) 和查找 (Lookup) 关系。如果只选择子对象而不选择其父对象，可能会产生大量无效的孤立数据。优先选择关系链顶端的对象。
存储预算：在选择包含大量数据或文件的对象（如 Case, EmailMessage, Attachment）时，要特别注意 5 GB 的存储限制。

4. 刷新后的配置

沙箱刷新后，许多配置会恢复到生产环境的状态或默认设置，这可能不是我们想要的。管理员需要检查并手动调整以下内容：

电子邮件递送能力 (Email Deliverability)：默认设置为“仅系统邮件 (System email only)”，以防止沙箱意外向真实客户发送测试邮件。如果测试需要发送邮件，必须谨慎地更改为“所有邮件 (All email)”，并确保所有用户记录的邮箱地址已被修改为测试邮箱。

第三方集成：

用户数据：

.invalid

自定义设置和自定义元数据类型：

5. 记录 ID 的变化

从生产环境复制到沙箱后，所有记录的 15 或 18 位 ID 都会发生改变。这意味着任何在生产环境中硬编码 (Hard-coded) 的 ID，例如在公式字段、验证规则、流程或代码中的 ID，在沙箱中都会失效。这是所有沙箱的共性，也是我们在设计解决方案时应避免硬编码 ID 的重要原因。

总结与最佳实践

Partial Copy Sandbox 是 Salesforce 管理员工具库中一个功能强大且极具价值的工具。它在零数据和全数据之间提供了一个完美的平衡点，是实现高质量 QA、UAT 和培训的理想环境。然而，要发挥其最大效用，并规避潜在风险，我们需要遵循一系列最佳实践。

管理员最佳实践清单：

策略性规划模板：在创建或刷新之前，投入时间与业务团队合作，定义一个最小但完整的数据集。将 Sandbox Template 文档化，并定期审查其有效性。
自动化刷新后任务：创建一个标准化的刷新后流程，并尽可能自动化。使用 Apex 脚本、Shell 脚本或 CI/CD 工具来执行数据匿名化、更新用户邮箱、修改命名凭据和自定义设置等任务。
严格的用户访问控制：沙箱也需要权限管理。确保只有需要访问的测试人员、开发人员和业务用户拥有活动账户。定期审查用户列表，并停用不活跃的用户。
清晰的沟通机制：沙箱刷新会清除所有未部署到生产环境的改动。在刷新前，务必提前通知所有相关用户，并给他们足够的时间来备份或完成他们的工作。建立一个共享的沙箱刷新日历。
切勿用作备份：明确告知团队，沙箱（无论是哪种类型）绝对不能作为生产数据的备份解决方案。它的数据随时可能因为刷新而被覆盖。
监控与治理：定期使用 Tooling API 或 Salesforce CLI 检查沙箱的使用情况、状态和上次刷新日期，确保这些宝贵的资源得到了有效利用。

通过遵循这些原则，作为 Salesforce 管理员，我们可以将 Partial Copy Sandbox 从一个简单的测试工具，转变为推动组织创新、保障应用质量和提升用户满意度的战略性资产。

Salesforce Einstein AI 编程实践：开发者视角下的智能预测

九月 15, 2025

阅读全文

Salesforce中文网