Best Practices for Auditing Deletions During Cascading Deletes in Mendix

0
Hi all, When using cascading deletes in Mendix (either via association delete behavior or Before Delete microflows), what are the best practices for logging or auditing the deleted objects? Specifically, I want to: Track which objects were deleted as a result of a parent deletion (e.g., Event → Registration → Feedback) Log key information (e.g., object ID, user, timestamp, reason if any) Ensure logs are reliable even when deletes are automated or deeply nested Should I implement custom audit logging in each 'Before Delete' microflow, or is there a more scalable approach for tracing cascading deletions?
asked
3 answers
0

Hi Vomeshwari, to audit deletions in Mendix especially those caused by cascading via association delete behavior follow these best practices:

  1. Use Before Delete microflows on all entities involved in the cascade (e.g. Registrations, Feedback) to capture deletion events.
  2. Log details (object type, GUID, user, timestamp) into a custom Auditlog entity or use a marketplace module like Audit Trail.
  3. Avoid relying solely on association delete behavior if audit tracking is required—automated deletes do not trigger central logging unless Before Delete microflows are used.
  4. Create a reusable sub-microflow (e.g., Log deletion) that can be called from multiple Before Delete flows to avoid code duplication.
  5. If performance is a concern, log only critical deletions, not static or reference data.

I hope this helps you! :)

answered
4

Hello Vomeshwari,

You can create sub microflow before delete as given below refrence on each entity and you can create a custom audit entity to store logging information.

 

image.png

there is some Audit trail marketplace module also which are useful on some scenario.

image.png

answered
2

When using the default delete behavior, a before delete event is the most appropiate way to handle this.

 

However, a more common best practice is to NOT use the default delete behavior, but handle deletes through microflows in ALL cases. Which can be best done by creating a submicroflow, which will handle the delete of the main record and the referenced records. This submicroflow should be the one and only microflow used for deletion.

 

Your case of creating an audit trail, can be handled in a separated sub microflow, executed before the delete submicroflow

answered