_{BC AL Journey #15}

Welcome back! In BC AL Journey #14 we created our first Power Automate using one of the stock Business Events and a provided wizard. In this step of our journey, we are going to revisit some of the work we did in BC AL Journey #11 and create a custom Business Event and a new Power Automate flow.

We are going to leverage the Customer Claims record we created back in BC AL Journey #13 and add a Business Event when the resolved flag is set.

Use Case

User would like to generate an email to the client when the resolved flag is set on a Customer Claim.

Implementation

• Add a Business Event to Business Central that fires when the Resolved flag of a Customer Claim is set to True.
• Create a Power Automate flow that send an email to the customer when a claim is set to resolved.

Test Plan

• Set a customer claim to resolved, observe if an email is set.

There are a few components to a Business Event; we need an Event Category, so it appears properly in Power Automate, a Trigger to watch for the data event, and the Business Event itself.

We will start with the Event Category, which we implement by Extending the Event Category Enumerator. I added a file called ARDEventCategories.EnumExt.al to the 11 – Enum Ext folder.

namespace AardvarkLabs;
using System.Integration;

enumextension 50000 ARD_EventCategories extends EventCategory
{
    
    value(50000; "Ardvark Labs Events")
    {
        Caption = 'Ardvark Labs Events';
    }
}

You can add as many Event Categories as you need to break up the events you are creating. In this case one is plenty.

Next, we create a new Code Unit in the 8 – Codeunit folder. I named mine ARDClaimResolvedEvent.Codeunit.al.

namespace AardvarkLabs;
using System.Integration;

codeunit 50002 ARD_ClaimResolvedEvent
{
    var
        EventCategory: Enum EventCategory;

    [EventSubscriber(ObjectType::Table, Database::ARDWarrantyClaim, 'OnAfterValidateEvent', 'Resolved', false, false)]
    local Procedure OnAfterValidateResolvedComplete(var Rec: Record ARDWarrantyClaim)
    var
        Customer: Record Customer;
    begin
        if Customer.Get(Rec."CustomerNo.") then
            ClaimResolvedBusinessEvent(Rec.SystemId, Customer.SystemId, Rec.Resolved);
    end;

    [ExternalBusinessEvent('ClaimResolved', 'Claim Resolved', 'This Business Event is triggered when a Claims resolution state has changed.', EventCategory::"Ardvark Labs Events")]
    local procedure ClaimResolvedBusinessEvent(ClaimID: Guid; CustomerNo: Code[20]; Complete: Boolean)
    begin
    end;
}

Here is a direct link to the file in GitHub.

The first code section is an Event Subscriber to the OnAfterValidateEvent of the ARDWarrantyClaim table. We could have used the OnValidate event of the Resolved field right on the table, but for Business Events it is best practice to have both the triggering and firing events in the same code unit. This allows you to keep the code together for maintenance and management.

We retrieve the Customer record and get the System Id. In Power Automate the Business Central connectors Get Record functionality uses the System Id of records, not the Code field we use on a Customer inside BC AL Code.

The second block of code is the actual Business Event. You define a name, display name, description, and our Event Category. Any values included in the procedure are passed to the receiver of the event. In this case we are going to pass it the Guid of the Claim, the Customer Guid and the resolved status.

There is an important detail to note here; we are using the System Id Guid for the customer record identifier and not the key field of “No.”. Microsoft has added the System Id field to nearly all the records in Business Central and this is the value used by the connectors in the Power Platform to access records. This allows the Power Platform to retrieve a single record regardless of how may keys Business Central uses.

That is it, publish this to a SaaS Business Central and let’s move over to Power Automate. Log into make.powerautomate.com and click the Create button on the left hand side of the screen.

Click on Automated cloud flow.

The next screen asks us for a name and what the trigger will be. Find the trigger for “When a business event occurs”. At the time I’m writing this, it is V3.

Click Create.

You will be presented with a single logic block.

Clicking on that block will allow you to select your environment and your event. Note the Event Name and the Event Category we created.

After selecting the event, we need to add an action by clicking on the plus under the trigger block.

Let’s add a Test Condition for when the resolved state is true. From our code, we passed a value called “Complete”. In the Add An Action menu click Control.

Then select Condition

The Condition parameters will display next, we can click on the lightning bolt to set the condition value.

Click the See More button to see all the available conditions.

Then click on Complete

Fill in the last field with true.

This create a True and a False path, we are going to click the + in the true path the add an action. We need to retrieve the associated Customer to know where we send the email. Find the Dynamics 365 Business Central section and click “Get Record”

Clicking Get Record will insert the block and bring up the properties. Filling the Environment, Company, then select Customers for the Table Name and using the Lightning Bolt select CustomerNo for the Row Id value, which is the Guid we specified in the Business Event.

We now add the Send Email by clicking on the + under our latest module and finding the Send Email action.

We can now fillout the details of the email. Clicking the down arrow on the “To” field will allow you to select Enter custom value.

You can then click the lightning bolt icon and lookup “email”

That is the email address from the Get Record block, which we used to retrieve the customer.

Fill out the rest as you see fit.

The finished flow should look like this:

Click Save and we are done!

To test our flow, go into Business Central, open a Customer change the email address to your email address, enter a Warranty Claim and then set it to Resolved. A few moments later you should receive an email.

You should also see it in the run history on the Flows page:

You have now created a custom business event to trigger a Power Automate flow based on changes to the system data. This can be a very efficient way to drive process automation. This also allows you to hand off events to additional team members in the Power Platform space.

Microsoft calls it Fusion Development when Business Central AL developer and a Power Automate developer work together to solve a problem. It is a really great way to spread a workload across a team.

Power Automate isn’t the only application that can consume a Business Event. Business Events are very similar to Web Hooks and can be subscribed to by any application. Here are some additional details from Microsoft. Business events on Business Central (preview) – Business Central | Microsoft Learn

I hope you had a great time with this one.