We have reached the final episode of our series. We have built the Staging tables, the UI, and the API.

Now, it is time to connect the final piece: The Processing Logic.

But more importantly, it is time to look at the “Truth” of this experiment. Does an “Agentic” workflow actually work for enterprise-grade Business Central development? Or is it just a fun toy?

1. Implementing the Logic (Phase 4 & 5)

I tasked the Orchestrator with Phase 4: creating the Process Staging codeunit. This is the brain of the operation, responsible for taking the raw data from our staging tables and converting it into a real Sales Order.

The agent successfully:

• Created the Codeunit.
• Generated a Unit Test (which we skipped for now, but it’s nice to have!).
• Implemented the logic to find the customer based on email, create the Sales Header, and loop through lines to create Sales Lines.

However, when I tried to compile, we hit a few snags. The agent missed some using statements and had a naming conflict with the codeunit.

This confirms a recurring theme: AI is great at the “heavy lifting” (writing 100 lines of logic), but you still need a human pilot to fix the syntax errors.

2. The “Bound Action” Problem

This was the most technical hurdle of the episode. We needed a way to trigger this processing logic directly from the API.

The agent tried to add a standard Action to the API page. As we discussed in the last episode, API pages do not support standard actions.

Instead of fighting with the agent to fix it, I switched to manual mode. I wrote a [ServiceEnabled] procedure directly on the API page to create a Bound Action.

Kodestykke

[ServiceEnabled]
procedure Process()
var
    WebShopProcessing: Codeunit "Web Shop Processing";
begin
    WebShopProcessing.Process(Rec);
end;

This allows us to call POST .../webOrders(ID)/Microsoft.NAV.Process from an external system to trigger the business logic immediately after uploading the order.

3. Testing the End-to-End Flow

With the Bound Action in place, I opened Postman (well, the VS Code extension equivalent) and fired a test payload.

1. POST to API: Created a new Web Order. (Status: 201 Created)
2. Verify in BC: The order appeared in our Staging Table.
3. Trigger Process: I clicked the “Process” action in the UI.
4. Result: A real Sales Order was created in Business Central!

It works. We went from zero code to a fully functional, multi-agent constructed integration.

The Verdict: Is AI Ready for Real Work?

After five episodes of “unfiltered” coding, here is my honest conclusion.

AI is an Accelerator, Not a Replacement.

• The Good: I could “multitask” like never before. I could have the AI write the boilerplate for an Azure Function while I sat in a Teams meeting. It handles the boring, repetitive tasks (creating tables, pages, simple logic) incredibly fast.
• The Bad: You cannot “one-shot” an enterprise solution. You still need to understand AL code to fix the compilation errors, architectural mistakes (like the API actions), and missing cleanup triggers (like OnDelete).

If you treat AI as a junior developer who writes fast but needs supervision, it will change your life. If you expect it to do everything perfectly while you sleep, you will be disappointed.

Thank you for following along on this journey!