Describe the issue
When a Document Attachment record is deleted in Business Central with the External Storage feature enabled and Delete from External Storage = true, the file is not deleted from the configured external storage (e.g. Azure Blob Storage). No delete request is ever sent to the storage provider.
We wanted to raise this for clarification: is this the intended behaviour by design, or is it an unintended gap?
The fact that it is not delete in external storage might also have consequences because of GDPR.
Expected behavior
Expected Behavior
When Delete from External Storage = true and a Document Attachment stored externally is deleted from BC, the corresponding file should be deleted from external storage (or at minimum, a delete request should be sent).
Actual Behavior
No delete request is sent. The file remains in external storage indefinitely, leading to orphaned blobs accumulating over time.
Steps to reproduce
1. Install and configure the "External Storage – Document Attachments" extension (ID: 5f2e93a0-6083-4718-b05a-7ac89be5644d, v28.0.0.0) with an Azure Blob Storage connector.
2. In DA External Storage Setup, set Enabled = true and Delete from External Storage = true.
3. Open any record (e.g. an Item) and attach a file → the file uploads successfully to Azure Blob Storage. ✅
4. Delete that Document Attachment record from BC.
5. Check Azure Blob Storage → the blob remains. No delete request was sent. ❌
Additional context
Code Observation
In codeunit 8751 "DA External Storage Impl.", the event subscriber responsible for triggering deletion is:
text
[EventSubscriber(ObjectType::Table, Database::"Document Attachment", OnAfterDeleteEvent, '', true, true)]
local procedure OnAfterDeleteDocumentAttachment(var Rec: Record "Document Attachment"; RunTrigger: Boolean)
This calls DeleteFromExternalStorage(Rec), which contains:
text
if not DocumentAttachment.Find() then
exit(false);
Since OnAfterDeleteEvent fires after the record has already been deleted from the database, DocumentAttachment.Find() will always return false at this point, causing the method to exit before any delete request is sent to external storage.
Question to the Team
We'd like to understand the intended design:
· Option A – By design: Deletion from external storage is not meant to happen automatically on record delete, and a separate cleanup mechanism is expected (e.g. manual action or job queue). If so, could this be clarified in documentation?
· Option B – Needs a change: The event should be OnBeforeDeleteEvent instead of OnAfterDeleteEvent, so that Find() can succeed while the record still exists, and the delete request can be sent to external storage before the BC record is removed.
· Option C – The Find() guard should be removed: If staying on OnAfterDeleteEvent is intentional, then the Find() guard in DeleteFromExternalStorage() is unnecessary — the Rec parameter already carries all required field values (External File Path, Stored Externally, etc.) in memory, and the Find() serves no purpose in this context.
Environment
· BC Version: 28.0
· Extension: External Storage - Document Attachments v28.0.0.0 (5f2e93a0-6083-4718-b05a-7ac89be5644d)
· External Storage Connector: Azure Blob Storage (c9ce86fe-cb70-4b79-be03-d21856b1a4ca)
· Deployment: SaaS (Online)
I will provide a fix for a bug
Describe the issue
When a Document Attachment record is deleted in Business Central with the External Storage feature enabled and Delete from External Storage = true, the file is not deleted from the configured external storage (e.g. Azure Blob Storage). No delete request is ever sent to the storage provider.
We wanted to raise this for clarification: is this the intended behaviour by design, or is it an unintended gap?
The fact that it is not delete in external storage might also have consequences because of GDPR.
Expected behavior
Expected Behavior
When Delete from External Storage = true and a Document Attachment stored externally is deleted from BC, the corresponding file should be deleted from external storage (or at minimum, a delete request should be sent).
Actual Behavior
No delete request is sent. The file remains in external storage indefinitely, leading to orphaned blobs accumulating over time.
Steps to reproduce
Additional context
Code Observation
In codeunit 8751 "DA External Storage Impl.", the event subscriber responsible for triggering deletion is:
text
[EventSubscriber(ObjectType::Table, Database::"Document Attachment", OnAfterDeleteEvent, '', true, true)]
local procedure OnAfterDeleteDocumentAttachment(var Rec: Record "Document Attachment"; RunTrigger: Boolean)
This calls DeleteFromExternalStorage(Rec), which contains:
text
if not DocumentAttachment.Find() then
exit(false);
Since OnAfterDeleteEvent fires after the record has already been deleted from the database, DocumentAttachment.Find() will always return false at this point, causing the method to exit before any delete request is sent to external storage.
Question to the Team
We'd like to understand the intended design:
· Option A – By design: Deletion from external storage is not meant to happen automatically on record delete, and a separate cleanup mechanism is expected (e.g. manual action or job queue). If so, could this be clarified in documentation?
· Option B – Needs a change: The event should be OnBeforeDeleteEvent instead of OnAfterDeleteEvent, so that Find() can succeed while the record still exists, and the delete request can be sent to external storage before the BC record is removed.
· Option C – The Find() guard should be removed: If staying on OnAfterDeleteEvent is intentional, then the Find() guard in DeleteFromExternalStorage() is unnecessary — the Rec parameter already carries all required field values (External File Path, Stored Externally, etc.) in memory, and the Find() serves no purpose in this context.
Environment
· BC Version: 28.0
· Extension: External Storage - Document Attachments v28.0.0.0 (5f2e93a0-6083-4718-b05a-7ac89be5644d)
· External Storage Connector: Azure Blob Storage (c9ce86fe-cb70-4b79-be03-d21856b1a4ca)
· Deployment: SaaS (Online)
I will provide a fix for a bug