We’ve configured a data retention policy in our D365 9.0 event management module to automatically delete event registrations older than 12 months. The policy has been active for 6 weeks now but historical records aren’t being purged. Our database storage continues to grow and we’re seeing performance degradation on event queries.
The retention policy is set up with these parameters:
RetentionPeriod: 365 days
TargetEntity: msevtmgt_eventregistration
RecurrencePattern: Weekly
State: Active
The background deletion job shows as “Succeeded” in the system jobs log, but when I query the event registration table, records from 2022-2023 are still present. I’ve verified the policy is targeting the correct entity and the cascading delete behavior is set on related entities. Has anyone encountered similar issues with retention policies not executing properly?
Based on your findings, here’s a comprehensive solution addressing all three critical areas:
Data Retention Policy Configuration:
Your retention policy configuration looks correct, but you need to verify the query criteria. Navigate to Settings > Data Management > Data Retention Policies and edit your policy. Click “View Records” to see what the query actually returns. In D365 9.0, there’s a known issue where date filters in retention policies sometimes use UTC conversion incorrectly, causing the query to return zero records even though data exists.
Background Deletion Job Monitoring:
The “Succeeded” status is misleading here. Query the AsyncOperationBase table directly to get actual metrics:
Check the Message field for processed record counts
Review the StatusCode (30 = Succeeded but might be 0 records)
Look at ExecutionTimeSpan to see if the job is timing out early
Examine the FriendlyMessage field for any warnings
For D365 9.0 specifically, there’s a 2-hour timeout on bulk delete jobs. If you have millions of event records, the job might be timing out before completing. Consider breaking the retention into smaller batches by adding additional filters (like event type or date ranges).
Entity Relationship and Cascading Delete Settings:
This is likely your main issue given the custom plugin. Here’s the resolution path:
Audit the relationship cascade settings: Export your event registration entity customization and search for all relationships. Any relationship with Cascade=“NoCascade” or Cascade=“Restrict” will block deletion. Update these to Cascade=“Cascade” for relationships where child records should be deleted with parent events.
Handle the custom Delete plugin: Your audit logging plugin needs modification. Update it to check the execution context and skip processing for bulk operations:
Check if the MessageName is “Delete” AND the Stage is not from a bulk operation
Add error handling that logs issues but doesn’t throw exceptions during bulk deletes
Consider moving audit logic to a post-operation stage with failure tolerance
Verify field-level security: Check if any fields on event registration have field-level security enabled. This can cause silent failures in bulk operations even with proper entity permissions.
Test with manual bulk delete first: Before relying on the retention policy, create a manual bulk delete job with the same criteria. This will give you better error visibility and confirm the configuration works.
Monitor storage after fix: Once corrected, the initial cleanup might take several cycles. Monitor your database storage metrics and the deletion job execution logs for at least 3-4 weeks to ensure consistent operation.
After implementing these changes, deactivate the old retention policy and create a new one to ensure clean execution state. The combination of plugin interference and potentially misconfigured cascade settings is preventing your deletions from executing properly.
This draft is based on general Microsoft Dynamics 365 Sales knowledge. It has not been verified against your specific version and environment. Practitioners: verify the steps and share your experience below.
Check if your event registration records have any active dependencies or relationships that might be blocking deletion. Even though the job shows succeeded, it might be skipping records due to referential integrity constraints. Navigate to Settings > Data Management > Bulk Record Deletion and review the failure logs for your retention job.
I’ve seen this exact behavior with retention policies in D365 9.0. The issue is usually related to entity relationship cascade settings. When you have custom entities or relationships with the event registration entity, the cascade delete might be set to ‘Restrict’ instead of ‘Cascade All’. This causes the deletion job to silently skip records rather than fail outright.
Go to Settings > Customizations > Entities > Event Registration > Relationships and check each relationship’s cascade configuration. Look specifically for any custom entities or plugins that reference event registrations. You might need to temporarily disable certain relationships, run a manual bulk delete, then re-enable them with proper cascade settings.
Another thing to verify - are you monitoring the actual background deletion job execution details? The system job might show “Succeeded” but process zero records. Check the AsyncOperation table directly and look at the Message field for your retention job. It should show how many records were evaluated and deleted in each run.
Thanks for the suggestions. I checked the AsyncOperation details and you’re right - the job is evaluating 0 records each run even though thousands of records meet the age criteria. I also found that we have a custom plugin registered on the Delete message for event registrations that was implemented for audit logging purposes. Could this be interfering with the retention policy execution?
Tested this on D365 9.0 and recreating the retention policy with an explicit UTC date filter in Data Management immediately resolved the historic event records not being flagged for deletion.
Yes, custom plugins on Delete can definitely interfere with bulk deletion operations. If your plugin throws any exception or has performance issues, it can cause the entire deletion batch to fail silently. The retention policy uses bulk delete under the hood which has different execution context than manual deletions. Try temporarily disabling your custom delete plugin and running a test retention cycle to see if records get deleted. If that works, you’ll need to refactor your plugin to handle bulk operations more efficiently or exclude it from bulk delete context.
Check the Security Roles assigned to the user context running the retention policy. In D365 9.0, retention policies execute under the system administrator context by default, but if you’ve customized the owner or there are field-level security restrictions on the event registration entity, it could prevent bulk deletion even when the job reports success.