Salesforce 管理员指南：精通 Partial Copy Sandbox

九月 19, 2025

背景与应用场景

大家好，我是一名 Salesforce 管理员 (Administrator)。在日常工作中，我最重要的职责之一就是维护我们生产环境 (Production Org) 的稳定性和安全性。这意味着任何新的功能、自动化流程或配置变更都不能直接在生产环境中进行，而是必须在一个安全、隔离的环境中进行充分的测试。这个环境，就是我们所熟知的 Sandbox (沙盒)。

Salesforce 提供了多种类型的沙盒，每种都有其特定的用途和限制。最常见的是 Developer Sandbox 和 Developer Pro Sandbox，它们非常适合开发人员进行编码和单元测试，因为它们可以快速创建和刷新，但它们只复制生产环境的元数据 (Metadata)，不包含任何业务数据。与之相对的是 Full Sandbox，它是生产环境的完整镜像，包含所有元数据和业务数据。这使得 Full Sandbox 成为进行性能测试、集成测试和用户培训的理想场所，但它的刷新周期很长（29天），并且成本高昂。

在 Developer Sandbox 和 Full Sandbox 之间，存在一个巨大的空白地带。我们经常面临这样的场景：

用户验收测试 (UAT - User Acceptance Testing): 业务用户需要测试新功能，但如果沙盒里没有真实感的数据，他们很难验证流程是否符合实际业务场景。例如，测试一个复杂的折扣审批流程，需要有相关的客户、机会和产品数据。
质量保证 (QA - Quality Assurance): QA 团队需要验证新功能在不同数据条件下的表现。一个空的沙盒无法满足这种需求，而 Full Sandbox 的数据量又过于庞大，可能导致测试效率低下。
新员工培训: 我们希望新员工在一个与真实环境相似的系统里学习操作，但又不希望他们接触到生产环境中的所有敏感数据。

为了解决这些问题，Salesforce 提供了完美的中间方案——Partial Copy Sandbox。它正如其名，复制了生产环境的所有元数据，以及部分经过筛选的业务数据。这使得它既能提供具有代表性的数据集来进行高质量的测试和培训，又比 Full Sandbox 更加轻量、灵活且刷新周期更短（5天）。作为管理员，理解并善用 Partial Copy Sandbox 是我们制定高效、经济的环境管理策略的关键。

原理说明

Partial Copy Sandbox 的核心工作机制依赖于一个非常重要的配置工具：Sandbox Template (沙盒模板)。在我们创建或刷新一个 Partial Copy Sandbox 之前，必须先创建一个沙盒模板。这个模板就像一个“数据采购清单”，我们通过它来精确地告诉 Salesforce，需要从生产环境中复制哪些对象 (Object) 的记录 (Record)。

沙盒模板 (Sandbox Template)

沙盒模板的配置界面非常直观。作为管理员，我会登录到生产环境，在“设置”中找到“沙盒”，然后进入“沙盒模板”选项卡。在这里，我可以新建或编辑模板。

在模板中，我会看到生产环境中所有标准和自定义对象的列表。我可以勾选我想要包含在沙盒中的对象。例如，对于一个销售流程的 UAT，我可能会选择以下核心对象：

Account (客户)
Contact (联系人)
Opportunity (业务机会)
Product2 (产品)
Pricebook2 (价格手册)
Quote (报价)

一个关键的特性是，Salesforce 会智能地处理对象之间的关系。当我选择了 Opportunity 对象时，系统会自动将其依赖的父对象记录（比如关联的 Account）也包含进来，以保证数据的引用完整性。这极大地简化了我的配置工作，避免了数据孤岛的产生。

数据采样与存储限制

需要强调的是，Partial Copy Sandbox 并不是复制所选对象的所有记录，而是进行数据采样。它会尝试从每个选定的对象中抽取最多 10,000 条记录。这个采样过程是确定性的，但我们无法控制具体会抽取哪些记录。

此外，Partial Copy Sandbox 有明确的存储限制：5 GB 的数据存储空间和 5 GB 的文件存储空间。这要求我们在设计沙盒模板时必须精打细算。如果选择了包含大量富文本字段、附件或拥有众多字段的对象，存储空间可能会很快被耗尽。因此，在选择对象时，我通常会遵循“按需最小化”的原则，只选择与测试场景直接相关的对象。

刷新周期

Partial Copy Sandbox 的刷新周期是 5 天。这个频率远高于 Full Sandbox 的 29 天，为我们的敏捷开发和迭代测试提供了极大的便利。我们可以根据每个 Sprint 的节奏来安排沙盒刷新，确保测试团队总能在一个相对“新鲜”且数据相关的环境中工作。

示例代码

作为一名管理员，虽然我们主要通过 Salesforce 的设置界面来管理沙盒，但在沙盒刷新完成后，使用一些简单的代码工具来验证数据是必不可少的。最常用的工具就是 SOQL (Salesforce Object Query Language)。这可以帮助我快速确认沙盒模板是否按预期工作，以及关键对象的数据是否已经成功复制。

假设我已经使用一个包含了 Account、Contact 和 Opportunity 对象的模板刷新了一个 Partial Copy Sandbox。现在，我登录到这个新的沙盒中，打开 Developer Console (开发者控制台) 的 Query Editor，执行以下查询来验证数据。

示例 1: 验证核心对象的数据量

这个查询用来检查主要对象（例如 Account）是否已经成功复制了记录。由于 Partial Copy 最多为每个对象复制 10,000 条记录，查询结果应该是一个小于等于 10,000 的正数。

/*
 * @description: 该 SOQL 查询用于计算 Partial Copy Sandbox 中 Account 对象的总记录数。
 * 这是刷新后最基本的健康检查，用于确认数据复制过程已成功执行。
 * 如果生产环境中的客户数量超过 10,000，我们期望这里的结果是 10,000。
 * 如果生产环境中的客户数量少于 10,000，结果应与生产环境中的数量一致。
 */
SELECT COUNT(Id) FROM Account

示例 2: 验证对象间的关联关系

仅有数据量是不够的，我们更关心数据的质量和完整性。这个查询用来验证复制过来的 Account 是否也带来了相关的 Opportunity 记录，这证明了沙盒模板在处理对象关系时是有效的。

/*
 * @description: 此查询用于查找那些至少拥有一个关联 Opportunity 的 Account 记录。
 * @purpose: 验证数据复制过程中是否保持了父子关系（Account-Opportunity）。
 *           一个高质量的测试数据集应该包含这种关联数据，以便业务用户可以测试完整的销售流程。
 *           我们限制返回结果为 100 条，仅用于抽样检查，而不是统计完整数据。
 */
SELECT Id, Name, (SELECT Id, Name, StageName FROM Opportunities)
FROM Account
WHERE Id IN (SELECT AccountId FROM Opportunity)
LIMIT 100

通过执行上述 SOQL 查询，我可以快速地对新刷新的 Partial Copy Sandbox 进行一次“体检”，确保它已经准备好交付给 QA 或 UAT 团队使用。这比随机点开几个页面去目视检查要高效和可靠得多。

注意事项

虽然 Partial Copy Sandbox 非常强大，但在使用过程中，我们必须注意以下几点，以避免潜在的问题。

1. 权限 (Permissions)

创建和管理沙盒需要用户拥有 “管理沙盒 (Manage Sandboxes)” 的系统权限。在分配任务时，需要确保负责环境管理的同事（通常是管理员或发布经理）拥有此权限。

2. 精心规划沙盒模板

沙盒模板是成功的关键。一个糟糕的模板可能会导致复制的数据毫无用处（例如，只有 OpportunityLineItem 但没有相关的 Product2 和 Pricebook2 记录），或者因为包含了太多非必需的对象而迅速耗尽存储空间。我的建议是：

从核心业务流程出发：识别出测试场景中最核心的对象（如销售流程的 Account, Opportunity），优先把它们加入模板。
逐步扩展：先用一个包含少量核心对象的模板进行一次刷新，验证数据可用后，再根据需要逐步添加其他相关对象。
定期审查：随着业务的发展，测试所需的数据也在变化。定期（例如每季度）审查和更新沙盒模板，确保它依然满足当前的需求。

3. 数据抽样的随机性

我们无法控制 Salesforce 具体复制哪些记录。这意味着某些特定的、用于边缘案例测试的记录可能不会被包含进来。如果测试必须依赖某条特定的记录，最佳实践是在沙盒刷新后，手动在沙盒中创建或导入这条记录。

4. 数据隐私与合规性

Partial Copy Sandbox 复制的是真实的生产数据，其中可能包含客户的个人身份信息 (PII) 或其他敏感数据。这带来了合规性风险。为了缓解这个问题，强烈建议在沙盒刷新后立即运行 Salesforce Data Mask 或其他数据脱敏工具，对敏感字段（如姓名、电话、邮箱）进行匿名化处理，以保护数据隐私。

5. API 与集成

沙盒刷新后，所有指向生产环境的硬编码 URL、命名凭据 (Named Credentials) 或集成端点都需要被重新配置，以指向测试系统或沙盒环境对应的端点。同时，需要确保所有出站邮件功能（邮件提醒等）在沙盒中被正确配置或禁用，以防止向真实客户发送测试邮件。

总结与最佳实践

总而言之，Partial Copy Sandbox 是 Salesforce 环境管理工具箱中一把不可或缺的“瑞士军刀”。它完美地平衡了数据相关性和环境管理成本，是支持 UAT、QA 测试和有效培训的理想选择。

作为一名 Salesforce 管理员，以下是我在实践中总结出的最佳实践：

明确目标：在创建沙盒之前，清晰地定义它的用途。是为了 UAT？QA？还是培训？目标决定了沙盒模板的设计和数据的需求。
文档化你的模板：为你的沙盒模板创建一份简单的说明文档，解释为什么选择了这些对象。这对于未来的维护和知识传承至关重要。
沟通是关键：在刷新沙盒前，提前通知所有将要使用它的用户。告知他们刷新的时间点以及数据将被覆盖的事实，避免他们的工作成果丢失。
将数据脱敏纳入流程：将运行 Data Mask 或其他脱敏脚本作为沙盒刷新后检查清单 (Post-Refresh Checklist) 的一个标准步骤。
监控存储使用情况：定期检查 Partial Copy Sandbox 的数据和文件存储使用量，确保存储空间不会成为测试工作的瓶颈。

通过遵循这些原则，我们可以最大限度地发挥 Partial Copy Sandbox 的价值，为我们的团队提供一个稳定、高效且数据丰富的测试环境，最终保障我们对生产环境所做的每一次变更都是高质量和可靠的。

Salesforce中文网