Introduction

I have been working with Logic Apps since early 2016 when Logic Apps consumption based was released in public preview.

Ever since, the platform has matured, features have been added, and not too long ago it got some awesome new AI capabilities in the form of autonomous and conversational agents. The thing is, I mainly execute traditional enterprise application integration projects at my clients. And due to that, I didn’t have an opportunity to dive into the new capabilities. Even worse, developments in the field of AI are moving so terribly fast that I couldn’t catch up with my busy work schedule.

So, in the past month I started to invest some free time to see what the Azure ecosystem has to offer in terms of AI. And Logic Apps autonomous/conversational agents was one of the topics that I really wanted to explore. I started connecting weekly with some of my integration colleagues around the topic, to see what a good use case would be for Logic Apps with AI. There were a couple, but I had my struggles.

For some reason, I couldn’t come up with a proper use case for which Logic Apps agents could be a solution. Moreover, I started to switch to Azure AI Search and MS Foundry to see if Retrieval-Augmented Generation (RAG) could help me in my other journey to “generate” integration specifications and bicep/workflow code based on earlier developed integrations on the Hybrid Integration Platform I’m responsible for. I’m making some progress and learning MS Foundry and AI Search, something I might cover later this year.

Last week my team had a problem in production, and that instantly triggered me with a spot-on use case. Sometimes, only when the pieces fall into place do you start to see the bigger picture.

Within our integration platform we use Entra ID App registrations. These app registrations are either being used for the OAuth 2.0 client credentials flow we use within our integrations for Authentication and Authorization to many APIs in our API Management instance, or we hand them to source systems that push data towards our integration landscape through APIs.

In the next section I’ll explain what happened, and why this is an issue for us. And of course, I’ll dive into how Logic Apps agent loops is an excellent solution for such IT challenges.

Problem

As mentioned, app registrations have been an important part of our landscape to implement proper authentication and authorization and especially for the OAuth 2.0 client credentials flow that we have implemented for our APIs.

Company policy dictates that the expiry date of a client secret must be within a year (meaning a maximum validity of 365 days). We have all kinds of controls in place to push the secrets to a specific key vault through Azure DevOps and we also have a pipeline that will renew a secret for an App registration (and update the key vault) when triggered.

Nevertheless, we don’t have any mechanism that informs us of upcoming secret expirations. Since we have dozens of them, that causes a risk for the platform. And that risk unfortunately became reality when our most important app registration expired on dev, test, acceptance and production. And we weren’t notified before that happened.

Solution – Logic Apps autonomous agent

What I wanted, was to be notified in the weeks before expiration of such client secret. And of course, we could use a key vault secret that contains the app registration secret with an expiry date set, or we could have set up a regular Logic App workflow that checks secrets from time to time or have a DevOps pipeline that checks secrets through PowerShell. In the end; all roads lead to Rome.

I was curious how I could achieve such functionality, with minimal development effort. The next sections will explain step-by-step how to implement a notification system with a Logic Apps autonomous agent.

The goal for the workflow that I’ll create is:

• Use Microsoft Graph as a tool to retrieve app registrations.
• Gather all the app registrations of which the secret is about to expire.
• Inform me via e-mail (also a tool) with name and expiry dates.

Prerequisites

To get started with there are a couple of prerequisites.

• Logic App Standard (or consumption based) should be up and running and a system assigned managed identity should be assigned to it.
• or in case Logic Apps consumption based one could also use an app registration, but it requires some tweaking in the upcoming examples.

1. Have an AI model in place first

This part is out of scope for this blog post, but for the autonomous agent to work, you will need a model in place that the workflow can use.

I have used Microsoft Foundry and deployed a gpt-4.1-mini model to use for this demo. It’s cheap and it does the job properly.

2. Have some app registrations that will expire in the upcoming weeks

To test if the logic is working properly, some app registrations are needed with secrets that will expire. I also created one that isn’t expiring. Please note that all of them start with appreg-test-sahin.

3. Assign Application.Read.All permissions on Microsoft Graph

The identity being used need to have permissions in Application.ReadWrite.All Microsoft Graph. For part 1 of the tutorial Application.Read.All is sufficient. But in part 2 additional actions will be taken, which requires additional permissions. Therefore, the following example and pictures show ReadWrite.All

To achieve that the following PowerShell script is executed:

Connect-MgGraph -Scopes Application.ReadWrite.All, AppRoleAssignment.ReadWrite.All -TenantId [Your tenant id]

$ManagedIdentityName = "[Name of the managed identity, likely the name of your Logic App]"
$permissions = "Application.ReadWrite.All"

$getPerms = (Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'").approles | Where {$_.Value -in $permissions}
$ManagedIdentity = (Get-MgServicePrincipal -Filter "DisplayName eq '$ManagedIdentityName'")
$GraphID = (Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'").id

foreach ($perm in $getPerms){
    New-MgServicePrincipalAppRoleAssignment -ServicePrincipalId $ManagedIdentity.Id `
    -PrincipalId $ManagedIdentity.Id -ResourceId $GraphID -AppRoleId $perm.id
}

The result of this script is shown in the following pictures:

4. Create an autonomous agent workflow

• Go to your Logic App Standard -> Workflows -> Create
• Give your workflow a meaningful name and select Autonomous agents

• A blank workflow will be created, and it will look like this:

• The autonomous agent will run once in a while. We start by adding a Recurrence trigger once a month (or weekly, whatever fits your needs).

• For this demo, we’ll also need some variables. First is the prefix for the app registration names. All my app registrations follow a convention, and they all start with appreg-test-sahin, and I want the tool that will be retrieving app registrations to filter based this prefix. I also want the notification email to be sent to me.

• Now let’s talk a bit about the agent loop in the workflow in the next paragraph.

5. The Agent Loop

Configuring the agent loop, it mainly consists of 2 sections.

• First, you create a connection to your AI model. With an MS Foundry model being deployed, you should choose Azure OpenAI.

• AI model. This is the model you have deployed within your subscription. In my case I have set up MS Foundry and deployed a gpt-4.1-mini model into that.
• Instructions for agent. This is the core part of the Agent loop. Here you give detailed instructions to the model, how it should behave, how it should interact with the tools and what process it must follow and what it must and must not do. Be specific! I found out that ambiguous or unclear instructions will result in logic not being executed. When you have written your instructions, you could ask ChatGPT to improve the instructions for your agent.
  

My agent instruction (that worked and without any help of ChatGPT):

You are a support engineer that monitors application registrations in Entra Id.

1) On scheduled intervals you need to check all application registrations that start with "@{variables('appregNamePrefix')}" and check if their secret is about to expire 3 weeks from today. Only do this for most recent secret of an app registration. The most recent secret is the one with the latest "endDateTime" value.

2) After you have determined which client secrets will be expiring, relevant information MUST be emailed so necessary actions can be taken to renew the secrets.

3) **Important** Your run continues by sending an e-mail to @{variables('emailAddress')} in a HTML formatted e-mail that contains a polite introduction mentioning the name of the recipient followed by a table containing the name of the app registration and the expiration date of the secret in dd-MM-yyyy format. Make sure that the table is well formatted.

If there are no secrets that will expire, no e-mail is sent.

6. Adding Tools to the Agent Loop

What makes Logic Apps so powerful with AI models and the agent loop, is that you have more than 1400 out of the box connectors available to connect to software and systems. All these connectors can be used as a tool for the workflow agent to perform its task. In my case there are 2 tools that I need:

• A HTTP request to MS Graph to retrieve app registrations and their secrets expiration dates that start with the prefix I set in the variable.
• The Office 365 connector that will be used to send an e-mail to me if there are any secrets that will expire in the next 3 weeks.

6.a) The HTTP tool and action (MS Graph)

When you add an action/connector that you want to use, it will be wrapped inside an agent tool action.

• This container action is mainly used to provide the model with more context. The description gives the model more context about the tool and the Agent parameters define what the tool needs.

• The HTTP action in its turn looks as follows:

The URI is as follows and contains a filter with the name prefix and selection criteria for the app registration. We want the id, display name and information about the secret(s) it has. It will return all app registrations that start with “appreg-test-sahin”.

https://graph.microsoft.com/v1.0/applications?$filter=startsWith(displayName,'@{agentParameters('appregNamePrefix')}')&$select=id,displayName,appId,passwordCredentials

Authentication is done via Managed Identity to https://graph.microsoft.com 

6.b) The email tool and action (Office 365 connector)

• The idea is the same. There is a tool container which provides context to the model. In this case a short description of the tool and some parameters that the agent needs to provide to send an e-mail notification for expiring app registration secrets.

• The send email action. Connection has been set up with my own email address and as you may notice, the required fields only contain the agent parameters from the tools. This means that the agent is in control in creating this email.

7) Let’s test if it works!

After saving the workflow and starting a workflow run, you can open the completed run and it will show the agent log to understand what the agent loop did.

And if everything went as expected, an email will be in the mailbox. Isn’t that awesome?

What’s next?

In part 2 of this article, we will expand the agent capabilities with:

• Creating new secrets for app registrations that are about to expire.
• Create or update key vault secrets for app registration secrets (so they can be used by your logic).
• Send an email with the new secret values and expiration dates.

Stay tuned!

Conclusion and takeaways

Autonomous and conversational agent are powerful additions for Logic Apps. I must admit that I really had struggles in finding proper cases in which Agent loops might be of help. Perhaps because I was overthinking it or because I just needed to experiment with it in the first place.

While I’m not 100% comfortable yet with “trusting” an AI model to do the work for me, I see benefits and consistent results in execution. The power lies in functionally telling the agent what to do and setting boundaries, and this saves you time in implementing complex logic (e.g. filtering the expiring secrets, looping, composing an email, etc.).

Anyhow, I am really happy that I now have a mechanism in place that proactively notifies me on secret expiration. And it will save us from reactive troubleshooting!

Some final thoughts:

• I could have achieved that same without an agent loop. But the workflow would contain much more logic to check all app registrations and the secrets (e.g. with a loop) and composing an e-mail the old way.
• Autonomous agents take away a lot of the technical effort and implementation of a workflow. Instead, the focus shifts to providing tools and effective instructions to your model.
• Writing proper instructions and providing sufficient context is very important. At some point, I didn’t get an e-mail anymore due to some changes in the context descriptions. It’s through trial and error that I got it to work again.