Azure Logic Apps Workflows

Azure Logic Apps is a cloud-based platform for creating and running automated workflows that integrate apps, data, services, and systems. It is designed to solve the problem of connecting disparate systems without writing complex integration code. Logic Apps provides a visual designer and hundreds of prebuilt connectors to services like Office 365, SQL Server, Salesforce, and Azure services. Workflows are defined declaratively using a JSON-based workflow definition language (Workflow Definition Language) and are executed by the Azure Logic Apps runtime.

For the AZ-104 exam, you need to know that Logic Apps is a serverless compute option (though it can also run in an integration service environment). It is billed based on execution and connector usage, not on pre-provisioned VMs. This makes it cost-effective for sporadic workloads.

A Logic App workflow consists of two main parts: triggers and actions. The trigger is the event that starts the workflow. Actions are the steps that run after the trigger fires. The workflow engine orchestrates the execution, handling state, retries, and error handling.

Trigger Types:

The trigger has a state that determines whether it has fired. For polling triggers, the state includes a timestamp of the last check. The trigger's recurrence interval is configurable (minimum 1 second for some connectors, but typically 1 minute for polling).

Actions:

Each action is a step that performs an operation, such as calling an API, transforming data, or sending an email. Actions can be:

Actions can be sequential, parallel, or conditional using loops, conditions, and switches.

Workflow Execution:

When a trigger fires, the Logic Apps runtime creates a workflow run instance. The run executes each action in the defined order (or in parallel if specified). The runtime manages:

Workflow Definition Language (WDL):

The workflow is defined in JSON. A simplified example:

{
    "definition": {
        "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
        "actions": {
            "Send_an_email": {
                "inputs": {
                    "body": {
                        "Content": "Order received: @{triggerBody()?['OrderID']}",
                        "Subject": "New Order"
                    },
                    "host": {
                        "connection": {
                            "name": "@parameters('$connections')['office365']['connectionId']"
                        }
                    },
                    "method": "post",
                    "path": "/v2/Mail"
                },
                "runAfter": {},
                "type": "ApiConnection"
            }
        },
        "contentVersion": "1.0.0.0",
        "outputs": {},
        "parameters": {
            "$connections": {
                "defaultValue": {},
                "type": "Object"
            }
        },
        "triggers": {
            "When_a_HTTP_request_is_received": {
                "inputs": {
                    "schema": {}
                },
                "kind": "Http",
                "type": "Request"
            }
        }
    },
    "parameters": {}
}

You can create and manage Logic Apps using Azure Portal, Azure CLI, PowerShell, or ARM templates.

Azure CLI example:

# Create a resource group
az group create --name MyResourceGroup --location westus

# Create a Logic App (consumption plan)
az logic workflow create --resource-group MyResourceGroup --location westus --name MyLogicApp --definition "path_to_definition.json"

# List all Logic Apps in a resource group
az logic workflow list --resource-group MyResourceGroup --output table

# Trigger a run
az logic workflow trigger --resource-group MyResourceGroup --name MyLogicApp --trigger-name manual

# View run history
az logic workflow run list --resource-group MyResourceGroup --name MyLogicApp --output table

AZ-104 exam objective 3.3 includes implementing Logic Apps workflows. You should be able to:

Common wrong answers: Selecting Azure Functions when the scenario requires no-code integration; confusing Logic Apps with Power Automate (Power Automate is for Microsoft 365 scenarios, Logic Apps for enterprise integration).

Scenario 1: Order Processing in E-commerce

A company uses an on-premises ERP system and wants to automatically send order confirmations and update inventory when orders are placed through a web app. They deploy a Logic App with an HTTP trigger (webhook) that receives order JSON from the web app. The Logic App then: 1) Validates the order using a custom connector to the ERP, 2) Sends a confirmation email via Office 365, 3) Posts a message to a Service Bus queue for inventory update. In production, they handle peak loads (thousands of orders per hour) by using a Standard Logic App (higher throughput) and setting retry policies for transient failures. Misconfiguration often occurs when the HTTP trigger schema does not match the incoming payload, causing parse errors. They use run history and Application Insights to monitor failures.

Scenario 2: Automated Approval Workflow

A finance department needs a system for expense report approvals. When an employee submits an expense report in SharePoint, a Logic App triggers on new item creation. The workflow sends an approval email to the manager using the 'Send approval email' action (which uses Office 365). The manager can approve or reject via email. Based on the response, the Logic App updates the SharePoint item status and sends a notification to the employee. In production, they handle hundreds of reports per day. A common issue is that the email approval action requires the manager to reply with a specific format; if the reply is not recognized, the workflow times out. They mitigate this by adding a timeout and fallback action to escalate.

Scenario 3: IoT Data Processing

A manufacturing company collects sensor data from machines via Azure IoT Hub. They want to process alerts when temperature exceeds a threshold. A Logic App triggers on IoT Hub events (via Event Grid). The workflow parses the message, checks the temperature, and if above threshold, sends an SMS via Twilio connector and logs the event to Azure Table Storage. In production, they have thousands of devices sending data every minute. They use a Consumption plan with high concurrency (default 100 concurrent runs) but had to request an increase to 500 due to spikes. Misconfiguration: forgetting to set a retry policy on the SMS action caused missed alerts when the SMS provider was temporarily unavailable.