AI-enabled D365 F&O integrations using the new Logic Apps agent loops

This article is the first in a series of blog posts I plan to publish, aimed at bringing clarity to one of today’s most hyped technology topic: artificial intelligence (AI). As with most of my other posts, there will be a practical example to illustrate the concepts, and I’ll explain everything at a beginner-friendly level (and without using any AI-generated text!)

A few months ago, the Logic Apps team introduced new (preview) AI capabilities in their Standard plan workflows. Among these updates is an AI-powered agent loop mode that uses an AI agent and a set of sub-workflows as tools operating in a “Think → Act → Reflect” pattern. In this post, I’ll briefly explain when and how to use AI agent loops in your solutions, demonstrate an AI-enabled F&O integration example, and discuss the advantages of Logic Apps agent loops compared to Microsoft’s other low-code AI platform, Copilot Studio

When to use AI agent flows and when not

In the majority of the AI podcasts I have seen so far, AI agent flows are mentioned as a replacement for today’s solutions with rigid, deterministic program logic. What I mean is this: below you have a logic app flow with a rigid program logic using switch and conditional statements:

It receives an inventory movement record and places it into the correct storage place using a rigid program logic. Many AI instructors I have listened to, some being representatives of big tech companies, declare this way of programming ‘old school’ now. They tell that the ‘future’ of programming should be using AI agents and LLM prompts instead. They tell it is the new trend of building such solutions, and it will remove the ‘burden’ of designing the program logic with rigid, deterministic flows and conditions, such as if-then-else and switch statements:

Well, the computing power needed by a solution using an AI agent is much higher than that of solutions using deterministic program logic. Yet there is a huge performance penalty and extra costs, which are currently not being 100% reflected to end users by big tech companies. The deterministic flow logic app example here, with the most basic plan, executes in approximately 0.1 to 0.5 seconds. The example with the AI agent loop and the most basic plan executes like this:

So, do you think any company investing so much in the performance optimizations of their solutions will switch to using AI agents instead of deterministic workflow solutions, just because it is ‘the new trend’? I don’t think so. Therefore, solutions using deterministic program logic are not going anywhere or being replaced by AI. We continue to solve problems that can be solved using rigid logical-conditional statements by using rigid logical-conditional statements.

On the other hand, modern AI tools can now tackle many technical design challenges that were previously impossible to solve with rigid programming methods or required external tools and services. They introduce new programming patterns and new dimensions to solution architecture—such as self-learning, self-adapting, and self-optimizing intelligent modules, linguistic decision models, and autonomous or human-in-the-loop result generation. Below are a few examples that, in my view, can only be solved effectively using AI tools rather than deterministic program logic:

• Logical flows that can be understood and solved by a human, but cannot be put into a deterministic program logic by using traditional programming language tools (for ex., if-then-else, switch statements)
• Processing unclear, semi-structured inputs from users, such as linguistic questions instead of the selection of pre-determined data, random documents, and e-mail messages
• Dynamically changing parameters, like parsing data from a service provider that uses a dynamically changing data schema
• Solutions that require recognition and understanding of a fairly large document base to operate
• Solutions that require far too much conditional routing or too much nested logic. Like the ones you cannot read all day, how many if-then-else statements are nested within each other
• Solution that requires human conversations

Example use case: F&O integrated employee inquiry portal

The requirement is as follows: A customer wants to extend their HR portal, integrating it with D365 F&O. The first step is creating a new portal page that lets employees make inquiries about other employees in the company within privacy limits. This page needs to be integrated with the F&O HR module and must function with the following requirements:

• Users log in to the portal page with their full names.
• Users should be able to access any information about the other employees unless the information is too private. If a private inquiry is made, users should be presented with a clear error message instead of the information requested.
• The information requested should be presented in clean and readable language to the user
• Users do not have any technical knowledge about the fields and field names of the employee table of F&O. So, they may ask for the information they want to query in plain language, or give a list of field names that may not be the exact F&O field names. Customers do not want any field selection or combo boxes either.
• All inquiries should be logged to an Azure table with details and date-time.
• Inquiries about the company’s managers are forbidden. Employees are well informed about it, and if they try to make an inquiry about any manager, they should receive an error message, and the manager should also be informed via an email containing details of who is doing the inquiry and what they want to know about him.
• The customer has (like always) a very low budget for this requirement. They want it to be done in a maximum of one day, preferably in half a day.

The details of the requirement tell us that the solution deserves to be an AI agent flow, so let’s get started. Create a standard logic app and add a workflow, choosing the new agent loop mode. It will create an agent loop template with a trigger, an agent action, a container set of tools for that agent, and a response from the agent. From here, I will not go into all the details of the workflow creation, but only explain the important points. You can download the workflow (without secrets and connections) from my GitHub link here. The request trigger of the workflow should look like this, with 3 fields: employee asking, employee of inquiry, and information needed:

Then you set up the tools, which are like sub-workflows that you need to pass parameters from the agent. They need to set up with good descriptive names and clear descriptions so that the agent can correctly understand and use them as needed, also on the tool parameters:

Here, we need to do the F&O integration using the OData connector and OData filtering to choose the correct employee from their full name. Just add a parameter for the OData filtering, as shown above, and the agent will learn about it and provide an OData filter string itself. You do not need to set up anything extra for the filtering. Cool, isn’t it?

Then you need to set up the agent. At first, you need to provide a model and an Azure OpenAI service or AI foundation connection to it. Here, I use the OpenAI service and GPT4.1 mini as a model. Then you need to provide a detailed prompt that delivers the requirements to the agent, and that is the trickiest part. You need to clearly describe all the parameters, tools, and required functionality to the agent, or it may not work as expected. MS has a guide here for writing effective prompts; however, it may require multiple trial-and-error attempts until it works as expected (just like coding and debugging). Here is my agent setup and prompt:

You are an agent that returns the users requested employee information from a portal using available tools for you to communicate with microsoft d365 finance and operations.

-Tool "Get employees" returns a list of employee information which you can pass a odata filter to field "NameAlias" to query a specific employee name.
-Tool Log requests log the request JSON to an Azure table
-Tool send email to employee sends an email message to the given employee email address

-Name of the asking employee is "@{triggerBody()?['askingEmployee']}"
-Name of the employee to inquiry is "@{triggerBody()?['inquiryEmployee']}" 
-Information requested about the inquiry employee is "@{triggerBody()?['informationToInquiry']}" 

-Check if the asking employee exists using the get employees tool and return an error message if it does notexists. Return no employee information if asking employee does not exists. Do not inform if asking employee do exists in the system.

-Asking too private questions are forbidden, too private questions are questions about home address, family, gender, health, age and religion. If a too private question is asked, warn the user kindly the question too private is and do not return any information. 

-Get the requested employee information for the inquiry employee using the get employee information tool. Requested information can be a question about the employee information or a list of information or fields from the employee information, extract that from the employee information. Pick the first record if tool return more than one records. Asking questions about managers are also forbidden, so check if the employee information states employee is a manager by controlling if "TitleId" field contains word "Manager" in it and if it does, return to user a warning instead of the requested information and send to this manager employee's email address a nice formatted warning email giving details about the inquiry question and asking employee name using the send email tool.

-If no forbidden information is asked, create a response message by formatting the user requested employee information in a good readable rich text
-Always log the user request to Azure table using the log request tool

Finally, return the result from the agent using a response action :

That’s all, and it takes a maximum of half a day to create such a workflow, including testing and trial-and-error attempts until setting the prompt right. Now let’s check how it works.

Testing

First, test the optimistic flow, send the following request to the workflow, and see the result:

İt works well, and I see that a log record has also been created in the logging table:

Now let’s ask some private things and check if the agent protects employees’ privacy well. Send the following request and see the result:

That also works perfectly. Be aware that if you do not get the expected result, you can debug the logic app runs as the non-agent workflows, and see the decisions of the agent and which tools it has used, and how many times :

Now, let’s debug the most complicated point, the manager’s privacy requirement. Send an inquiry about a manager and see the result:

And did it send an email to the manager reporting the inquiry? Yes, it did:

So, all work perfectly and is created promptly in such a short time as half a day.

Copilot or Logic apps agent flows

Now is the difficult question. MS has also Copilot and Copilot studio, which you can create such a solution inside the Copilot chat window instead of the backend service with F&O integration. Which one is better and more cost-effective? First of all, these two solutions serve different purposes and technical needs. Logic apps are an enterprise low-code solution with 1400+ connectors and much more technical flexibility, and CoPilot is a user-friendly, low-code, and tightly integrated solution for Dynamics 365 that targets end users to create intelligent conversational agent solutions. Copilot is more suitable for solutions to be used in the Dynamics 365 application’s frontends. Both evolve and extend at the time of writing, adding new features, and both change their billing regularly.

In our integration solution, logic apps seem to be more of a fit since it is more flexible and more suitable for creating a backend application. And it can cost much less than the Copilot option. If you start everything from scratch, and if you choose the most basic plans in both solutions, they can cost head-to-head for around 3000 requests per month. Copilot has a monthly fee and free credits depending on the chosen billing, and costs per request are much cheaper in the Logic Apps option than the Copilot, but the app service plans required are more expensive per month.

However, if you already have an app service plan and already have multiple logic apps in your subscription, or if you plan to create more logic apps like this, you will only be adding your agent loops to the already existing plans. Then, using your AI agents via logic apps becomes much more affordable than acquiring an extra Copilot option for you. So, customers having multiple existing enterprise integrations can benefit from stepping into AI agent flows using the Logic Apps agent loops option.

Estimated Copilot costs (per 3000 requests per month) with most basic options:

Estimated Azure costs (per 3000 requests per month) with the most basic app service plan and Azure OpenAI service:

Please be aware that these pricing estimations are rough and fluctuate continuously as these solutions evolve. Determining which option is more suitable for you requires too many parameters to take into consideration.