When building integration workflows with Azure Logic Apps Standard, there’s often a need to track custom business events that sit between pure technical telemetry and business process monitoring. Recently, while authoring a Logic App Standard workflow, I needed to track the total number of items processed along with a breakdown of successful versus failed processing attempts.

While Logic Apps provides excellent run history and built-in diagnostics, custom events allow you to capture specific business actions and metrics that align with your reporting requirements. In this post, I’ll show you how to send custom events directly to Azure Application Insights using the ingestion endpoint from the Application Insights connection string.

The Use Case

I needed to answer questions like:

• How many items were processed in total for a workflow run?
• What’s the success vs. failure rate for different item types?
• Can I correlate these metrics with other application telemetry?

Standard Logic Apps diagnostics don’t easily provide this level of custom business metric tracking, making Application Insights custom events the perfect solution.

Understanding the Application Insights Ingestion Endpoint

The Application Insights connection string contains several components, including the ingestion endpoint. It looks something like this:

InstrumentationKey=<key>;IngestionEndpoint=https://<region>.in.applicationinsights.azure.com/;LiveEndpoint=https://<region>.livediagnostics.monitor.azure.com/;ApplicationId=<ID>

// Broken Down
//------------
InstrumentationKey=<key>

IngestionEndpoint=https://<region>.in.applicationinsights.azure.com/

LiveEndpoint=https://<region>.livediagnostics.monitor.azure.com/

ApplicationId=<ID>

The Ingestion Endpoint component as the name suggests is used for the ingest of telemetry/metrics/events/etc. The component points to a regional Application Insights endpoint with the Instrumentation key supplied later in in the ingestion request for targeting your specific Application Insights instance.

The missing part to this endpoint that allows you to post your telemetry is a trailing v2/track. Combined this appears as follows: https://<region>.in.applicationinsights.azure.com/v2/track

We’ll use the IngestionEndpoint combined with the InstrumentationKey to send custom events via HTTP requests.

Implementation

Step 1: Configure Application Insights Connection in Bicep

First, we need to extract the ingestion endpoint and instrumentation key from Application Insights and make them available to our Logic App as application settings:

resource applicationInsights 'Microsoft.Insights/components@2020-02-02' existing = {
  name: applicationInsightsName
}

resource logicAppDeployment 'Microsoft.Web/sites@2025-03-01' = {
  name: logicAppName
  location: Location
  kind: 'functionapp,workflowapp'
  properties: {
    ...
    siteConfig: {
      ...
      appSettings: [
        ...
        {
          name: 'appInsightsIngestUrl'
          value: '${split(filter(split(applicationInsights.properties.ConnectionString, ';'), val => contains(val, 'IngestionEndpoint='))[0], '=')[1]}v2/track'
        }
        {
          name: 'appInsightsKey'
          value: applicationInsights.properties.InstrumentationKey
        }
      ]
    }
  }
}

The Bicep code above parses the connection string to extract the ingestion endpoint and appends the required v2/track path. It also captures the instrumentation key needed to point to your instance.

Step 2: Create Logic App Parameters

Add parameters to your Logic App Workflow’s parameters.json file to reference these application settings:

{
    "AppInsightsIngestionUrl": {
        "type": "String",
        "value": "@appsetting('appInsightsIngestUrl')"
    },
    "AppInsightsKey": {
        "type": "String",
        "value": "@appsetting('appInsightsKey')"
    }
}

These parameters allow your workflow to access the ingestion URL and key at runtime.

Step 3: Add the Workflow Actions and Event Payload

In your Logic App workflow, use a Compose action to build the Application Insights event payload. The payload follows the Application Insights telemetry schema:

{
  "name": "Microsoft.ApplicationInsights.@{parameters('AppInsightsKey')}.Event",
  "time": "@{utcNow()}",
  "iKey": "@{parameters('AppInsightsKey')}",
  "data": {
    "baseType": "EventData",
    "baseData": {
      "ver": "2",
      "name": "LogicAppWorkflowName",
      "properties": {
        "workflowRunId": "@{workflow().run.name}",
        "ItemsProcessed": "",
        "Type1Count":  "",
        "Type1CountFailures":  "",
        "Type2Count":  "",
        "Type2CountFailures":  "",
        "Type3Count":  "",
        "Type3CountFailures":  ""
      }
    }
  }
}

Key components of the payload:

• name: Event identifier following Application Insights naming convention
• time: Timestamp in UTC format
• iKey: Your instrumentation key
• data.baseData.name: The custom event name that will appear in Application Insights
• data.baseData.properties: Your custom properties containing business metrics

Step 4: Send the Event via HTTP

Add an HTTP action to send the composed payload to Application Insights:

Configure the HTTP action with:

• Method: POST
• URI: @{parameters('AppInsightsIngestionUrl')}
• Headers: Content-Type: application/json
• Body: Output from the Compose action

The HTTP action will receive a 200 OK response when the event is successfully ingested.

The response body should indicate a successful ingestion as follows:

{
    "itemsReceived": 1,
    "itemsAccepted": 1,
    "errors": []
}

Step 5: Query Your Events

After your workflow runs, navigate to Application Insights and use the following KQL query to view your custom events:

customEvents
| where name == "LogicAppWorkflowName"
| project timestamp, 
          workflowRunId = tostring(customDimensions.workflowRunId),
          itemsProcessed = toint(customDimensions.ItemsProcessed),
          type1Success = toint(customDimensions.Type1Count),
          type1Failures = toint(customDimensions.Type1CountFailures)
| order by timestamp desc

You can create custom dashboards, alerts, and reports based on these events.

Summary

By leveraging the Application Insights ingestion endpoint directly via HTTP actions, you can easily track custom business metrics from your Logic Apps Standard workflows without external dependencies. This approach lets you correlate workflow execution with wider integration components/applications and build comprehensive dashboards based on your specific use case.

Hope this helps, and keep Workflow-ing!

Microsoft has just introduced something quite revolutionary into the world of integration: Agent Loop, a new capability in Azure Logic Apps that lets you build AI-powered agents directly into your workflows. On the surface, it might seem like another incremental feature. But dig a little deeper, and the implications are huge!

Let’s break it down.

What Is Agent Loop?

Agent Loop is Microsoft’s way of embedding advanced AI decision-making into Logic Apps workflows. Think of it like adding a smart co-pilot into your integration flows, an agent that can retain context, reason over time, and take meaningful actions. It uses an LLM like Azure OpenAI under the hood, paired with a memory store that persists throughout the workflow, allowing the agent to understand, adapt, and make decisions across multiple steps.

This isn’t just a chat feature bolted onto Logic Apps. This is a new integration pattern.

Why This Matters

1. From Orchestrators to Orchestrators-With-Brains

Traditionally, Logic Apps has been a powerful tool for orchestrating workflows, but each step is stateless and reactive. With Agent Loop, Microsoft is blurring the lines between workflow automation and autonomous decision-making. Your integration logic can now evolve based on prior inputs, contextual signals, or even unstructured content.

Imagine an agent that:

• Detects anomalies in data feeds and adjusts routing accordingly
• Analyses unstructured text (emails, tickets, PDFs) and initiates remediation
• Talks to legacy systems, interprets responses, and adapts its logic in real time

This isn’t just modernisation, it’s next-gen augmentation.

2. For BizTalk Migrations, This Changes the Equation

Many of the workflows built in BizTalk were complex not just because of their integration points, but because of the decision logic baked into orchestration layers. Until now, moving those workflows into Azure meant carefully untangling rulesets, mappings, and dependencies.

Agent Loop gives you a new option, wrap legacy logic in an AI reasoning layer, preserve existing behaviour where needed, and inject flexibility where it’s long overdue. That’s a big deal for organisations plotting their BizTalk to Azure Integration Services (AIS) migration.

3. Bridging Structured and Unstructured Worlds

In most enterprises, structured data lives in databases, but the real mess, the emails, PDFs, meeting notes, customer queries, is where value is trapped. Agent Loop lets you embed GPT-style agents that can process unstructured inputs, make sense of them, and act accordingly.

In effect, it bridges the gap between API-driven systems and human language interactions, a holy grail for integration architecture.

What Could This Enable?

Some early scenarios come to mind:

• Intelligent triage: Auto-routing support tickets based on nuanced analysis, not just keywords
• Contract processing: Reading legal documents and extracting obligations for ERP updates
• Integration self-healing: Agents that spot failed API calls and retry or switch endpoints contextually
• Customer 360 augmentation: Combining CRM data with email sentiment to tailor outreach strategies

What’s powerful here is not just the AI, it’s that the AI lives inside your governed, observable, enterprise-ready integration fabric. That’s the kind of maturity architects have been waiting for.

The Bigger Picture

This move by Microsoft is a signal, AI isn’t a separate strategy anymore, it’s becoming part of the plumbing. And for IT leaders, that means a shift in how we think about capability building.

Where before we asked, “What can be automated?”, now we ask, “What can be intelligently automated?” Where we once feared black-box AI, now we can build AI agents that live inside controlled workflows.

A Word of Caution

This is still early days. Agent Loop is in public preview, and like all AI features, there are concerns around predictability, testing, and operational risk. Governance, testing harnesses, and monitoring patterns will also need to be matured alongside adoption.

But make no mistake, this is a foundational shift.

Getting Started

Agent Loop is already available in Logic Apps Standard! Here are some Microsoft resources to help you begin:

• Documentation: Explore the agent loop concepts and detailed guide with step-by-step instructions on how to configure and use Agent Loop.
• Samples & Demos: Watch pre-recorded demos showcasing both conversational and autonomous agent scenarios built with Agent Loop. You’ll also get a preview of exciting features coming soon.

Final Thoughts

If you’re leading a modernisation initiative, working through a BizTalk migration, or trying to unify integration and automation under a future-proof architecture, Agent Loop deserves your attention.

It’s one of those moments where what looks like a feature is actually a new paradigm. The integration space just got a whole lot smarter,and that changes everything.

Further Reading:

Official Announcement – Microsoft Tech Community

In previous articles I have subtly referenced risks and best practices regarding HTTP triggered workflows and their use of Access Keys for security, such as:

• Some Potential Risks:

  • If a Key is leaked, it can be used by anyone who obtains it to call your Logic App Workflow.
  • If a Key has expired or been invalidated then services, applications, and or users who have not been provided a new key will cease to be able to invoke your workflow.

• Some Access Key Best Practices to mitigate risks:

  • Have a revocation plan - Make sure that you are prepared to respond if a Key is compromised.
  • Have a rotation plan - Look to replace the Key with new ones at regular intervals.

Given the risks and best practices described, I wanted to put together a solution whereby the regeneration and issue of the access keys could be automated. This allows for keys to be regenerated on a regular schedule provided they might need to comply with security policies. Further to this, regenerating the access keys means old ones are invalidated and thus protects you in the incident were a key is compromised.

Solution

To automate the regeneration of the access keys, I am going to make use of the Azure Rest API and the following components:

• Azure Key Vault - Used as secure storage for the workflow access keys.
• Identity and Access Management - Services, applications, and users will gain access to the access key secrets in Key Vault through Identity and role assignment at the secret level (Principal of Least Privilege).
• PowerShell Script - A script developed to invoke the Regenerate Access Key Azure Rest API.
• Bicep Template - A template developed to obtain and re-issue the workflow access keys to Key Vault.
• DevOps Pipeline - Using an automated pipeline to manually or on schedule invoke the PowerShell script and redeploy the Bicep template.

⚠️ Note

• For automated roll out of access keys to services, applications, or users, their reference of the key vault secrets must not be directly tied to a version of the secret, rather always point to current.

• Key vault reference values are cached in App Services and refetched every 24 hours.

  • To refetch values immediately, the following options are available:

    • Manually through the Portal by using the “Pull Reference Values” under “Environment Variables”.

    • Update the App Config. Any configuration change to the app causes an app restart and an immediate refetch of all referenced secrets.

    • Preferred - Pipeline powershell task after roll out that invokes a refetch.

      az rest --method post --url https://management.azure.com/[Resurce ID]/config/configreferences/appsettings/refresh?api-version=2022-03-01

Script to Regenerate a Workflow Access Key

The following PowerShell script is used to Regenerate a specific Logic App Workflow Access Key. By regenerating a new key, the previous will also be invalidated.

$SubscriptionId = '{SubscriptionID}'
$ResourceGroupName = '{ResourceGroupName}'
$LogicAppName = '{Standard Logic App Name}'
$WorkflowName = '{Workflow Name}'

# Not required if automated and using as part of a DevOps pipeline.
Connect-AzAccount -Subscription $SubscriptionId 

$accessToken = Get-AzAccessToken

$request = @{
    Method = 'POST'
    Uri = "https://management.azure.com/subscriptions/$($SubscriptionId)/resourceGroups/$($ResourceGroupName)/providers/Microsoft.Web/sites/$($LogicAppName)/hostruntime/runtime/webhooks/workflow/api/management/workflows/$($WorkflowName)/regenerateAccessKey?api-version=2024-04-01"
    Body = @{
        keyType = 'Primary'
    } | ConvertTo-Json
    Headers = @{
        Authorization = "Bearer $($accessToken.Token)"
        "Content-Type" = "application/json"
    }
}

Invoke-RestMethod @request

Bicep Template to Obtain and Surface Workflow Access Keys to Key Vault

The following Bicep template is used to obtain the workflow access key and create the secret in key vault (if already deployed, then a new version).

/********************************************
Bicep Template: Workflow Access Keys Role Out
        Author: Andrew Wilson
*********************************************/

targetScope = 'resourceGroup'

// ** User Defined Types **
// ************************

@description('Object type used to identify a Workflow and Trigger')
@metadata({
  workflowName: 'The name of the workflow within your Standard Logic App.'
  workflowTrigger: 'The HTTP trigger name within the workflow'
})
@sealed()
type workflow = {
  workflowName: string
  workflowTrigger: string
}

@description('Array of Standard Logic App Workflows')
@minLength(1)
type workflowArray = workflow[]

// ** Parameters **
// ****************

@description('Name of the Logic App to place workflow(s) sig into KeyVault')
param LogicAppName string

@description('Name of the Key Vault to place secrets into')
param keyVaultName string

@description('Array of Workflows to obtain sigs from.')
param workflows workflowArray

// ** Variables **
// ***************

// ** Resources **
// ***************

@description('Retrieve the existing Logic App')
resource logicApp 'Microsoft.Web/sites@2024-04-01' existing = {
  name: LogicAppName
}

@description('Retrieve the existing Key Vault instance to store secrets')
resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
  name: keyVaultName
}

@description('Create the Logic App workflow access key as a secret - Deployment principle requires RBAC permissions to do this')
resource vaultLogicAppKey 'Microsoft.KeyVault/vaults/secrets@2023-07-01' = [for workflow in workflows: {
  name: '${logicApp.name}-${workflow.workflowName}-sig'
  parent: keyVault
  tags: {
    ResourceType: 'LogicAppStandard'
    ResourceName: logicApp.name
  }
  properties: {
    contentType: 'string'
    value: listCallbackUrl(resourceId('Microsoft.Web/sites/hostruntime/webhooks/api/workflows/triggers', logicApp.name, 'runtime', 'workflow', 'management', workflow.workflowName, workflow.workflowTrigger), '2022-09-01').queries.sig
  }
}]

// ** Outputs **
// *************

In the instance that the access key is compromised due to a user/component/service being compromised, then the action would be two fold:

1. Revoke the user/component/service access to the secret in key vault.
2. Regenerate and issue a new access key.

Hope this helps and have fun.

Following the idea of defensive programming or as I like to call it for Logic Apps (being low code): defensive processing, it is considered good practice to wrap your workflows in a try-catch pattern to handle the unexpected. The pattern makes use of a mixture of Run After conditions and the Scope block.

• Run After Conditions | used to define the execution order based on the state of the previous action or scope
• Scope Block | provides the ability to group a series of actions. If any action within the scope fails, the whole scope will fail (unless handled via other means)

By placing your actions within a “try” scope with the assumption that each action will run after the success of the previous, if there is an action failure, the scope will fail also.

Using the Run After conditions on either a proceeding action or scope, you can “catch” any has failed, is skipped, or has timed out states from the “try” scope. In effect this makes up your simple try-catch block.

Example

It is possible once you have entered into the catch scope to retrieve details of the resulting try scope by using the expression @result('Scope-Try'). The expression will provide an array of all the actions and their details including if they were successful or failed with a given exception message.

This is really useful but how does it hold up when nested you may ask…

Nested Try-Catch Scopes

Nested try-catch scopes can be handy when you have smaller segments of the larger workflow that can be tried as a group; preventing unnecessary complexity in handling issues and failures later in the workflow or as a whole.

Example

This example still has its overarching try-catch due to the possibility of either sub catches containing actions that can fail, be skipped, or time out.

Nesting try-catch scopes offers the same capabilities as un-nested. However, there are caveats to remember when nesting in this way:

• Complexity | readability and maintainability is always paramount when designing workflows.
  • Make sure to appropriately and consistently title actions and scopes.
  • Add comments, especially on scopes as this can aid in describing the processing and functionality that sits within.
• Intentional flow review | given the added complexity through nesting and run after configurations, thorough review and testing of processing flow should be conducted.
  • A method of doing this is to test/mock outputs on actions.
• Handles the unexpected | as with the single try-catch, this is not a method in handling non-“happy path” results from processing, rather the unexpected failures, skips, or timeouts.

As referred to in the last point in the caveats, if the try-catch both singular and nested aids in the unexpected, how can I add to this pattern to help with handling “un-happy” paths. This cues the Compensating Transaction pattern…

Compensating Transaction Pattern

The Compensating Transaction pattern is useful when you are trying to attain an eventually consistent operation that consists of multiple steps. If one or more of the steps fail, this pattern can be used to undo the steps performed.

One of the most basic forms of compensation or undo is to notify for manual remediation. This is the scenario that I will use as an example.

Scenario

Let’s assume that a taxi booking process needs to be automated as a logic app workflow. There are four steps involved in this process:

1. Check to see if the customer is an existing customer, and if so obtain an enriched form of their details from our system.
2. Check if the time slot is available with a local driver.
3. If the time slot is available, book the time slot with the local driver.
4. Send a notification to the customer regarding details of the booked time slot and their driver.

If there are any problems with processing these four steps, a notification will need to be sent for manual remediation. This must include:

• The steps that were successful
• The step that was not able to be performed
• The steps that were skipped after the one that failed to be processed

In this scenario and example, the use of the try-catch pattern (nested) is used to catch the unexpected problems in processing. The addition of the Condition action allows us to perform process validation (the action may have succeeded, but did it return the result we desired?). The example further uses the Condition action to validate if the workflow should continue onto the next processing step given the previous may have failed.

Example

The example shows a subset of the steps implemented as the rest are a repeat demonstration.

Given this workflow design, we can process faults in a controlled manner both expected and unexpected. We can control which processing steps should be performed given an error may have occurred, and we can through our transaction log give a full account allowing for full remediation.

There are caveats to remember when implementing this pattern and example:

• Complexity | readability and maintainability is always paramount when designing workflows.
  • Make sure to appropriately and consistently title actions and scopes.
  • Add comments, especially on scopes as this can aid in describing the processing and functionality that sits within.
• Intentional flow review | given the added complexity through nesting, conditions, and run after configurations, thorough review and testing of processing flow should be conducted.
  • A method of doing this is to test/mock outputs on actions.

Hope this helps and have fun.

Prior to the Christmas break I was involved in writing some integrations that used a mixture of Logic Apps Standard and Function Apps. It was agreed as part of the architecture that user-assigned identities would be the best fit. As part of the implementation, I observed that the differences in configuration setup between system-assigned and user-assigned wasn’t widely understood. This article aims to show a brief run through of both.

Setup and Difference with System-Assigned

System-Assigned

The general process when using a System-Assigned identity is as follows:

1. Create a Key Vault Instance.

2. Create secrets required by the application.

3. Create the app resource (Logic App / Function App)

   • As part of the configuration, specify the identity as System Assigned.

   • Reference the key vault secret(s) in your App Settings.

4. Authorise the applications identity read access to key vault or specifically the key vaults secret.

The main points with System-Assigned setup is:

• The identity is tied to the created app resource and its life-cycle
• The resource cannot reference key vault secrets at the point of creation
  • Authorisation to read the key vault secrets has not occurred at this point
• The identity cannot be associated with other resources

User-Assigned

The general process when using a User-Assigned identity is as follows:

1. Create a Key Vault instance

2. Create secrets required by the application(s)

3. Create the user-assigned identity

4. Authorise the user-assigned identity read access to key vault or specifically the key vaults secret.

5. Create the app resource (Logic App / Function App)

   As part of the resource configuration

   • Specify the identity as user-assigned and reference the created identity in step 3

   • Specify the identity to be used for key vault reference operations by setting the keyVaultReferenceIdentity property to the resource ID of the user-assigned identity

   • Reference the key vault secret(s) in your App Settings.

The main points with User-Assigned setup is:

• The identity is managed outside the context of a resource and its life-cycle
• A resource that uses the identity can read secrets from keyvault at the point of creation
  • Given that the authorisation has occurred prior to the resource creation.
• The identity can be associated with on or more resources

⚠️ Note One of the most common gotchas [user-assigned] is missing or forgetting to specify the identity to be used for key vault reference operations (keyVaultReferenceIdentity property - Step 5).

Hope this helps and have fun.

Overview

The recent work that I have been doing with Standard Logic Apps and linking them as backends to Azure API Management has relied on the use of the Logic App Workflow SAS key for security. This is a valid authentication approach, but there are risks that you need to be aware of as well as best practices that you need to be abiding by. Such as:

• Some Potential Risks:

  • If a SAS is leaked, it can be used by anyone who obtains it to call your Logic App Workflow.
  • If a SAS expires and the API Management API has not been updated to make use of the updated SAS, then the integration functionality will be hindered.

• Some SAS Best Practices to mitigate risks:

  • Always use HTTPS - If a SAS is passed over HTTP and intercepted, an attacker can perform a man-in-the-middle attack and read the SAS.
  • Have a revocation plan - Make sure that you are prepared to respond if a SAS is compromised.
  • Have a rotation plan - Look to replace the SAS with new ones at regular intervals and include shorter time intervals for the expiration period.

There are other features that can be used to further restrict access to your Logic App, for instance adding IP Address Restrictions to limit traffic to only your API Management Instance.

But what if you require further governance whereby the Logic App requires a valid Entra ID bearer token in order to be invoked. To implement this we are going to make use of Easy Auth.

Easy Auth

Easy Auth is a built-in authentication and authorisation capability provided by Azure App Services and Azure Functions. Easy Auth makes use of federated identity whereby a third-party identity provider manages the user identities and authentication flow for you. Fortunately for us, Standard Logic Apps have the same foundations as Azure Functions and therefore Easy Auth is also extended to Logic Apps Standard.

Easy Auth is a platform feature running on the same virtual machine as your application. Once enabled, any incoming HTTP requests will pass through this feature prior to being handled by your application. Easy Auth runs separately from your application code and can be configured using ARM settings or using a configuration file.

Using Easy Auth and Linking to API Management

As mentioned above, I would like to use Easy Auth to protect my HTTP Triggered Azure Logic App (Standard) workflows, but more importantly, I would like Azure API Management to be the only identity that can be used to make requests to my workflows as shown in the diagram below:

Note:

As we will be invoking the Logic App HTTP triggered workflows with Easy Auth, we no longer need to specify the following parameters in the request:

• sp: The permissions; generally ‘read’ or ‘write’
• sv: The version number of the query parameters
• sig: Shared-Access-Signature

Furthermore, I have opted for Infrastructure as Code (IaC) as my method of implementation, specifically Bicep.

For setup, we will need to conduct the following four steps:

1. Configure the Logic App to Use Microsoft Entra sign-in.

   Working through the Microsoft instructions in the link above, you will require as minimum the following when setting up the Logic App Application Registration:

   • Select the supported account type. (I’m using Current tenant - single tenant)

   • Setup a Redirect URI for your Logic App:

     Select Web for platform and set the URI to <app-url>/.auth/login/aad/callback. For example, https://contoso.azurewebsites.net/.auth/login/aad/callback.

   • Make not of the Application (client) ID.

   • Create a Client Secret and store this securely (I’m using Azure DevOps Secure Library Variables as part of a deployment).

     This is a secret value that the application uses to prove its identity when requesting a token. This value is saved in your app’s configuration as a slot-sticky application setting named MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. If the client secret isn’t set, sign-in operations from the service use the OAuth 2.0 implicit grant flow, which isn’t recommended.

   • Expose an API > Add > Save. This value uniquely identifies the application when it’s used as a resource, allowing tokens to be requested that grant access. It’s used as a prefix for scopes you create.

     I am using a single-tenant app and therefore using the default value. Appears as such api://<application-client-id>

   • Add the user_impersonation scope to your App Registration allowing Admins and users to consent.

2. Make sure that API Management has been setup with Managed Identity. I am using System Assigned.

   @description('Deployment of the APIM instance')
   resource apimInstanceDeploy 'Microsoft.ApiManagement/service@2022-08-01' = {
     ...
     identity: {
       type: 'SystemAssigned'
     }
     ...
   }
   

3. Store the App Registration Secret in KeyVault and Reference in your Logic App Settings to allow the Logic App to prove its identity.

   ...
   
   @secure()
   @description('The client secret for the Easy Auth App Registration')
   param applicationEasyAuthClientSecret string
   
   ...
   
   @description('Role Definition Id for the Key Vault Secrets User role')
   var keyVaultSecretsUserRoleDefId = '4633458b-17de-408a-b874-0445c86b69e6'
   
   ...
   
   @description('Deploy the Application Easy Auth App Registration Secret to Keyvault')
   resource vaultLogicAppRegSecret 'Microsoft.KeyVault/vaults/secrets@2023-07-01' = {
     name: '${applicationLogicAppName}-EasyAuth-Secret'
     parent: applicationKeyVaultDeploy
     properties: {
       contentType: 'string'
       value: applicationEasyAuthClientSecret
     }
   }
   
   ...
   
   @description('Deploy the Application Standard Logic App')
   resource applicationLogicAppStandardDeploy 'Microsoft.Web/sites@2024-04-01' = {
     name: applicationLogicAppName
     location: location
     identity: {
       type: 'SystemAssigned'
     }
     ...
     resource config 'config@2024-04-01' = {
       name: 'appsettings'
       properties: {
         ...
         MICROSOFT_PROVIDER_AUTHENTICATION_SECRET: '@Microsoft.KeyVault(VaultName=${applicationKeyVaultDeploy.name};SecretName=${vaultLogicAppRegSecret.name})'
         ...
       }
     }
   }
   
   ...
   
   @description('Create the RBAC for the Logic App to Read the Secret from Key Vault')
   resource applicationLogicAppRBACWithKV 'Microsoft.Authorization/roleAssignments@2022-04-01' = {
     name: guid(applicationKeyVaultDeploy.id, applicationLogicAppStandardDeploy.id, keyVaultSecretsUserRoleDefId)
     scope: vaultLogicAppRegSecret
     properties: {
       principalId: applicationLogicAppStandardDeploy.identity.principalId
       roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', keyVaultSecretsUserRoleDefId)
       principalType: 'ServicePrincipal'
     }
   }
   

4. Enable Easy Auth on the Standard Logic App using ARM/Bicep Template AuthSettingsV2 or ARM REST API. I am using a Bicep Template.

   @description('Setup the Easy Auth config settings for the Standard Logic App')
   resource applicationAuthSettings 'Microsoft.Web/sites/config@2023-01-01' = {
     name: 'authsettingsV2'
     parent: applicationLogicAppStandardDeploy // Existing Standard Logic App for Easy Auth to be enabled
     properties: {
       globalValidation: {
         requireAuthentication: true
         unauthenticatedClientAction: 'AllowAnonymous' // Do not change: See note below.
       }
       httpSettings: {
         requireHttps: true
         routes: {
           apiPrefix: '/.auth'
         }
         forwardProxy: {
           convention: 'NoProxy'
         }
       }
       identityProviders: {
         azureActiveDirectory: {
           enabled: true
           registration: {
             openIdIssuer: uri('https://sts.windows.net/', tenant().tenantId)
             clientId: logicAppEasyAuthClientId
             clientSecretSettingName: 'MICROSOFT_PROVIDER_AUTHENTICATION_SECRET'
           }
           validation: {
             allowedAudiences: environment().authentication.audiences // Azure Management Plane [management.core.windows.net and management.azure.com]
             defaultAuthorizationPolicy: {
               allowedPrincipals: {
                 identities: [
                   apimInstance.identity.principalId // APIM System Assigned Principal Id
                 ]
               }
             }
           }
         }
       }
       platform: {
         enabled: true
         runtimeVersion: '~1'
       }
     }
   }
   

   Note:

   ¹EasyAuth is managed by AppService, and for an incoming request, it is a hop that comes before LA Runtime. When EasyAuth is enabled for a Logicapp standard, all incoming requests are validated against the policies in your V2 Auth settings.

   If you have “unauthenticatedClientAction”: “Return401” and when the request fails with EasyAuth, those requests are not routed to LA runtime and will fail with 401 from AppService. Therefore, you will also observe broken portal experience with Return401. When you set it to “AllowAnonymous”, all calls (failed and successful) will be routed to the LA runtime. The LA runtime will know if the request failed with EasyAuth or was successful and will process the request accordingly. For example, to get run histories, we authenticate it on SAS specific to that run generated based on the Logic Apps access keys. LA runtime will know that this request failed with EasyAuth but it will be processed successfully as it has valid SAS. The underlying AppService platform will have no knowledge of validating other auth like SAS.

5. Configure API Management to obtain a valid Bearer token and add it to the request Authorization Header. Implemented through APIM Policy.

   <!-- API ALL OPERATIONS SCOPE -->
   <policies>
       <inbound>
           <base />
           <!-- Uses System Assigned Managed Identity of the APIM Instance -->
             <authentication-managed-identity resource="https://management.azure.com/" output-token-variable-name="msi-access-token" ignore-error="false" />
             <set-header name="Authorization" exists-action="override">
    	         <value>@("Bearer " + (string)context.Variables["msi-access-token"])</value>
             </set-header>
       </inbound>
       <backend>
           <base />
       </backend>
       <outbound>
           <base />
       </outbound>
       <on-error>
           <base />
       </on-error>
   </policies>
   

6. Configure API Management to Append the Logic App Workflow api-version query parameter to the request. Implemented through APIM Policy.

   <!-- API OPERATION SCOPE -->
   <policies>
       <inbound>
           <base />
           <rewrite-uri template="__uri__" />
           <set-query-parameter name="api-version" exists-action="append">
               <value>__api-version__</value>
           </set-query-parameter>
       </inbound>
       <backend>
           <base />
       </backend>
       <outbound>
           <base />
       </outbound>
       <on-error>
           <base />
       </on-error>
   </policies>
   

Summary

In short, we have defined our three A’s (Access, Authentication, Authorisation) providing further governance on our Standard Logic App and API Management through the use of Easy Auth. To see my worked example, have a look at my GitHub repository along with a README that explains how to get started.

Hope this helps and have fun.

I have recently been adding email alerting to some Logic App Standard workflows as part of the error handling flow. In doing so I made use of an existing Office 365 Outlook Connector in the Azure Subscription; the connector is not built in for Standard Logic Apps but is rather part of the Managed Api Connections.

Managed Api Connectors require more than just the connection details to be detailed in the Logic Apps connections.json configuration as shown below:

{
  "managedApiConnections": {
    "office365": {
      "api": {
        "id": "@appsetting('office365_apiId')"
      },
      "authentication": {
        "type": "ManagedServiceIdentity"
      },
      "connection": {
        "id": "@appsetting('office365_connectionId')"
      },
      "connectionRuntimeUrl": "@appsetting('office365_connectionRuntimeUrl')"
    }
  }
}

The Managed API Connector also requires that the Logic App has been granted access to the Connector through the use of Access Policies. This can be configured through the Azure Portal or through infrastructure deployments, in my case I have opted for infrastructure deployments with the use of Bicep templates.

It was at this point that I realised that the Access Policy resource which is a child resource to Microsoft.Web/connections has not been documented, obtainable through an Azure Portal template export, or through the Resource Explorer.

Solution

From digging around the Access Policy resource has the following ARM Template Schema:

{
   "type": "Microsoft.Web/connections/accessPolicies",
   "apiVersion": "2016-06-01",
   "name": "[concat('<connection-name>'),'/','<object-ID>')]",
   "location": "<location>",
   "dependsOn": [
      "[resourceId('Microsoft.Web/connections', parameters('connection_name'))]"
   ],
   "properties": {
      "principal": {
         "type": "ActiveDirectory",
         "identity": {
            "objectId": "<object-ID>",
            "tenantId": "<tenant-ID>"
         }
      }
   }
}

Resource Properties

Parameter	Description
<connection-name>	The name for your managed API connection, for example office365
<object-ID>	The object ID for your Microsoft Entra identity, for example the system assigned managed identity of the logic app
<tenant-ID>	The tenant ID for your Microsoft Entra identity

In Bicep this takes on the following form:

@description('Create the access policy for the Logic App to access the managed Api Connection ')
resource managedAPIConnectionAccessPolicy 'Microsoft.Web/connections/accessPolicies@2016-06-01' = {
  name: logicApp.name // Using the Logic App Name for readability
  parent: managedAPIConnector
  location: Location
  properties: {
    principal: {
      type: 'ActiveDirectory'
      identity: {
        tenantId: subscription().tenantId
        objectId: logicApp.identity.principalId // Using the System Assigned Managed Identity of the Logic App
      }
    }
  }
}

Note

The Bicep tooling will give you the following warning but will not hinder in both the transpilation into ARM or in the deployment of the resource:

Resource type "Microsoft.Web/connections/accessPolicies@2016-06-01" does not have types available.

After setting up a Logic App (Standard) Backend in Azure API Management (APIM) in my last post, I wanted to try and see if I could create a Swagger definition from a Standard Logic App which could then be used to simplify the API authoring process in APIM. This post shows my methods of doing so.

If you haven’t already I would recommend reading my previous post as this one will be working off of the building blocks of the last.

As with my previous post, the high-level architecture has not changed and neither has the overall aim as shown below.

The design aims to abstract the backend from the api operations, i.e. the backend points to the Logic App and the individual operations point to the respective workflows. The design also specifies granular access to the workflow Shared-Access-Signature (sig) held in the applications specific KeyVault (to see further details on this, see Azure RBAC Key Vault | Role Assignment for Specific Secret). Furthermore, the additional required parameters that are necessary to call a workflow have been implemented through APIM policies to remove the need for callers to understand backend implementation.

I have opted for Infrastructure as Code (IaC) as my method of implementation, specifically Bicep. I have broken down the implementation of the diagram above into two parts, Application Deployment, and API Deployment.

Problem Space

Having come across the ARM REST API to generate a Swagger definition for a consumption Logic App, I went searching for the same functionality for Standard Logic Apps. Given a short time searching, I found the REST APIs situated under App Services with the Swagger generation API no where to be seen.

But would this stop me… No.

Knowing that I can retrieve a detailed definition of a Standard Logic App through the Azure Resource Manager, I started looking at methods of stripping out the detail that I would need to construct a Swagger Definition.

My chosen method to do this is through a PowerShell script using both ARM REST APIs and the az cli. This choice will allow me to run the script as non-interactive in future DevOps CI/CD pipelines.

Application Deployment

Our first step toward generating the Swagger definition for our Logic App is to deploy an instance of our Logic App to Azure. The process has not changed from the last post apart from the addition of step 4. As shown in the diagram below, step 4 is where we will use the PowerShell script that I have written to extract the core details of our Logic App and workflows to construct a Swagger Definition.

The script has been designed to take a ControlFile.json that you update with one or more HTTP triggered workflows and API details to assist in the retrieval and generation of the definition. There is an example control file in my GitHub repository.

The SpecCreator.ps1 takes the following parameters:

<#
    .SYNOPSIS
	Creates a Swagger definition for a select Standard Logic App and its specified Workflows.

    .DESCRIPTION
	Uses a series of parameters to derive the Standard Logic App and the Workflows to include in the base Swagger definition template. 

    .PARAMETER SubscriptionId
    The ID of the Subscription that the Standard Logic App is Hosted in.

    .PARAMETER ResourceGroupName
    The Resource Group Name that the Standard Logic App is Hosted in.

    .PARAMETER LogicAppName
    The Name of the Standard Logic App to use for the Swagger Definition.

    .PARAMETER APITitle
    API Name used to define the set of operations.

    .PARAMETER APIDescription
    Description of the API and its set of operations.

    .PARAMETER APIVersion
    None-Mandatory - Specified version of the API. Default is 1.0.0.0

    .PARAMETER SpecTemplatePath
    None-Mandatory - Base path to the swagger definition template, doesn't include the name of the file.

    .PARAMETER ControlFile
    None-Mandatory - Base path to the json control file used to identify the set of Workflows to extract as operations for the swagger definition, doesn't include the name of the file.

	.PARAMETER InteractiveMode
	If specified will request the user to interactively login into Azure for az tooling.
    #>

The script then uses a series of ARM REST API calls to obtain the following detail:

• Request Schema (if one is provided).
• Workflow Definition.

Using the Workflow Definition, we can interrogate the Workflow Trigger for details such as:

• HTTP Method.
• Relative Paths.
  • Note: Path Parameters are expected to be wrapped with curly braces, for example:
    • /users/{id}
    • /cars/{carId}/drivers/{driverId}
    • cars/{carId}/drivers/{driverId}
    • /{carId}/{driverId}
    • {carId}

Once all the Workflow details have been obtained, the script uses an imported tokenised Swagger Definition to generate the respective Definition for your Standard Logic App and Workflows.

API Deployment

For the most part, the API Deployment has not changed. We are using the same Bicep to create the APIM Instance, APIM Backends/Named Values, and Policies. The main change to our Bicep Deployment occurs in step 2.1 as shown in the diagram below.

Rather than constructing the API and API Operations individually through Bicep Resources as done in the previous post, we are going to define the APIM API along with the generated Swagger Definition from earlier steps. APIM validates the Swagger Definition and uses it to construct the API and Operations on our behalf.

The three main differences to our API deployment are:

1. We need to make use of the loadTextContent Bicep function to load the generated Swagger Definition into our Bicep Template.

   var swaggerDefinition = loadTextContent('../../SwaggerGenerator/GeneratedSpec.json')
   

2. We need to change the Microsoft.ApiManagement/service/apis resource to accept our generated Swagger Definition:

   @description('Create the Logic App API in APIM - Loading in Swagger Definition')
   resource logicAppAPI 'Microsoft.ApiManagement/service/apis@2022-08-01' = {
     name: apiName
     parent: apimInstance
     properties: {
       displayName: apimAPIDisplayName
       subscriptionRequired: true
       path: apimAPIPath
       protocols: [
         'https'
       ]
       format: 'swagger-json'
       value: swaggerDefinition
     }
   }
   

3. We need to remove the following Bicep Module call to create the API Operations as this will now be done for us.

   @description('Deploy logic App API operation')
   module logicAppAPIOperation 'Modules/apimOperation.azuredeploy.bicep' = [for operation in apimAPIOperations :{
     name: '${operation.name}-deploy'
     params: {
       parentName: '${apimInstance.name}/${logicAppAPI.name}'
       lgCallBackObject: listCallbackUrl(resourceId('Microsoft.Web/sites/hostruntime/webhooks/api/workflows/triggers', logicAppName, 'runtime', 'workflow', 'management', operation.lgWorkflowName, operation.lgWorkflowTrigger), '2022-09-01')
       operationDisplayName: operation.displayName
       operationMethod: operation.method
       operationName: operation.name
   
     }
   }]
   

Summary

The main benefit of using this method over constructing the API and Operations through Bicep is that we only need to define the backing API once.

If you would like to spin up a demo of this implementation or would like to use it as the basis of something you are working on, the source to all my work is in my GitHub repository along with a README that explains how to get started.

Have a go and see if this simplifies your Standard Logic App APIM Configurations.

Updated [31/01/2024]: See New Post showing methods of linking a Logic App Standard as a Backend to APIM through a Swagger Definition.

I have recently been reviewing the method in which a Logic App (Standard) workflow would be setup as an API in API Management. My aim is to overcome and simplify the limitation whereby directly importing a Logic App (Standard) workflow is not available, only in consumption.

After some exploration I believe I have identified a configurable and secure method in setting up the front-to-backend routing as can be seen in the diagram below:

The overall design aims to abstract the backend from the api operations, i.e. the backend points to the Logic App and the individual operations point to the respective workflows. The design also specifies granular access to the workflow Shared-Access-Signature (sig) held in the applications specific KeyVault (to see further details on this, see Azure RBAC Key Vault | Role Assignment for Specific Secret). Furthermore, the additional required parameters that are necessary to call a workflow have been implemented through APIM policies to remove the need for callers to understand backend implementation.

I have opted for Infrastructure as Code (IaC) as my method of implementation, specifically Bicep. I have broken down the implementation of the diagram above into two parts, Application Deployment, and API Deployment.

Application Deployment

The following diagram demonstrates how the application backend has been deployed.

The deployment is split into three stages:

1. Deploy the Core Application Components.
2. Deploy the Logic Workflows to the recently deployed Logic App.
3. Store the Workflow SAS keys in KeyVault for later secure use.

In turn the Bicep for step 1 is shown below:

/***************************************
Bicep Template: Application Core Deploy
***************************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('A prefix used to identify the application resources')
param applicationPrefixName string

@description('The name of the application used for tags')
param applicationName string

@description('The location that the resources will be deployed to - defaulting to the resource group location')
param location string = resourceGroup().location

@description('The environment that the resources are being deployed to')
@allowed([
  'dev'
  'test'
  'prod'
])
param env string = 'dev'

// ** Variables **
// ***************

var applicationKeyVaultName = '${applicationPrefixName}${env}kv'
var lgApplicationAppServicePlanName = '${applicationPrefixName}${env}asp'
var lgStorageAccountName = '${applicationPrefixName}${env}st'
var applicationLogicAppName = '${applicationPrefixName}${env}logic'

var isProduction = env == 'prod'

// ** Resources **
// ***************

@description('Deploy the Application Specific Key Vault')
resource applicationKeyVaultDeploy 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: applicationKeyVaultName
  location: location
  tags: {
    Application: applicationName
    Environment: env
    Version: deployment().properties.template.contentVersion
  }
  properties: {
    sku: {
      family: 'A'
      name: 'standard'
    }
    tenantId: tenant().tenantId
    enableRbacAuthorization: true
    enableSoftDelete: isProduction
  }
}

@description('Deploy the App Service Plan used for Logic App Standard')
resource lgAppServicePlanDeploy 'Microsoft.Web/serverfarms@2022-09-01' = {
  name: lgApplicationAppServicePlanName
  location: location
  tags: {
    Application: applicationName
    Environment: env
    Version: deployment().properties.template.contentVersion
  }
  kind: 'elastic'
  sku: {
    name: 'WS1'
    tier: 'WorkflowStandard'
    size: 'WS1'
    family: 'WS'
    capacity: 1
  }
}

@description('Deploy the Storage Account used for Logic App Standard')
resource lgStorageAccountDeploy 'Microsoft.Storage/storageAccounts@2023-01-01' = {
  name: lgStorageAccountName
  location: location
  tags: {
    Application: applicationName
    Environment: env
    Version: deployment().properties.template.contentVersion
  }
  sku: {
    name: 'Standard_LRS'
  }
  kind: 'StorageV2'
  properties: {
    supportsHttpsTrafficOnly: true
    minimumTlsVersion: 'TLS1_2'
    defaultToOAuthAuthentication: true
  }
}

@description('Deploy the Application Standard Logic App')
resource applicationLogicAppStandardDeploy 'Microsoft.Web/sites@2022-09-01' = {
  name: applicationLogicAppName
  location: location
  tags: {
    Application: applicationName
    Environment: env
    Version: deployment().properties.template.contentVersion
  }
  kind: 'functionapp,workflowapp'
  properties: {
    serverFarmId: lgAppServicePlanDeploy.id
    publicNetworkAccess: 'Enabled'
    httpsOnly: true
  }
  resource config 'config@2022-09-01' = {
    name: 'appsettings'
    properties: {
      FUNCTIONS_EXTENSION_VERSION: '~4'
      FUNCTIONS_WORKER_RUNTIME: 'node'
      WEBSITE_NODE_DEFAULT_VERSION: '~18'
      AzureWebJobsStorage: 'DefaultEndpointsProtocol=https;AccountName=${lgStorageAccountDeploy.name};AccountKey=${listKeys(lgStorageAccountDeploy.id, '2019-06-01').keys[0].value};EndpointSuffix=core.windows.net'
      WEBSITE_CONTENTAZUREFILECONNECTIONSTRING: 'DefaultEndpointsProtocol=https;AccountName=${lgStorageAccountDeploy.name};AccountKey=${listKeys(lgStorageAccountDeploy.id, '2019-06-01').keys[0].value};EndpointSuffix=core.windows.net'
      WEBSITE_CONTENTSHARE: lgStorageAccountDeploy.name
      AzureFunctionsJobHost__extensionBundle__id: 'Microsoft.Azure.Functions.ExtensionBundle.Workflows'
      AzureFunctionsJobHost__extensionBundle__version: '${'[1.*,'}${' 2.0.0)'}'
      APP_KIND: 'workflowApp'
    }
  }
}

// ** Outputs **
// *************

output keyVaultName string = applicationKeyVaultName
output applicationLogicAppName string  = applicationLogicAppName

Step 2 is the deployment of the workflow definition such as this very simple request response:

{
    "definition": {
        "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
        "actions": {
            "Response": {
                "type": "Response",
                "kind": "Http",
                "inputs": {
                    "statusCode": 200
                },
                "runAfter": {}
            }
        },
        "contentVersion": "1.0.0.0",
        "outputs": {},
        "triggers": {
            "When_a_HTTP_request_is_received": {
                "type": "Request",
                "kind": "Http"
            }
        }
    },
    "kind": "Stateless"
}

Step 3 demonstrated below takes a number of workflows, retrieves their SAS keys and creates them as secrets in the Application KeyVault.

/*****************************************
Bicep Template: Application Secrets Deploy
*****************************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('Name of the Logic App to place workflow(s) sig into KeyVault')
param applicationLogicAppName string

@description('Name of the Key Vault to place secrets into')
param keyVaultName string

@description('Array of Workflows to obtain sigs from.')
param workflows array = [
  {
    workflowName: ''
    workflowTrigger: ''
  }
]

// ** Variables **
// ***************



// ** Resources **
// ***************

@description('Retrieve the existing Logic App')
resource logicApp 'Microsoft.Web/sites@2022-09-01' existing = {
  name: applicationLogicAppName
}

@description('Retrieve the existing Key Vault instance to store secrets')
resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
  name: keyVaultName
}

@description('Vault the Logic App workflow sig as a secret - Deployment principle requires RBAC permissions to do this')
resource vaultLogicAppKey 'Microsoft.KeyVault/vaults/secrets@2023-07-01' = [for workflow in workflows: {
  name: '${logicApp.name}-${workflow.workflowName}-sig'
  parent: keyVault
  tags: {
    ResourceType: 'LogicAppStandard'
    ResourceName: logicApp.name
  }
  properties: {
    contentType: 'string'
    value: listCallbackUrl(resourceId('Microsoft.Web/sites/hostruntime/webhooks/api/workflows/triggers', logicApp.name, 'runtime', 'workflow', 'management', workflow.workflowName, workflow.workflowTrigger), '2022-09-01').queries.sig
  }
}]

// ** Outputs **
// *************

API Deployment

The following diagram demonstrates how API Management and the Logic App backend API have been deployed.

The deployment is split into two stages:

1. Deploy an API Management Service Instance.
2. Deploy respective Backend, API, API Operations, and Policies.

Our deployment of the API and its operations pointing at the Standard Logic App requires the following components:

1. Azure Role Assignment - This is the authorisation system that we will use to assign APIMs System Assigned Managed Identity access to the applications Key Vault, specifically the sig secret.
2. APIM API and API Operations - Represents a set of available operations with each containing a reference to a backend service that implements the API.
3. APIM Named Values - This is a global collection of name/value pairs within the APIM Instance. Using APIM Policies we can use Named Values to further API configuration. Named Values can store constant string values, secrets, or more importantly Key Vault references to secrets.
4. APIM Backend - APIM Backend is an HTTP service that implements a front-end API. Normally with consumption Logic Apps when imported into APIM a Backend Service is automatically created for you. This is not currently possible with Standard Logic Apps. However, Standard Logic Apps have the same foundations as Azure Functions which means that we can set this up through custom backends (i.e. is treated as a Function Backend).
   • Setting up the Backend means that we can abstract backend service information, promoting reusability and improved governance.
5. APIM Policies - Policies are statements that are run sequentially on a given request or response for an API. These statements further our ability to configure the API and its abilities such as adding further parameters, setting a backend, making use of configured Named Values.

The Bicep for step 1 is shown below:

/**********************************
Bicep Template: APIM Instance Deploy
***********************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('A prefix used to identify the api resources')
param apiPrefixName string

@description('The location that the resources will be deployed to - defaulting to the resource group location')
param location string = resourceGroup().location

@description('The environment that the resources are being deployed to')
@allowed([
  'dev'
  'test'
  'prod'
])
param env string = 'dev'

@description('The apim publisher email')
param apimPublisherEmail string

@description('The apim publisher name')
param apimPublisherName string

// ** Variables **
// ***************

var apimInstanceName = '${apiPrefixName}${env}apim'

// ** Resources **
// ***************

@description('Deployment of the APIM instance')
resource apimInstanceDeploy 'Microsoft.ApiManagement/service@2022-08-01' = {
  name: apimInstanceName
  location: location
  tags: {
    Environment: env
    Version: deployment().properties.template.contentVersion
  }
  sku: {
    capacity: 0
    name: 'Consumption'
  }
  properties: {
    publisherEmail: apimPublisherEmail
    publisherName: apimPublisherName
  }
  identity: {
    type: 'SystemAssigned'
  }
}

// ** Outputs **
// *************

output apimInstanceName string = apimInstanceName

The Bicep for step 2 makes use of module deployments and policies loaded as text into variables. The Main deployment template is shown below:

/******************************************
Bicep Template: Logic App Standard APIM API
*******************************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('Name of the Logic App to add as a backend')
param logicAppName string

@description('Name of the APIM instance')
param apimInstanceName string

@description('Name of the Key Vault instance')
param keyVaultName string

@description('Name of the API to create in APIM')
param apiName string

@description('APIM API path')
param apimAPIPath string

@description('APIM API display name')
param apimAPIDisplayName string

@description('Array of API operations')
param apimAPIOperations array = [
  {
    name: ''
    displayName: ''
    method: ''
    lgWorkflowName: ''
    lgWorkflowTrigger: ''
  }
]

// ** Variables **
// ***************

// Logic App Base URL
var lgBaseUrl = 'https://${logicApp.properties.defaultHostName}/api'

// Key Vault Read Access
var keyVaultSecretsUserRoleDefinitionId = '4633458b-17de-408a-b874-0445c86b69e6'

// All Operations Policy
var apimAPIPolicyRaw = loadTextContent('./APIM-Policies/APIMAllOperationsPolicy.xml')
var apimAPIPolicy = replace(apimAPIPolicyRaw, '__apiName__', apiName)

// Operation Policy Template
var apimOperationPolicyRaw = loadTextContent('./APIM-Policies/APIMOperationPolicy.xml')

// ** Resources **
// ***************

@description('Retrieve the existing APIM Instance, will add APIs and Policies to this resource')
resource apimInstance 'Microsoft.ApiManagement/service@2022-08-01' existing = {
  name: apimInstanceName
}

@description('Create the Logic App API in APIM')
resource logicAppAPI 'Microsoft.ApiManagement/service/apis@2022-08-01' = {
  name: apiName
  parent: apimInstance
  properties: {
    displayName: apimAPIDisplayName
    subscriptionRequired: true
    path: apimAPIPath
    protocols: [
      'https'
    ]
  }
}

@description('Retrieve the existing Logic App for linking as a backend')
resource logicApp 'Microsoft.Web/sites@2022-09-01' existing = {
  name: logicAppName
}

@description('Deploy logic App API operation')
module logicAppAPIOperation 'Modules/apimOperation.azuredeploy.bicep' = [for operation in apimAPIOperations :{
  name: '${operation.name}-deploy'
  params: {
    parentName: '${apimInstance.name}/${logicAppAPI.name}'
    lgCallBackObject: listCallbackUrl(resourceId('Microsoft.Web/sites/hostruntime/webhooks/api/workflows/triggers', logicAppName, 'runtime', 'workflow', 'management', operation.lgWorkflowName, operation.lgWorkflowTrigger), '2022-09-01')
    operationDisplayName: operation.displayName
    operationMethod: operation.method
    operationName: operation.name

  }
}]

@description('Retrieve the existing application Key Vault instance')
resource keyVault 'Microsoft.KeyVault/vaults@2023-07-01' existing = {
  name: keyVaultName
}

@description('Retrieve the existing logicapp workflow sig secret')
resource vaultLogicAppKey 'Microsoft.KeyVault/vaults/secrets@2023-07-01' existing = [for operation in apimAPIOperations: {
  name: '${logicAppName}-${operation.lgWorkflowName}-sig'
  parent: keyVault
}]

@description('Grant APIM Key Vault Reader for the logic app API key secret')
resource grantAPIMPermissionsToSecret 'Microsoft.Authorization/roleAssignments@2022-04-01' = [for (operation, index) in apimAPIOperations: {
  name: guid(keyVaultSecretsUserRoleDefinitionId, keyVault.id, operation.lgWorkflowName)
  scope: vaultLogicAppKey[index]
  properties: {
    roleDefinitionId: subscriptionResourceId('Microsoft.Authorization/roleDefinitions', keyVaultSecretsUserRoleDefinitionId)
    principalId: apimInstance.identity.principalId
    principalType: 'ServicePrincipal'
  }
}]

@description('Create the named values for the logic app API sigs')
resource logicAppBackendNamedValues 'Microsoft.ApiManagement/service/namedValues@2022-08-01' = [for (operation, index) in apimAPIOperations: {
  name: '${apiName}-${operation.name}-sig'
  parent: apimInstance
  properties: {
    displayName: '${apiName}-${operation.name}-sig'
    tags: [
      'sig'
      'logicApp'
      '${apiName}'
      '${operation.name}'
    ]
    secret: true
    keyVault: {
      identityClientId: null
      secretIdentifier: '${keyVault.properties.vaultUri}secrets/${vaultLogicAppKey[index].name}'
    }
  }
  dependsOn: [
    grantAPIMPermissionsToSecret
  ]
}]

@description('Create the backend for the Logic App API')
resource logicAppBackend 'Microsoft.ApiManagement/service/backends@2022-08-01' = {
  name: apiName
  parent: apimInstance
  properties: {
    protocol: 'http'
    url: lgBaseUrl
    resourceId: uri(environment().resourceManager, logicApp.id)
    tls: {
      validateCertificateChain: true
      validateCertificateName: true
    }
  }
}

@description('Create a policy for the logic App API and all its operations - linking the logic app backend')
resource logicAppAPIAllOperationsPolicy 'Microsoft.ApiManagement/service/apis/policies@2022-08-01' = {
  name: 'policy'
  parent: logicAppAPI
  properties: {
    value: apimAPIPolicy
    format: 'xml'
  }
  dependsOn: [
    logicAppBackend
  ]
}

@description('Add query strings via policy')
module operationPolicy './Modules/apimOperationPolicy.azuredeploy.bicep' = [for (operation, index) in apimAPIOperations: {
  name: 'operationPolicy-${operation.name}'
  params: {
    parentStructureForName: '${apimInstance.name}/${logicAppAPI.name}/${operation.name}'
    rawPolicy: apimOperationPolicyRaw
    apiVersion: listCallbackUrl(resourceId('Microsoft.Web/sites/hostruntime/webhooks/api/workflows/triggers', logicAppName, 'runtime', 'workflow', 'management', operation.lgWorkflowName, operation.lgWorkflowTrigger), '2022-09-01').queries['api-version']
    sp: listCallbackUrl(resourceId('Microsoft.Web/sites/hostruntime/webhooks/api/workflows/triggers', logicAppName, 'runtime', 'workflow', 'management', operation.lgWorkflowName, operation.lgWorkflowTrigger), '2022-09-01').queries.sp
    sv: listCallbackUrl(resourceId('Microsoft.Web/sites/hostruntime/webhooks/api/workflows/triggers', logicAppName, 'runtime', 'workflow', 'management', operation.lgWorkflowName, operation.lgWorkflowTrigger), '2022-09-01').queries.sv
    sig: '{{${apiName}-${operation.name}-sig}}'
  }
  dependsOn: [
    logicAppAPIOperation
  ]
}]

// ** Outputs **
// *************

The APIM All Operations Policy template is as follows:

The Deletion Set Header is used to remove subscription key headers from the forwarded request to the backend. For more information see Azure API Management | Unintentional Pass through of Subscription Key Header.

<!-- API ALL OPERATIONS SCOPE -->
<policies>
    <inbound>
        <base />
        <set-backend-service id="logicapp-backend-policy" backend-id="__apiName__" />
        <set-header name="Ocp-Apim-Subscription-Key" exists-action="delete" />
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

The APIM Operation Policy template is as follows:

By setting the parameters as policy means that those calling the API do not need to be aware of backend configuration. Thus allowing for complete separation of concerns.

<!-- API OPERATION SCOPE -->
<policies>
    <inbound>
        <base />
        <set-query-parameter name="api-version" exists-action="append">
            <value>__api-version__</value>
        </set-query-parameter>
        <set-query-parameter name="sp" exists-action="append">
            <value>__sp__</value>
        </set-query-parameter>
        <set-query-parameter name="sv" exists-action="append">
            <value>__sv__</value>
        </set-query-parameter>
        <set-query-parameter name="sig" exists-action="append">
            <value>__sig__</value>
        </set-query-parameter>
    </inbound>
    <backend>
        <base />
    </backend>
    <outbound>
        <base />
    </outbound>
    <on-error>
        <base />
    </on-error>
</policies>

The API Operation Module deployment is as follows:

/**********************************
Bicep Template: API Operation Deploy
***********************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('API Management Service API Name Path')
param parentName string

@description('Name of the API Operation')
param operationName string

@description('Display name for the API operation')
param operationDisplayName string

@description('API Operation Method e.g. GET')
param operationMethod string

@description('Logic App Call Back object containing URL and other details')
param lgCallBackObject object

// ** Variables **
// ***************

var operationUrlBase = split(split(lgCallBackObject.value, '?')[0], '/api')[1]
var hasRelativePath = lgCallBackObject.?relativePath != null ? true : false
var pathParametersList = hasRelativePath ? lgCallBackObject.relativePathParameters : []
var pathParameters = [for pathParameter in pathParametersList: {
    name: pathParameter
    type: 'string'
}]
var RelativePathHasBeginingSlash = hasRelativePath ? first(lgCallBackObject.relativePath) == '/' : false
var operationUrl = hasRelativePath && RelativePathHasBeginingSlash ? '${operationUrlBase}${lgCallBackObject.relativePath}' : hasRelativePath && !RelativePathHasBeginingSlash ? '${operationUrlBase}/${lgCallBackObject.relativePath}' : operationUrlBase

// ** Resources **
// ***************

@description('Deploy logic App API operation')
resource logicAppAPIGetOperation 'Microsoft.ApiManagement/service/apis/operations@2022-08-01' = {
  name: '${parentName}/${operationName}'
  properties: {
    displayName: operationDisplayName
    method: operationMethod
    urlTemplate: operationUrl
    templateParameters: hasRelativePath ? pathParameters : null
  }
}

// ** Outputs **
// *************

The API Operation Policy Module Deployment is as follows:

/********************************************
Bicep Template: APIM LG API Operation Policy
********************************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('The Parent naming structure for the Policy')
param parentStructureForName string

@description('The raw policy document template')
param rawPolicy string

@description('The Logic App service API version')
param apiVersion string

@description('The Logic App workflow permissions')
param sp string

@description('The Logic App workflow version number of the query parameters')
param sv string

@description('The named value name for the workflow sig')
param sig string

// ** Variables **
// ***************

var policyApiVersion = replace(rawPolicy, '__api-version__', apiVersion)
var policySP = replace(policyApiVersion, '__sp__', sp)
var policySV = replace(policySP, '__sv__', sv)
var policySIG = replace(policySV, '__sig__', sig)


// ** Resources **
// ***************

@description('Add query strings via policy')
resource operationPolicy 'Microsoft.ApiManagement/service/apis/operations/policies@2022-08-01' = {
  name: '${parentStructureForName}/policy'
  properties: {
    value: policySIG
    format: 'xml'
  }
}

// ** Outputs **
// *************

Have a go and see if this simplifies your Standard Logic App APIM Configurations.

Azure Logic Apps is an Azure Integration Service (AIS) that provides you the ability to create and run automated workflows with little to no code. Consumption Logic Apps are developed using the visual designer within the Azure Portal.

If you are new to developing Azure Logic Apps, there is great Microsoft Learning material to get you started:

• What are Azure Logic Apps | https://learn.microsoft.com/en-us/azure/logic-apps/logic-apps-overview
• Introduction to Azure Logic Apps | https://learn.microsoft.com/en-us/training/modules/intro-to-logic-apps/
• Quickstart: Create an integration workflow | https://learn.microsoft.com/en-us/azure/logic-apps/quickstart-create-first-logic-app-workflow

Problem Space

Once you have created your workflow in the Logic App designer, your next question may be:

How do I consistently deploy the Logic App with my developed workflow?

We are going to be looking at conducting our deployment with ARM and Bicep templates.

ARM templates are a declarative way of defining Azure service configurations in code. When deploying services to Azure using ARM templates that are under source control and therefore in step with product development, are by far the best approach. The Azure services can be defined in a single template and that template can be used to deploy multiple copies of the system, either for dev/test purposes or to provision live instances for multiple customers in a reliable and predictable manner.

Bicep¹ is a transparent abstraction over ARM template JSON and doesn’t lose any of the JSON template capabilities. Bicep templates will be compiled into ARM templates.

ARM Template Deployments

Following the Microsoft guide² for both building an Azure Logic App using ARM templates and including the Logic Apps definition, you will likely end up with the following development process:

1. Develop and Deploy a Basic Logic App ARM template:

Remember to add the template to your Source Control

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "logicAppName": {
            "type": "String"
        },
        "location": {
            "type": "String"
        }
    },
    "variables": {},
    "resources": [
        {
            "type": "Microsoft.Logic/workflows",
            "apiVersion": "2019-05-01",
            "name": "[parameters('logicAppName')]",
            "location": "[parameters('location')]",
            "properties": {
                "definition": {},
                "parameters": {}
            }
        }
    ]
}

2. Develop a workflow in the deployed Logic App Portal Designer:
3. Obtain the workflow definition from Code view:
4. Copy the workflow definition from the Portal into your Logic App ARM Template:

Make sure to parametrise fields within your workflow using the ARM Parameter syntax

{
    "$schema": "https://schema.management.azure.com/schemas/2019-04-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "logicAppName": {
            "type": "String"
        },
        "location": {
            "type": "String"
        },
        "interval": {
            "type": "int"
        }
    },
    "variables": {},
    "resources": [
        {
            "type": "Microsoft.Logic/workflows",
            "apiVersion": "2019-05-01",
            "name": "[parameters('logicAppName')]",
            "location": "[parameters('location')]",
            "properties": {
                "definition": {
                    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
                    "actions": {
                        "Condition_-_Morning_or_Afternoon": {
                            "actions": {
                                "Terminate_-_Afternoon": {
                                    "inputs": {
                                        "runStatus": "Succeeded"
                                    },
                                    "runAfter": {},
                                    "type": "Terminate"
                                }
                            },
                            "else": {
                                "actions": {
                                    "Terminate_-_Morning": {
                                        "inputs": {
                                            "runStatus": "Succeeded"
                                        },
                                        "runAfter": {},
                                        "type": "Terminate"
                                    }
                                }
                            },
                            "expression": {
                                "and": [
                                    {
                                        "greaterOrEquals": [
                                            "@utcNow('H:mm:ss')",
                                            "12:00:00"
                                        ]
                                    }
                                ]
                            },
                            "runAfter": {},
                            "type": "If"
                        }
                    },
                    "contentVersion": "1.0.0.0",
                    "outputs": {},
                    "parameters": {},
                    "triggers": {
                        "Recurrence_-_Start": {
                            "evaluatedRecurrence": {
                                "frequency": "Day",
                                "interval": 1,
                                "schedule": {
                                    "hours": [
                                        "11"
                                    ]
                                }
                            },
                            "recurrence": {
                                "frequency": "Hour",
                                "interval": "[parameters('interval')]"
                            },
                            "type": "Recurrence"
                        }
                    }
                },
                "parameters": {}
            }
        }
    ]
}

5. Any changes to the workflow in the Azure Portal Designer are to be reflected in your ARM Template that is in Source Control. You can use source control change tooling to see the diff between current and latest, this can help you retain parameterized values that you have previously included.

Bicep Template Deployment

Generating Logic App ARM Templates from Bicep is possible but has a different approach. Bicep is not written in Json as ARM is, and therefore you cannot simply copy the Json workflow definition into the Logic App deployment resource.

Following the example given by Microsoft³, their method is to write out the definition using the Bicep syntax and replace property values with Bicep properties as you would with ARM. This approach however does not adapt well to change, nor is it an easy task to bring the workflow definition across from the portal. Having to convert the workflow to Bicep syntax every time is simply a pain.

That said, hope is not lost.

Bicep has some built in functions that will allow us to retain a similar development process, such that:

We will still run through steps 1, 2, and 3 as we have done for ARM, but this time with Bicep.

/************************
Logic App Template Bicep
**************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('Logic App Name')
param logicAppName string

@description('The location that the resource will be deployed to')
param location string

// ** Variables **
// ***************

// ** Resources **
// ***************

resource logicAppDeployment 'Microsoft.Logic/workflows@2022-10-01' = {
  name: logicAppName
  location: location
  properties: {
    definition: {}
    parameters: {}
    state: 'Enabled'
  }
}

// ** Outputs **
// *************

output LogicAppName string = logicAppName

4. Rather than copying the workflow definition into the Bicep template, copy the definition into a new Json file in your source control repository.

5. As you do not have access to your Bicep Parameters, any values that need parametrising will need to be replaced with tokens that will be replaced by the Bicep Template. For instance, **interval**.

6. Next we will load our workflow definition into the template, conduct token replacement with Parameter values, and then assign the definition and parameters to the Logic App Resource.

   The Bicep Functions that we will be using to conduct these activities are:

   • loadTextContent | Loads the content of the specified file as a string. | https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/bicep-functions-files#loadtextcontent
   • replace | Returns a new string with all instances of one string replaced by another string. | https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/bicep-functions-string#replace
   • json | Converts a valid JSON string into a JSON data type. | https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/bicep-functions-object#json

   See the Example Below:

/************************
Logic App Template Bicep
**************************/

targetScope = 'resourceGroup'

// ** Parameters **
// ****************

@description('Logic App Name')
param logicAppName string

@description('The location that the resource will be deployed to')
param location string

@description('Trigger Interval')
param interval int

// ** Variables **
// ***************

var logicAppDefinition = loadTextContent('./Definition.json') // Load our definition into a string variable
var logicAppReplacementParameter = replace(logicAppDefinition, '**interval**', interval) // Replace tokens with our parameters
var logicAppDefinitionJson = json(logicAppReplacementParameter) // Retrieve the Json object from the Json String so we can access specific data when assigning

// ** Resources **
// ***************

resource logicAppDeployment 'Microsoft.Logic/workflows@2022-10-01' = {
  name: logicAppName
  location: location
  properties: {
    definition: logicAppDefinitionJson.definition // Set the definition
    parameters: logicAppDefinitionJson.parameters // Set any Properties that may be set
  }
}

// ** Outputs **
// *************

output LogicAppName string = logicAppName

7. As with the ARM templates, any changes to the workflow in the Azure Portal Designer are to be reflected in your Json Workflow file that is in Source Control. You can use source control change tooling to see the diff between current and latest, this can help you retain tokenised values that you have previously included.

Take Note When

• Special point of care should be taken if your logic app is using xpath expressions, proper concatenation/interpolation of the quotes can be a nightmare.
• Bicep loadTextContent has size limits: The maximum allowed size of the file is 96 Kb.
  • If you are meeting these size limits for your workflows, this may be an indication that you need to split your workflow up.

Summary

Whether you choose to build your resource deployment templates with ARM or Bicep, both options as shown will provide you a development process where you can keep your low code consumption Logic App not only in source control, but have a reliable deployment template that will allow you to create your Logic App when and where ever you wish.

I have recently encountered an interesting problem space with Azure logic app action run after logic. I ran into the problem whilst creating a logic app that will perform actions in parallel. The bulk of the actions are performed in scopes. If an action fails within the first set of scopes, the scope status is Failed. If the first scope fails, then the second scope full of actions are executed (this based on run after logic). The problem with this is that I still need the logic app to terminate as Failed so that an alert will be fired off.

Assumed fix one

To fix this, I assumed that I could place a terminate action after the parallel actions conclude with run after logic Succeeded. Thus being, if the second scope on either branch has succeeded, then the terminate failed action runs.

This logic can be seen in the diagram shown below:

How this actually turns out is that both parallel first scopes will have to have failed and the second scopes have run for the terminate condition to run. Thus, if using run after logic to assess if an action after a parallel stream should run will only work in an AND logic case.

i.e

Both second scopes have succeeded, or both second scopes have failed etc.

Not if scope 2.2 succeeded or if scope 3.2 succeeded.

Assumed fix two

After validating the run after logic of the first assumed fix, I then experimented with placing a terminate failed action at the end of each parallel stream with the same run after condition. As you would expect, the major problem with this is that if the one parallel stream fails first, the other stream will be skipped mid execution. Clearly not fixing the problem. This can be seen in the diagram below:

Actual Fix

The actual fix for this is not one you would naturally come to. Based on Microsoft Documentation we need to evaluate the scopes result status within a conditional action, then conduct the actions based on that result. Within the condition action, we can use either and/or logic as required. The expression to retrieve the scopes run status is as follows:

result('Scope')[0]['status']

This solution allows us to retrieve individual scope run status and evaluate at the end of the parallel stream. Based on either 2.1 or 3.1 scopes failing, we can then run our failed termination, else allow logic app to succeed.

Bear in mind that for this to work, the conditional after the parallel stream needs to have all run after types set so that the conditional runs regardless. This can be seen in the diagram below: