Logic Apps: System Assigned Identity and Source Control

Introduction

Azure Logic Apps provide a powerful alternative to Power Automate for building workflows and integrations in the cloud. While both tools share similarities, Logic Apps offer unique advantages, especially for enterprise-scale solutions. However, managing Logic Apps in source control and deploying them via Azure DevOps pipelines comes with its own set of challenges.

This blog post explores the differences between Logic Apps and Power Automate, highlights the limitations of Logic Apps in source control, and provides insights into handling system-assigned identities and API versions during deployment.

Key Differences Between Logic Apps and Power Automate

While Logic Apps and Power Automate share a similar purpose, they differ in several key areas:

  1. Ownership:

    • Logic Apps are owned and managed within Azure, making them ideal for enterprise-grade workflows.
    • Power Automate is part of the Microsoft 365 ecosystem and is more user-friendly for business users.

  2. Cost:

    • Logic Apps treat premium actions as standard actions, making them more cost-effective for workflows requiring premium connectors.
    • Power Automate charges extra for premium actions.

  3. Scalability:

    • Logic Apps are designed for high-scale workflows and can handle enterprise-level integrations.

  4. History Retention:

    • Logic Apps retain history for more than 30 days by default (90 days) and can be extended further.
    • Power Automate has a shorter history retention period.

For more details, refer to the Azure Logic Apps Limits and Configuration Guide.

Challenges with Logic Apps and Source Control

Unlike Power Automate, Logic Apps do not have the concept of “solutions” for deployment via Azure DevOps pipelines. However, the Azure Logic Apps Visual Studio Code Extension provides a way to export Logic Apps and generate Azure DevOps pipeline definitions for local projects.

Azure Logic Apps Extension

Limitations of the Visual Studio Code Extension

  1. System Assigned Identity:

    • The extension does not include the SystemAssigned identity property by default. This property must be added manually to the exported ARM template.

  2. API Version:

    • The API version is set to a default value (2019-05-01) with no option to modify it during export.

Adding System Assigned Identity and API Version

When exporting Logic Apps using the Visual Studio Code extension, you may need to manually update the ARM template to include the SystemAssigned identity and ensure the correct API version is used. This is because the system assigned property is not automatically added and the apiversion is defaulted with no option. Below is an example of the required JSON configuration:

{
  "apiVersion": "2019-05-01",
  "dependsOn": [],
  "location": "uksouth",
  "name": "[parameters('test_workflow')]",
  "identity": {
    "type": "SystemAssigned"
  }
}

Steps to Update the ARM Template

  1. Open the exported ARM template in your preferred editor.
  2. Locate the Logic App definition.
  3. Add the identity property with "type": "SystemAssigned".
  4. Verify the apiVersion is correct and update it if necessary.

Using the Azure Logic Apps Visual Studio Code Extension

The Azure Logic Apps Visual Studio Code Extension simplifies the process of exporting Logic Apps for source control. It includes features such as:

  • Exporting Logic Apps to a local project.
  • Generating Azure DevOps pipeline definitions.

However, as mentioned earlier, manual updates are required to include system-assigned identities and ensure the correct API versions are used.

Conclusion

By addressing these limitations, you can effectively manage Logic Apps in source control and deploy them seamlessly using Azure DevOps pipelines.

References

Azure Logic Apps Limits and Configuration Guide Logic Apps and Source Control (with PowerShell)