Deleted Record Management
Though CopyStorm will faithfully back up records that have been deleted in Salesforce, there are a few cases where Salesforce will delete records without the deletion being visible to CopyStorm. These situations occur when:
- A hard delete is performed in Salesforce.
- A Salesforce table does not track deleted records (this occurs in system tables).
Best Practices for Hard Deleted Records
When a Salesforce record is deleted, Salesforce marks the record as deleted by setting the “isDeleted” field to true and by putting the record in the recycle bin. When CopyStorm runs it retrieves all updated records — including those which have been marked as deleted. This is used to record record deletion in the CopyStorm database, but there are a few cases where a record is deleted and not put in the recycle bin.
This is called a hard delete. When this happens, the normal CopyStorm update flow will never determine that the record has been deleted.
There are four primary conditions where hard deletes occur:
- A user manually empties a recycle bin.
- A record has been in the recycle bin for a long time (weeks) and Salesforce automatically deletes it from the recycle bin.
- Two records are merged.
- Salesforce deletes a record without using the recycle bin. This does not occur on most tables, but this article identifies the handful of tables with this issue.
To solve this problem, the “isDeleted” field needs to be updated to reflect records that have been hard deleted in Salesforce. The CopyStorm/Medic fixIsDeleted tool has been designed to do this exact task.
How often (and if) your site resolves hard deletes is up to you. If you would like the CopyStorm backup to reflect hard deletes then the following list may help — it contains known tables that can contain hard deletes in a out-of-the-box Salesforce instance:
| Table Name | Common Impact | Description |
|---|---|---|
| OpportunityLineItem | High | The operation of syncing an opportunity with a quote does a hard delete on existing line items. |
| OpportunityContactRole | High | When team assignments change hard deletes from Salesforce can happen. |
| .*History | Low | Older history records can be automatically hard deleted by Salesforce. |
| .*Share | Low | When sharing rules are modified, Saleforce hard deletes share records. |
| .*Feed | Low | Feed records (from Chatter) are sometimes deleted for reasons that are not clear. We suspect this occurs when a chatter feed is deleted. |
Because hard deletes can be caused by a site’s business practices (or by specific user behavior), best practices are often site specific. This is Capstorm’s recommendation:
- If your site uses Salesforce quotes, then run a daily CopyStorm/Medic job to fix hard delete problems within the OpportunityLineItem table.
- Each weekend, run CopyStorm/Medic to fix hard delete problems on all custom tables and core Salesforce tables. Core Salesforce tables are listed in the sample CopyStorm/Medic file found here.
In practice, we have found that very few custom or core Salesforce tables need to be scanned. Over time we reduce the number of tables scanned based on problems reported by CopyStorm/Medic.
Best Practices for Non-Tracked Records
There are a number of system tables in Salesforce which do not track deletions or allow restoration from the Salesforce recycle bin.
Tables that follow this behavior can be found in the CopyStorm database by running the following SQL query:
- select distinct tableName from copyForceTableField where tableName not in (select tableName FROM copyForceTableField where name=’IsDeleted’);
Most of the time a site will not care if these tables contain deleted records. If your site requires that deleted data be pruned, the best practice is to periodically drop or truncate these tables. Once dropped, the next run of CopyStorm will automatically repopulate the tables.