Salesforce 字段审计追踪：数据保留与合规性的深度解析

八月 27, 2025

背景与应用场景

在任何复杂的企业级系统中，数据审计都是一个至关重要的环节。了解“谁在何时对何事做了何种更改”不仅是内部治理的要求，更是满足外部法规遵从性的基石。Salesforce 作为全球领先的 CRM 平台，提供了强大的数据追踪能力。标准的 Field History Tracking (字段历史跟踪) 功能允许我们跟踪特定对象上最多 20 个字段的变更历史。这些历史数据通常保存在相关的历史对象中（例如，`AccountHistory`、`CaseHistory`）。

然而，标准功能存在两个核心限制：

字段数量限制： 每个对象最多只能跟踪 20 个字段。对于核心业务对象（如客户、合同），这往往是不够的。
数据保留时间限制： Salesforce 仅在线保留 18-24 个月的字段历史数据。超过这个期限的数据会被自动删除。

对于许多行业，尤其是金融、医疗和公共部门，这样的限制是无法接受的。法律法规（如 Sarbanes-Oxley Act (SOX), HIPAA, GDPR）常常要求企业将审计数据保留 5 年、7 年、10 年甚至更长时间。当审计人员要求提供三年前某个关键客户记录的变更历史时，标准功能便无能为力了。

为了解决这一痛点，Salesforce 推出了 Field Audit Trail (字段审计追踪)。作为 Salesforce Shield 产品套件的一部分，Field Audit Trail 是一项付费的增强功能，它极大地扩展了 Salesforce 的原生审计能力。其核心价值在于：

延长数据保留期限： 允许您为特定对象定义长达 10 年的数据保留策略。
增加追踪字段数量： 可将每个对象的追踪字段上限从 20 个提高到 60 个。

Field Audit Trail 的典型应用场景包括：

法规遵从性： 在金融服务或医疗保健等受到严格监管的行业中，满足法律对数据审计日志的长期保留要求。
内部审计与安全取证： 当发生数据泄露或内部违规操作时，能够回溯多年的数据变更历史，精准定位问题根源和责任人。
数据治理： 维护关键数据的完整性和准确性，为长期的数据治理策略提供可靠的历史依据。
业务纠纷解决： 在处理客户投诉或合同纠纷时，提供不可篡改的、长期的历史数据作为证据。

原理说明

要理解 Field Audit Trail 的工作原理，首先需要明白它是在标准 Field History Tracking 的基础上构建的。其核心机制可以概括为“分层存储”和“策略驱动的归档”。

当您为一个对象启用了 Field Audit Trail 并定义了数据保留策略（例如，为 Account 对象保留 10 年历史）后，整个数据生命周期如下：

热数据阶段 (Hot Data)：
当一个被追踪的字段发生变更时，Salesforce 像往常一样，在标准的历史对象（如 `AccountHistory`）中创建一条记录。这部分数据被视为“热数据”，因为它们是最近发生的，查询频率较高。这些数据可以被标准报表、SOQL 查询等轻松访问，并保留在 Salesforce 的主数据库中，期限为 18-24 个月。
归档阶段 (Archiving)：
一旦 `AccountHistory` 中的数据超过了标准的 18 个月保留期，Salesforce 的后台归档进程就会被触发。这个进程会将这些“冷数据” (Cold Data) 从 `AccountHistory` 对象移动到一个名为 FieldHistoryArchive 的特殊存储中。
冷数据存储 (Cold Storage)：
FieldHistoryArchive 并非一个标准的 Salesforce 对象，而是一个 Big Object (大对象)。Big Objects 专为存储海量数据（亿级甚至十亿级记录）而设计，构建在可扩展的底层大数据技术（如 Apache HBase）之上。它提供了稳定、经济高效的长期数据存储方案，但查询方式和标准 SObject 有所不同。

因此，完整的审计数据被分成了两部分：

近期的（18个月内）： 存储在标准历史对象中（例如 `AccountHistory`），可以通过常规 SOQL 查询。
远期的（超过18个月）： 存储在 FieldHistoryArchive 大对象中，需要通过特定的查询方式（如标准 SOQL 的特定语法或 Async SOQL (异步 SOQL)）来访问。

当您需要查询一条记录的完整历史时，您可能需要同时查询这两个地方，然后将结果合并。这种设计兼顾了对近期数据的高性能访问和对海量历史数据的低成本存储。

示例代码

Field Audit Trail 的配置主要通过 Salesforce 的 Setup 界面完成，但查询归档后的数据则需要通过 API 和代码。由于 FieldHistoryArchive 是一个 Big Object，处理大规模数据时，官方强烈推荐使用 Async SOQL。

查询 FieldHistoryArchive 的字段

在编写查询之前，了解 FieldHistoryArchive 的关键字段至关重要：

ParentId: 发生变更的记录 ID（例如，某个 Account 记录的 ID）。
FieldHistoryType: 发生变更的对象 API 名称（例如，'Account'）。
FieldName: 发生变更的字段 API 名称（例如，'AnnualRevenue'）。
OldValue: 字段的旧值。
NewValue: 字段的新值。
CreatedById: 执行变更操作的用户 ID。
CreatedDate: 变更发生的时间戳。

示例 1: 使用标准 SOQL 查询 FieldHistoryArchive

对于小批量、目标明确的数据查询，可以使用标准 SOQL。但请注意，对 Big Object 的 SOQL 查询有严格限制，必须在 WHERE 子句中包含索引字段。FieldHistoryArchive 的主键索引由 FieldHistoryType, ParentId, 和 CreatedDate 组成。

// 查找特定 Account 记录在 2020 年的所有归档历史
// 注意：这个查询可能因为数据量大而超时，仅适用于小范围查询
List<FieldHistoryArchive> archives = [
    SELECT ParentId, FieldName, OldValue, NewValue, CreatedDate, CreatedById 
    FROM FieldHistoryArchive
    WHERE FieldHistoryType = 'Account'
    AND ParentId = '001xx000003D8gPAAS' // 替换为具体的 Account ID
    AND CreatedDate >= 2020-01-01T00:00:00Z 
    AND CreatedDate < 2021-01-01T00:00:00Z
    ORDER BY CreatedDate DESC
];

for (FieldHistoryArchive arch : archives) {
    System.debug('Field: ' + arch.FieldName + 
                 ', Old: ' + arch.OldValue + 
                 ', New: ' + arch.NewValue + 
                 ', Changed on: ' + arch.CreatedDate);
}

示例 2: 使用 Async SOQL 查询 FieldHistoryArchive（推荐方式）

当需要处理大量归档数据时（例如，导出某一年所有客户的变更历史），必须使用 Async SOQL。这是一种通过 REST API 提交查询作业，并在后台处理，完成后再获取结果的方式。

以下是使用 REST API 提交 Async SOQL 查询作业的步骤和示例。

第 1 步: 提交查询作业 (POST 请求)

向 /services/data/vXX.X/async-queries 端点发送一个 POST 请求。请求体包含您的 SOQL 查询。

端点: /services/data/v58.0/async-queries

方法: POST

请求头:

Authorization: Bearer [Your_Session_ID]
Content-Type: application/json

请求体:

{
  "query": "SELECT ParentId, FieldName, NewValue, OldValue, CreatedDate FROM FieldHistoryArchive WHERE FieldHistoryType = 'Account'"
}

Salesforce 会返回一个作业 ID，表示作业已成功提交。

{
  "id": "751xx000000001ZAAQ",
  "state": "InProgress",
  "createdDate": "2023-10-27T06:43:08.000+0000",
  "apiVersion": 58.0,
  "query": "SELECT ParentId, FieldName, NewValue, OldValue, CreatedDate FROM FieldHistoryArchive WHERE FieldHistoryType = 'Account'",
  "operation": "query"
}

第 2 步: 检查作业状态 (GET 请求)

定期轮询作业状态端点，直到 state 变为 "JobComplete"。

端点: /services/data/v58.0/async-queries/751xx000000001ZAAQ (使用上一步返回的 ID)

方法: GET

第 3 步: 获取查询结果 (GET 请求)

作业完成后，使用结果端点获取数据。数据通常以 CSV 格式返回。

端点: /services/data/v58.0/async-queries/751xx000000001ZAAQ/results

方法: GET

响应将是 CSV 格式的查询结果，您可以将其解析或直接保存为文件。

注意事项

作为技术架构师，在规划和实施 Field Audit Trail 时，必须考虑以下关键点：

权限和许可：
- 功能许可： Field Audit Trail 是 Salesforce Shield 的一部分，需要额外购买许可。
- 配置权限： 用户需要“View Setup and Configuration”和“Customize Application”权限才能定义历史数据保留策略。
- 查询权限： 用户需要对 FieldHistoryArchive 对象的读取权限，以及对父对象（如 Account）的读取权限，才能查询到相关数据。
API 限制和治理：
- Async SOQL 限制： Async SOQL 有其自身的每日作业和查询限制，独立于常规的 API 调用限制。在设计批量数据导出方案时，必须考虑这些限制。
- 查询性能： 对 Big Object 的查询性能高度依赖于索引。查询 FieldHistoryArchive 时，务必在 WHERE 子句中尽可能使用索引字段 (FieldHistoryType, ParentId)，以避免全表扫描导致的性能问题或查询失败。
数据延迟：
从标准历史对象到 FieldHistoryArchive 的归档过程是异步的，并非实时发生。这意味着刚超过 18 个月的数据可能不会立即出现在归档中，通常会有一定的延迟。在设计审计流程时要考虑到这一点。
不可变性：
一旦数据被写入 FieldHistoryArchive，它就是不可变的。您无法通过 DML 操作修改或删除这些记录，这确保了审计日志的完整性和不可篡改性。
查询复杂性：
Big Object 的 SOQL 不支持所有标准 SOQL 功能，例如 `JOIN`、`GROUP BY` 的复杂聚合函数、`LIKE` 的部分通配符等。这意味着复杂的分析查询可能无法直接在 Salesforce 内部完成，通常需要将数据导出到外部系统。

总结与最佳实践

Field Audit Trail 是 Salesforce 平台上一项强大的、企业级的审计和合规工具。它通过提供长达 10 年的数据保留策略和更多的可追踪字段，完美弥补了标准字段历史跟踪功能的不足，是受监管行业或有严格内部审计要求的企业的必备功能。

作为技术架构师，为了最大化其价值并避免潜在的陷阱，我们建议遵循以下最佳实践：

策略性规划，而非全面开启：

在项目初期就与业务、法务和合规团队合作，明确哪些对象和字段的数据具有长期审计价值。避免盲目地为所有字段启用追踪，因为这会产生海量数据，增加存储成本和查询复杂性。只追踪那些对合规性、安全性或核心业务流程至关重要的字段。
为查询而设计架构：

深刻理解 FieldHistoryArchive 的 Big Object 特性及其查询限制。在设计任何依赖于归档数据的报表、仪表板或集成时，优先考虑使用 Async SOQL。对于需要复杂分析和聚合的场景，应设计一个将数据从 FieldHistoryArchive 定期导出到外部数据仓库（如 Snowflake, Google BigQuery）的ETL流程。在那里，您可以使用更强大的分析工具进行数据挖掘。
建立统一的审计数据访问层：

由于审计数据分散在标准历史对象和 FieldHistoryArchive 中，可以考虑创建一个统一的数据访问服务（例如，一个 Apex 服务或中间件 API）。该服务封装了查询逻辑，能够智能地从两个数据源获取数据并合并，为上层应用提供一个完整的、无缝的历史数据视图。
监控与治理：

定期监控 Async SOQL 的使用情况和 Big Object 的数据增长量。确保您的数据架构能够应对未来的数据量增长，并确保 API 调用没有超出限制。制定清晰的治理策略，规定谁有权访问这些敏感的审计数据。

通过遵循这些原则，您可以有效地利用 Field Audit Trail 构建一个稳健、合规且可扩展的 Salesforce 数据审计解决方案，为您的企业保驾护航。

Salesforce中文网