Skip to main content

Record Created or Modified

Use the Record Created or Modified trigger to run a flow interactively – in your own session, while a record is being saved – whenever a record in one of the supported tables is created, modified, or both (you choose). Because it runs synchronously, the flow can do two things a background flow cannot:

  • Prevent the change. End the flow with an Error step and the save is cancelled with your message.
  • Change the record. End the flow with a Set field values step and your values are written onto the record before it is stored.

Any other AutoFlow step can be used in between (look something up, call a service, insert a related record, and so on).

Supported tables (pick exactly one):

  • Master data: Customer, Vendor, Contact, Item
  • Sales and purchase documents: Sales Header, Sales Line, Purchase Header, Purchase Line
  • Projects: Project (Job), Project Task, Project Budget Line (Job Planning Line)
  • Subscription contracts: Customer Subscription Contract, Customer Subscription Contract Line — available when the Microsoft Subscription Billing app is installed

Typical examples:

  • Block saving a sales line whose discount exceeds a limit, with a clear message.
  • Default a dimension or a responsible person onto a purchase header when the buyer changes.
  • Stamp a follow-up date whenever a project's status field is edited.
  • Enforce a naming rule on a customer, or block clearing a mandatory field on an item.
  • Default values onto a new record the moment it is created — for example a responsible person or a dimension on every new customer.

What happens when the flow runs​

  1. A user creates or changes a record in the table you selected, and Business Central is about to save it. The flow only runs for the events you switched on (see When the flow runs below).
  2. AutoFlow applies your field filters. If the record does not match, nothing happens.
  3. On a modify, if you configured watch fields, the flow fires only when at least one of them actually changed (comparing the value before and after). With no watch fields it fires on every save that matches the filters. On an insert there is nothing to compare against, so watch fields do not limit it — the flow fires on every new record that matches the filters.
  4. The flow runs to the end, synchronously:
    • If it ends with an Error step (or any step raises an error), the save is cancelled and the user sees the message.
    • If it ends with a Set field values step, those values are written onto the record and the save continues.
    • If it just ends, the save continues unchanged.

Trigger outputs​

  • Rec — a reference to the record being saved, ready to feed into follow-up steps.
  • For every watch field, two values:
    • xRec_<Name> — the value before the change. On an insert there is no previous value, so this is blank.
    • Rec_<Name> — the value after the change (on an insert, the new value).

<Name> is the name you give each watch field (see below).

Configure the trigger​

Open the flow editor, pick When a record is created or modified (interactive), and complete the card.

Table​

Choose the table to watch. Changing the table clears the field filters and watch fields, because they belong to a specific table.

The table picker lists every table in the system, but the trigger only works on the tables above. Pick another one and the status line at the bottom of the dialog says so straight away – "Table 17 (G/L Entry) is not supported by this trigger, so the flow would never run" – and the flow cannot be published until you change it.

Next to that message sits Ask us to add this table. It sends the table and the trigger to the AutoFlow team, along with your organization so we can come back to you. The button only appears while the chosen table is unsupported. Your partner can also add tables themselves with a small companion extension; ask us for the details.

When the flow runs​

Two switches decide which events start the flow:

  • Run when a record is modified — run while an existing record is being changed. This is on by default (and it is what flows built before this option existed always did).
  • Run when a record is inserted — run while a new record is being created.

Turn on either or both. On an insert there is no previous value, so the xRec_<Name> outputs are blank and watch fields do not limit when the flow runs — only the field filters apply.

Interactive sessions only​

Leave this on (the default) so the flow runs only when a person is working in the client. Saves made by posting routines, job queue tasks, or web-service calls are left untouched — this keeps a validation error from breaking a background routine. Turn it off only if you really want the flow to run for every save.

Timeout (seconds)​

The flow runs while the record is being saved, so keep this short. A slow flow makes the user wait for their save.

Field Filters​

Optional. Limit the flow to records that match certain criteria (for example Document Type = Order). Records that do not match are ignored.

Watch Fields​

Optional. Pick the fields whose change should run the flow, and give each one a Name. The name is suggested automatically from the field caption (for example Posting Date becomes PostingDate); keep it short and stable, because it is used to build the xRec_<Name> and Rec_<Name> outputs. With no watch fields the flow fires on every save that matches the filters.

Change the record: Set field values​

To adjust the record, end the flow with the Set field values step (it is only available in a Record Modified flow). Add a row per field you want to set, type a value (SmartField references are supported), and choose how to apply it:

  • Validate — as if a user typed it on the page, so dependent fields recalculate and standard validation runs.
  • Assign — write the value directly, without validation.

The step's Skip standard processing option has no effect here – the record is always saved normally.

Show a message on the page​

Because the flow runs in your own session, a Send Notification step surfaces a message to the user as a page notification without stopping the save — for example, to confirm what the flow changed.

Prevent the change​

To stop the save, end the flow with an Error step and supply the message the user should see. The whole save is rolled back together with anything the flow changed.

Best practices​

  • Keep watch fields tight and the timeout short. The user is waiting for the save.
  • Prefer Validate when a value should behave like a manual entry; use Assign for raw values only.
  • Combine filters with watch fields so the flow runs only for the records and changes that matter.