Skip to main content

Global Delete

Use the Global Delete trigger to start a flow whenever a record is deleted from a Business Central table. Unlike the Modify and Insert triggers, the deleted record is gone by the time the flow runs, so the trigger lets the author choose specific fields to capture as outputs before the row disappears.

Typical examples include:

  • Archiving a deleted customer to an external system before the row is purged.
  • Recording an audit entry whenever a sales order is removed.
  • Cascading a clean-up to a downstream service when a master-data record is deleted.

What happens when the flow runs

  1. Business Central deletes a record from the table you selected.
  2. AutoFlow checks the trigger configuration and applies any field filters you defined.
  3. If the filters pass, AutoFlow reads the values of the configured output fields from the row that's about to be removed.
  4. AutoFlow starts the flow and emits one Value-Output per output field (keyed by the field's name). No reference output is provided — the row no longer exists post-commit, and a stale RecordId would resolve to nothing.

Configure the trigger

Open the flow editor, pick When a record is deleted, and complete the configuration card.

Description

  • Purpose: Help your team understand when the flow executes.
  • When to fill it: Always.
  • Tips: Mention the table and the reason for capturing the deletion, e.g. Sales Order deleted — archive to Data Lake.

Table No.

  • Purpose: Tell AutoFlow which Business Central table to monitor.
  • When to fill it: Required.
  • Tips: Stick to specific business tables. Avoid posting buffers and other tables that delete rows as part of normal posting routines.

Field Filters

  • Purpose: Limit executions to rows that match certain criteria.
  • When to fill it: Optional.
  • How it works: Filters are applied to the row before deletion completes. Rows that don't match are ignored.

Output Fields

  • Purpose: Carry data from the deleted record forward into the flow.
  • When to fill it: Optional. Pick the fields you want exposed as Value-Outputs — typically the primary key and any fields needed by downstream steps.
  • How it works: Each picked field becomes a Value-Output named after the field, with a string representation of the field's value. Decimals and dates use a locale-invariant format, so flows behave the same on every tenant.
  • Tips: Capture the primary key and any human-readable identifier (e.g. customer No. and Name). You can always add more fields later if downstream steps need them.

Best practices

  • Always capture the primary key. Without it, downstream steps have no anchor for the deleted row.
  • Keep outputs minimal. Capturing every field works but bloats the execution log. Pick the columns the flow actually consumes.
  • Beware of cascading deletes. A DeleteAll walks the table row by row through the OnDatabaseDelete subscriber, so the trigger fires once per deleted row — and that can be a lot of executions for a single user action.