Updated for changes introduced in UR12 and UR16. See general steps below.
I recently had a customer ask me about the purpose of the DeletionService maintenance operation (AsyncOperationType = 14) executed by the AsyncService in Dynamics CRM 2011. To provide some context from CRM 4.0, the DeletionService performed physical data cleanup on records that had been logically deleted through the application by setting the DeletionStateCode = ‘2’. This behavior no longer occurs in CRM 2011 – when records are deleted through the application, they are physically deleted from the database. So, why the need for a DeletionService maintenance operation?
The database maintenance performed by the DeletionService operation focuses both on organization-wide cleanup and record-specific cleanup. For the latter cleanup to be performed it’s important to note that during the initial delete action while records are removed from the entity tables, they are also inserted to the dbo.SubscriptionTrackingDeletedObject table. This table provides the DeletionService with specific ObjectId’s that have been removed so that further cleanup can be performed asynchronously.
Suppose I have an existing Account:
I then delete the Account through the native application. Notice, the record is physically deleted from AccountBase, but has now been inserted to SubscriptionTrackingDeletedObject. An example of how this table is used can be seen in the stored procedure ‘p_GetTablesForDeletion’, which gets called at the beginning of the DeletionService operation to gather up entity table names where records have been deleted. It joins to the SubscriptionTrackingDeletedObject table to identify those tables.
So what type of cleanup does this DeletionService perform you say? Primarily, matchcode (duplicate detection), offline sync subscription, and principalobjectaccess/POA (inherited and shared privileges) records left behind from deleted entity records as well as a few other odds and ends.
Here are the general steps that the DeletionService performs when executing its maintenance routine:
- Gather up duplicate detection-enabled entity tables requiring cleanup
- Perform entity specific Matchcode record cleanup for each entity table returned by the stored procedure
- Get the expired subscription days setting from Organization table
- Delete associated Sync Subscription that have expired
- Delete associated PrincipalObjectAccess (POA) records
- Delete SubscriptionTrackingDeletedObject records that have expired
- UR16: Cleanup orphaned attachment records
- UR12: Delete MetadataSyncTrackingDeletedObject records that have expired
- Delete PostRegarding records based on deleted Posts (activity feeds)
So now you know, the rest of the story…