External business events and Power Automate: letting the rest of Microsoft 365 react to Business Central

Integration events (the events post) are for AL code inside the tenant. External business events are the same idea pointed outward: a named event your extension raises, that Power Automate (and anything else that speaks the Business Central connector) can trigger on, with a payload, without polling an API every minute.

Declaring one

codeunit 50140 "CON Shipment Events"
{
    [ExternalBusinessEvent('ShipmentReleased', 'Courier shipment released', 'A courier shipment has been released for collection.', EventCategory::"CON Courier")]
    procedure ShipmentReleased(ShipmentNo: Code[20]; Carrier: Text; ShipmentSystemId: Guid)
    begin
    end;
}

The attribute names the event, gives it a display name and description (which appear in Power Automate's trigger picker), and a category (an enum extension of EventCategory). The procedure body is empty; calling the procedure is raising the event. The parameters are the payload: keep them to identifiers and a few scalars. The subscriber fetches the rest through the API using the SystemId.

Raise it from your Mgt. codeunit at the business moment: after the shipment is released and committed (an external event raised inside a transaction that then rolls back is still delivered, so raise after the commit point or from OnAfter positions that imply success).

On the other side

In Power Automate: trigger "When a business event occurs" (Business Central connector), pick the environment, company, category and event; the parameters arrive as dynamic content. Then do whatever the business wants: post to a Teams channel, create a Planner task, write a row to Dataverse, call the courier's own Power Platform connector, email the customer. Logic Apps and Dataverse's Business Central virtual tables can subscribe the same way.

When to use which

Patterns that keep it safe

• Payload is identifiers, not data. The flow reads the record through the API with its own permissions. This keeps personal data out of the event log and means the flow sees current data, not a stale copy.
• Idempotent consumers. Events can be delivered more than once. The flow checks before it acts (has a task already been created for this shipment?).
• Do not write back blindly. A flow that updates Business Central in response to an event that was caused by a flow updating Business Central is a loop. Use a field or a tag to mark flow-originated changes.
• Version the event. Changing parameters breaks every flow. Add ShipmentReleasedV2 and keep the old one for a release.
• Per environment. Flows are bound to an environment; a sandbox copy does not re-point them, but a flow pointing at production triggered by sandbox testing is a real risk if someone edited the connection. Document which flows exist and which environment each watches.

External events are also what Copilot agents and the Dataverse integration increasingly build on, so an extension that raises them at its business moments is ready for whatever the business connects next.

Related posts