您在此处:
归档策略入门
使用归档应用程序创建自动化的计划策略,以管理数据的生命周期。
归档策略
归档策略定义了将数据从生产移动到归档的条件。在创建此策略时,您也可以设置初始保留期。
归档策略使用单个条件(例如LastModifiedDate > 365
days ago)来标识要归档哪些记录。
归档策略也会设置简单的默认保留期,例如“在归档日期后 7 年删除”。保留期设置归档记录的初始到期日期。
清除策略
清除策略定义了永久删除存储在归档中的数据的条件。
清除策略会更改归档策略设置的默认保留期,并为您提供更多权力和灵活性来管理数据销毁。
例如,您可以更快地清除某些记录类型,例如Record Type =
'Test Data' AND Archived Date > 1 year,同时保留更关键的记录,例如Record Type = 'Financial' AND Archived Date > 10
years,而不管归档策略期间默认的 7 年保留集如何。
开始前的关键问题
好的策略始于好的计划。在开始构建之前,请与您的利益相关者讨论这些关键问题。
要归档的内容?
- 哪些根对象及其相关子记录必须归档?例如,已完结个案、旧任务或自定义项目记录。
- 什么是业务驱动因素?您是否试图提高性能、降低存储成本或满足特定的合规性要求?
何时运行?
- 归档和清除策略必须多久运行一次?例如,每天、每周或每月。
- 归档和清除策略必须在什么特定的时间和日期运行?备注 为了减少对用户和系统性能的任何可能影响,我们强烈建议在非高峰时段(例如夜间和周末)运行大型归档或清除进程。
谁有权访问?
- 谁负责创建和管理这些归档和清除策略?备注 通常是系统管理员,但您可以将归档权限集分配给适当的管理员。
- 谁需要在归档后查看数据?例如,管理员、审计员或特定支持团队。
- 谁需要权限才能从归档中取消归档记录并将其恢复回您的实时组织?备注 未归档权限集控制此功能。仅将这些权限集分配给需要的特定用户。
用例和查询
出于测试目的,我们建议从较低的归档策略限制开始。
示例:归档任务
对象:任务
用例:归档满足这些条件的任务。
- 与个案的记录类型相关
- RecordTypeID = 'abc'
- 上次修改时间超过 2 年前
LIMIT = 5 在每次运行中归档 5 个任务及其相关对象。
预览:ID、活动日期、类别(自定义字段)、描述、所有者 ID、主题、状态
SELECT Id FROM Task WHERE Whold IN (SELECT Id FROM Contact
WHERE RecordTypeid = 'abc') AND ActivityDate<LAST_N_DAYS: 730 LIMIT 5示例:归档个案
对象:个案
用例:归档满足这些条件的个案。
- 状态设置为“已结束”
- 30 多天前创建
LIMIT = 5000 在每次运行中归档 5000 个个案及其相关对象。
预览:ID、个案编号、类型、子类别(自定义字段)、问题(自定义字段)
SELECT Id FROM Case WHERE Status = 'Closed'
AND CreatedDate < LAST_N_DAYS: 30 LIMIT 5000示例:从特定客户归档个案
对象:个案
用例:归档满足此条件的个案。
- 状态设置为“已结束”
- 30 多天前创建
- "属于 ID 为""1234""的客户"
LIMIT = 5000 会在每次运行中归档 5000 个个案及其相关对象。
预览:ID、个案编号、类型、子类别(自定义字段)、问题(自定义字段)
SELECT Id FROM Case WHERE accountId IN (SELECT id from Account
WHERE Id ='1234XXXXXXXXXXXXXXX') AND Status = 'Closed'
AND CreatedDate < Last_N_Days:30 LIMIT 5000示例:归档附件
对象:附件
用例:归档附件,其中:
- 父级是处于“已签名”或“已完成石棉”阶段的业务机会。
- 业务机会结束日期在过去 6 个月以上。
LIMIT = 2500 在每次运行中归档 2,500 个附件及其相关对象
预览:ID、父 ID、创建日期
SELECT Id FROM Attachment WHERE ParentId IN (SELECT Id FROM Opportunity
WHERE (StageName='Signed Off' OR StageName='Asbestos Completed')
AND CloseDate < N_MONTHS_AGO:6) LIMIT 2500示例:归档联系人
对象:联系人
用例:归档联系人,其中:
Archiver__c字段设置为True
LIMIT = 1000 会在每次运行中归档 2,500 个联系人及其相关对象。
预览:ID、父 ID、创建日期
SELECT Id FROM Contact WHERE Archiver__c = true LIMIT 1000归档查询最佳实践
要提高归档查询的成功率,请考虑这些建议。
- 对索引字段的写入条件。SOQL 查询的复杂性极大地影响了字段是否适合编入索引。标准和自定义索引不同。
- 请参阅查询和搜索优化作弊表。
- 将结果集限制为可管理的大小。一次检索过多记录会触发表扫描,这比索引查找慢得多。
- 避免与大量数据匹配的过于宽泛的筛选器。如果需要,将日期范围拆分为更小的批次,以减少查询负载。
- 定期验证筛选器逻辑,以确保您只针对必须归档的记录。
- 监控流程日志,以识别重复出现的性能瓶颈或无法在整个流程生命周期中继续的记录。
- 使用日期筛选查询结果。有关更多信息,请查看日期格式和 WHERE 中的日期文字。
- 引用
SystemModstamp,而不是LastModifiedDate。LastModifiedDate由用户驱动,并在用户更改记录时更新。SystemModstamp由系统驱动,并在系统修改记录时更新,包括自动化和后端流程。使用SystemModstamp的查询往往表现更好,因为它们被编入索引。 - 请考虑 Force.com 有自己的 SOQL 查询优化器。有关更多信息,请参阅 Lightning 平台查询优化常见问题解答。
优化归档查询
当您在 Salesforce 中运行查询时,重要的是要确保它们经过优化,以提高效率并避免性能问题,特别是在您使用大型数据集时。
一个常见的问题是,某些筛选器会触发全表扫描,从而对性能产生负面影响。例如:
SELECT Id FROM EmailMessage WHERE ParentId IN (SELECT Id FROM Case
WHERE IsClosed = true) AND LastModifiedDate < LAST_N_MONTHS:13 LIMIT 350000此查询的问题:
IsClosed不是选择性筛选器,这意味着它不能有效地使用索引。LastModifiedDate可以返回 100 多万条记录,这阻止了索引的使用。- 要充分利用查询优化,请在 Salesforce 中对查询的对象进行索引。
- 要提高效率,请删除
IN子查询。
优化查询:
- 移除
IN子查询,这会降低不必要的复杂性。 - 确保对象已编入索引。
对未索引对象的查询不会从性能优化中受益。
- 在开发人员控制台中打开查询计划设置。
查询计划设置会分析查询选择性。要打开此设置,请转到开发人员控制台帮助下的首选项。
- 修改这些筛选器。
- 将
Parent.IsClosed更改为索引字段。 - 使用
SystemModstamp而不是LastModifiedDate,因为SystemModstamp已编入索引且效率更高。 - 要减少扫描的记录数量,请缩小日期范围。例如,
<13和>15。
- 将
以下是更高效的新查询。
SELECT Id FROM EmailMessage WHERE Parent.IsClosed = true
AND LastModifiedDate < LAST_N_MONTHS: <13 and >15 LIMIT 350000
