A unique challenge encountered when extending a Business Central cloud deployment is that of extensibility. Source code in cloud deployments cannot be directly modified.
As a consequence, changing built-in workflows in Business Central can seem impossible at first glance.
Thankfully, Microsoft offers a special mechanism for adding new behaviors and sometimes replacing existing behaviors entirely: Events.
Events and Event Subscribers
The use of Events and Event Subscribers is a common pattern in software development. This technique enables developers to extend the functionality of existing workflows by adding Event Subscribers to the application.
Event Subscribers are executed whenever an Event is triggered in the main body of code. This enables developers to extend existing workflow functionality while being unable to modify the code that runs the workflows defined by the default version of Business Central.
Subscribing to Events
Creating an Event Subscriber involves creating a new Codeunit. It subscribes to an event with special markup on top of the procedure that is to be subscribed to an event. The following is an example of such a Codeunit.
| codeunit 50100 EventSubscriber { [EventSubscriber(ObjectType::Codeunit, 123, 'AfterWorkflowExecutes', '', false, false)] procedure TriggerExternalService() begin // Some code that calls out to update a third-party service. end; } |
Let's break down what this code does line-by-line.
| codeunit 50100 EventSubscriber { // Implementation } |
This line defines a new Codeunit with the ID 50100. This Codeunit will hold the procedures that subscribe to the event we're targeting.
|
[EventSubscriber(ObjectType::Codeunit, 123, 'AfterWorkflowExecutes', '', false, false)] |
This line marks our procedure as an Event Subscriber. The arguments passed into EventSubscriber are as follows:
- Argument 1 indicates the type of the Event Publisher. In this case, our argument indicates that the publisher is a Codeunit.
- Argument 2 indicates the identity of the Event Publisher. This value can either be an ID as shown above or the name of the object.
- Argument 3 is the Event that is being subscribed to. In this case, the sample code subscribes to AfterWorkflowExecutes, which is published from Codeunit 123.
- Argument 4 defines the table field that the triggering event listens to. This argument can be blank unless the publisher is a Table publishing a field validation event.
- Argument 5 is optional and defaults to false. When set to true, it prevents errors from triggering when a licensing issue with the subscriber occurs.
- Argument 6 is optional and defaults to false. When set to true, it prevents errors from triggering when a permissioning issue with the subscriber occurs.
| procedure TriggerExternalService() begin // Some code that calls out to update a third-party service. end; |
This line defines the Event Subscriber. This code is what is run whenever the targeted Event is published.
Of note, the argument list of this procedure must match the argument list of the event being subscribed to.
For instance, if AfterWorkflowExecutes accepts a SalesInvoice as an argument, TriggerExternalService would need to take a SalesInvoice as an argument as well.
Business Events vs. Integration Events
Not all events are created equal:
| Type | Use When... | Risk Level | TL;DR |
| Business Events |
You want to extend logic safely & reliably |
Low |
Public, stable API. Microsoft promises not to change them. |
| Integration Events |
You need tighter, internal logic access |
Higher |
More powerful, but also more likely to break with updates. |
Business Events and Integration Events are two common types of events, both of which allow for workflow modification. There's a critical difference between the two events:
Business Events are treated as the preferred method of modifying workflows.
- They are treated as a stable, public API. That means that Microsoft makes an informal promise not to change them.
- They are also designed to be decoupled from the implementation of Business Central. That means Business Events are generally safe to rely on. The inner workings of Business Central can change, but since those internals aren't exposed and Microsoft is committed to not changing Business Events, your Event Subscriber is unlikely to break.
Integration Events, on the other hand, are highly coupled with Business Central internals.
- These events are primarily implemented to allow third-party services, like Shopify, to integrate tightly with Business Central. As a consequence of these design decisions, subscriptions to these events can be much riskier and prone to error.
- Be careful when subscribing to Integration Events, and be sure to properly understand the risks before doing so.
Overriding Workflows Entirely
We’ve talked about adding behavior with Event Subscribers—but in some cases, you can actually override it.
Certain Integration Events include an IsHandled argument. Set it to true, and Business Central will skip its default workflow.
This works because Business Central supports pass-by-reference (marked with var), meaning a change to a variable in one place updates it everywhere. Here's how that looks in code:
| [EventSubscriber(ObjectType::Codeunit, 123, 'AfterIntegrationEvent', '', false, false)] local procedure ModifyInternalProcess(var IsHandled: Boolean) begin IsHandled := true; end; |
By convention, this tells the following workflow code written by Microsoft to not execute as usual. This allows extensions to entirely override typical workflow processes.
Easing Extensions with Business Central
Even though you can’t touch the base code in cloud deployments, Events and Event Subscribers make it totally possible to build around existing workflows—or override them entirely (with caution).
And hey, if all this sounds like a bit much? That’s where we come in.
If you need help integrating Business Central with your other cloud solutions, give us a call.
.jpeg)