Build Secure Instance Deletion Automations

This configuration illustrates how large-scale deletions can be performed through automation in a more controlled and secure way.

It introduces a pattern that reduces the risk of accidental mass deletion caused by misconfigured filters, while maintaining full configurability.

The approach relies on isolating deletion logic into a single, reusable field and adding validation layers before execution.

Review the configuration goals

The objective of this configuration is to:

• Centralize deletion logic in a single configurable field

• Provide visibility on impacted instances before deletion

• Reduce risks linked to complex or incorrect filters

• Introduce safety thresholds to prevent unintended mass deletion

• Enable monitoring and alerting when deletion conditions are not met

All elements described below are fully configurable and can be adapted depending on the use case and data sensitivity.

Separate selection, validation, and execution

Instead of directly applying filters inside an automation, this approach separates:

1. Selection of instances to delete

2. Validation of the volume of deletion

3. Execution of the deletion

This ensures better control and visibility.

Configuration

Define the deletion scope (calculated association field)

A calculated n-n association field is created to define the scope of deletion.

This field:

• Uses as input Concept with instances to delete > All instances with filters

• Returns all instances that are intended to be deleted

• Acts as the single source of truth for deletion logic

Also see Re-use filters on instances.

Count the instances to delete (control field)

A second field is created to count the number of instances identified for deletion.

This field:

• Is a simple count of the previously defined association field

• Provides a measurable indicator of deletion volume

This enables validation before triggering any destructive action.

Review the deletion dashboard

A dashboard can be configured to provide visibility on:

• The list of instances targeted for deletion (the n-n computed field must be used to retrieve instances)

• The total number of instances (via the count field)

This dashboard serves as a validation layer, allowing users to:

• Review the data before deletion

• Ensure the scope is consistent with expectations

Configure the automation

Iterate over the deletion scope

Instead of redefining filters in the automation:

• Use the calculated association field directly. Remember that n-n computed fields are not typed. The path must therefore be: Global > Use cases to delete > Use case > All instances.

• Iterate through it using a For each

Set a safety threshold

A condition is added to the automation:

• Deletion is executed only if the count is below a defined threshold

Example:

• Expected deletion volume: ~50 instances

• Threshold: 60

If the count exceeds the threshold:

• The automation does not execute

This prevents unintended large-scale deletions caused by faulty filters.

Configure alerts (optional but recommended)

Trigger condition

If the count exceeds the defined threshold

Action

Send an email notification to relevant users

Email content

The email can include:

• Explanation that deletion was blocked

• The number of impacted instances

• A direct link to the dashboard displaying the targeted instances

This ensures that:

• Users are aware of the issue

• They can review and correct the filter if needed

Review the benefits

• Single source of truth for deletion logic

• Improved safety through threshold validation

• Better visibility via dashboards

• Reduced risk of misconfigured filters

Review the limitations

Read more

• Use Formulas for Practical Examples