Skip to main content

Global Modify

Use the Global Modify trigger to start a flow whenever a record changes in Business Central. Like Global Insert, it listens at the database level, so updates from the UI, an API call, or a background job all wake up the flow. Optionally pick a set of watch fields so the flow fires only when one of those specific fields changes — the rest of the record can move freely without spinning up the flow.

Typical examples include:

  • Reacting when a customer's Blocked status flips.
  • Sending a notification when a sales order's Status reaches Released.
  • Synchronising specific item fields with an external system without re-syncing on every harmless edit.

What happens when the flow runs​

  1. Business Central modifies a record in the table you selected.
  2. AutoFlow checks the trigger configuration and applies any field filters you defined.
  3. If watch fields are configured, AutoFlow compares the modified record against a snapshot taken at publish time (and refreshed after every modify). The flow fires only when at least one watch field's value differs.
  4. If watch fields are not configured, the flow fires on every modify that passes the field filters.
  5. The trigger emits two outputs:
    • Rec — the record ID of the modified row, ready to feed into follow-up record steps.
    • ChangedFields — a JSON array [{"fieldNo", "fieldName", "oldValue", "newValue"}, …] of every watch field that changed (empty array when no watch fields are configured).

Configure the trigger​

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

Description​

  • Purpose: Help your team understand when the flow executes.
  • When to fill it: Always. The description shows up in trigger lists and execution history.
  • Tips: Mention the table and the fields you are watching, e.g. Customer Blocked status changes.

Table No.​

  • Purpose: Tell AutoFlow which Business Central table to monitor.
  • When to fill it: Required.
  • Tips: Stick to specific business tables. Avoid temporary or buffer tables that change during posting routines — they will fire many irrelevant modifications.

Field Filters​

  • Purpose: Limit executions to rows that match certain criteria before the watch-field diff is evaluated.
  • When to fill it: Optional. Strongly recommended when only a subset of records is interesting.
  • How it works: Filters are applied first. Records that fail the filter are ignored, regardless of their watch fields.

Watch Fields​

  • Purpose: Restrict the trigger to actually-changed fields you care about.
  • When to fill it: Optional. Pick one or more fields whose changes should fire the flow. Leave empty to fire on every modify that matches the filters.
  • System fields are blocked: SystemId, SystemModifiedAt, and the rest of the system metadata range cannot be selected — they always change on every modify and would defeat the purpose.
  • Tips: Pick the smallest possible set of fields. Each additional watch field adds rows to the snapshot cache that gets backfilled at publish time.

Best practices​

  • Keep watch fields tight. A single watch field on a busy table is much cheaper than the entire record being snapshotted.
  • Combine filters with watch fields. Filter to the subset of records (e.g. Document Type=Order) and watch only the fields whose change matters.
  • Beware of bulk operations. A ModifyAll rewrites every row one by one through the OnDatabaseModify subscriber, so the trigger fires once per row.
  • Backfill blocks publish. When you publish a new flow version with watch fields, AutoFlow walks the entire table once to seed the snapshot. On very large tables that can take a moment.