This chapter covers Azure Logic Apps as a key integration technology for the AZ-305 exam. Azure Logic Apps enables you to build automated workflows that integrate apps, data, and services across cloud and on-premises environments. Expect 5-10% of exam questions to touch on integration services, with Logic Apps being a primary focus for scenarios involving SaaS connectors, enterprise messaging, and business process automation. Mastery of Logic Apps is essential for designing reliable, scalable integration solutions in Azure.
Jump to a section
Imagine a large corporate mailroom that receives thousands of letters, packages, and interoffice envelopes daily. The mailroom is not a single person but a system of conveyor belts, sorting machines, and workers that process items based on rules. A letter arrives with a barcode; the scanner reads it and routes the letter to the correct bin. If the barcode is missing, a worker opens the envelope, reads the address, and writes a new barcode. If the address is incomplete, the worker looks up the employee directory to fill in the missing details. The mailroom can also initiate actions: when a package arrives, it triggers a notification to the recipient via email. The entire process is automated, with each step defined by a workflow. If a step fails (e.g., the directory lookup times out after 30 seconds), the mailroom can retry twice, then escalate to a supervisor. This mailroom is Azure Logic Apps: it receives triggers (incoming mail), applies conditions (barcode present?), transforms data (write barcode), calls external services (directory), and handles errors. Just as the mailroom integrates physical mail streams, Logic Apps integrates cloud services, on-premises systems, and SaaS applications using connectors. The workflow is defined declaratively in a designer, and the runtime engine executes each step sequentially or in parallel, with built-in retry policies and monitoring.
What is Azure Logic Apps?
Azure Logic Apps is a cloud-based platform for creating and running automated workflows that integrate applications, data, systems, and services. It follows a declarative model: you define the workflow's trigger, conditions, actions, and error handling using a visual designer or JSON definition. Logic Apps is part of Azure Integration Services, alongside API Management, Service Bus, and Event Grid. It is designed for enterprise integration patterns (EIPs) such as content-based routing, scatter-gather, and claim check.
Why Logic Apps Exists
Before Logic Apps, developers had to write custom code to connect disparate systems. This approach was time-consuming, brittle, and hard to maintain. Logic Apps provides over 400 prebuilt connectors for popular services (Office 365, Salesforce, SQL Server, etc.), reducing development effort. It also offers built-in enterprise-grade features: retry policies, state management, monitoring, and security. The exam focuses on when to use Logic Apps versus other integration options (Azure Functions, Service Bus, Event Grid).
How Logic Apps Works Internally
A Logic App workflow consists of a trigger and a series of actions. The trigger can be:
Polling trigger: Checks an endpoint at a defined interval (e.g., every 5 minutes) for new data. Example: "When a new email arrives" in Office 365 Outlook.
Event-based trigger: Responds to an event (e.g., HTTP request, message on Service Bus queue). Example: "When an HTTP request is received" – this creates a callback URL.
Once triggered, the workflow runs actions sequentially or in parallel. Each action is a step that calls a connector, runs built-in operations (e.g., compose, parse JSON), or executes a condition/switch. The Logic Apps runtime orchestrates execution, handles state persistence, and supports retry policies. The workflow definition is stored as JSON in Azure, and each run is recorded in the run history.
Key Components
Connectors: Prebuilt APIs for services. Types: Standard (e.g., Office 365), Enterprise (e.g., SAP), Custom (built via API). Connectors have operations (triggers and actions).
Triggers: The event that starts a workflow. Every Logic App must have exactly one trigger.
Actions: Steps after the trigger. Can include API calls, data transformations, loops, conditions, and scope blocks.
Managed Connectors: Hosted by Microsoft, handle authentication, scaling, and monitoring. Some are free, others incur charges.
Built-in Connectors: Run directly on the Logic Apps runtime for low latency (e.g., HTTP, Service Bus, Azure Functions).
Integration Account: Required for enterprise features like B2B messaging (EDI, AS2) and XML transformation. It stores schemas, maps, agreements, and certificates.
Workflow Definition: JSON file that describes the workflow using the Workflow Definition Language (WDL).
Run History: Stores inputs, outputs, and status of each run (up to 90 days retention).
Defaults and Timers
Retry Policy: Default is exponential backoff with 4 retries over ~7.5 minutes (initial interval 1 second, max 1 hour). Can be configured to fixed interval or none.
Timeout: Each action has a default timeout of 120 seconds. Can be increased up to 1 hour for synchronous operations, or up to 2 days for async operations (when using "Run after" conditions).
Split On: Default is enabled for triggers that return arrays; it creates a separate workflow instance for each array item. Can be disabled.
Concurrency: Default is unlimited concurrent runs. Can be limited to a specific number (e.g., 10) to control load.
Pagination: Default returns 50 items per page for connectors that support it. Can be increased up to 1000 or use continuation token.
Configuration and Verification
You can create Logic Apps via Azure Portal, PowerShell, CLI, or ARM templates. Example CLI command to create a Logic App:
az logic workflow create --resource-group myRG --name myLogicApp \
--definition "workflow.json" --location eastusTo verify run history:
az logic workflow run list --resource-group myRG --name myLogicAppIn the portal, you can monitor runs, view inputs/outputs, and resubmit failed runs.
Interaction with Related Technologies
Azure Functions: Logic Apps can call Functions for custom code execution. Functions are better for long-running or complex processing; Logic Apps for orchestration.
Service Bus: Logic Apps can trigger on messages in queues/topics and send messages. Service Bus provides reliable messaging with sessions and topics.
Event Grid: Logic Apps can subscribe to Event Grid events (e.g., blob created) for near-real-time triggers. Event Grid is a push model; Logic Apps polling triggers are pull.
API Management: Logic Apps can be exposed as APIs through API Management, adding policies like rate limiting and transformation.
Integration Service Environment (ISE): For scenarios requiring dedicated storage, VNet injection, and higher throughput. ISE runs Logic Apps in a dedicated environment.
Exam-Relevant Details
Pricing Plans: Consumption (pay-per-execution) and Standard (fixed cost per hour). ISE is a third option for high-scale enterprise.
Limits: Consumption plan: max 500 actions per workflow, 80 MB request size. ISE: 100,000 actions, 1 GB request size.
Security: Use managed identities for authentication to Azure resources. For on-premises data, use on-premises data gateway.
B2B: Use Integration Account for EDI (X12, EDIFACT), AS2, and XML transformations.
Common Exam Scenarios
SaaS Integration: Connect Salesforce to SharePoint – trigger on new lead, create document.
Hybrid Integration: On-prem SQL Server to Azure Blob Storage – use on-premises data gateway.
Business Process Automation: Approve expense reports – trigger from email, send approval request, update database.
Trap Patterns
Choosing Logic Apps over Functions: If the workflow requires orchestration with multiple steps, conditions, and connectors, Logic Apps is correct. But if you just need a simple API endpoint or heavy computation, Functions is better.
Ignoring limits: Exam may ask about maximum actions or message size. Consumption plan: 500 actions, 80 MB. ISE: 100,000 actions, 1 GB.
Confusing triggers: Polling vs event-driven. Polling triggers have a recurrence interval; event triggers (HTTP, Service Bus) are immediate.
Retry policy: Default exponential backoff with 4 retries – not infinite retries.
Step-by-Step: Creating a Simple Approval Workflow
Define Trigger: Use "When a new email arrives" (Office 365 Outlook) – polling every 3 minutes.
Parse Email Content: Use "Parse JSON" action to extract subject and body.
Condition: Check if subject contains "Approval".
If true: Send approval email via "Send approval email" action – waits for response.
Condition on response: If approved, update SQL database via SQL Server connector.
If false: Send rejection notification.
Error handling: Configure "Run after" for actions to execute on failure.
This workflow demonstrates polling trigger, data transformation, conditional branching, human interaction, and error handling – all core concepts tested on AZ-305.
Define the trigger
Choose a trigger that starts the workflow. For a polling trigger like 'When a new email arrives', the Logic Apps runtime checks the mailbox at a configurable interval (default 3 minutes). The trigger returns a list of new emails. You can set the interval and frequency (e.g., 1 minute, 1 hour). For event-based triggers like 'When an HTTP request is received', a callback URL is generated; the runtime waits indefinitely for a request. The trigger must be the first step and exactly one trigger per workflow.
Add actions and conditions
After the trigger, add actions sequentially. Each action can be a connector operation (e.g., 'Create file'), a built-in operation (e.g., 'Compose', 'Parse JSON'), or a control action (e.g., 'Condition', 'For each', 'Switch'). Conditions evaluate expressions; if true, the workflow takes one path, else another. You can nest conditions and loops. The runtime executes actions in order, respecting parallelism if configured. Each action has an input and output that can be referenced later.
Configure error handling
By default, if an action fails, the workflow stops. Use 'Run after' settings to define alternative paths on failure, timeout, or skipped status. For example, set a second action to run 'After previous action has failed'. You can also configure retry policies: exponential backoff (default), fixed interval, or none. The retry policy applies per action. For critical workflows, add a 'Scope' block to group actions and handle errors collectively.
Test and monitor the workflow
Run the Logic App manually or wait for the trigger. In the Azure portal, navigate to 'Run history' to see each execution. Each run shows status (Succeeded, Failed, Running), duration, and input/output for each action. Click on a run to inspect details. For failed runs, you can resubmit (re-run with same inputs) or view error messages. Use 'Enable diagnostics' to send logs to Log Analytics for advanced monitoring.
Secure and deploy
Use managed identities to authenticate to Azure resources without secrets. For connectors that require credentials, store them in Azure Key Vault and reference them. For on-premises connectors, install and configure the on-premises data gateway. Deploy Logic Apps via ARM templates, Bicep, or Terraform. Set up alerts on failed runs using Azure Monitor. For production, use deployment slots (Standard plan) to stage changes.
Enterprise Scenario 1: Automated Invoice Processing
A multinational company receives thousands of invoices via email daily. They use Logic Apps to automate the workflow: trigger on new email with attachment (PDF), parse the invoice using OCR (via Azure Cognitive Services), extract fields (invoice number, amount, vendor), check against a database for duplicate invoices, and if valid, save to SharePoint and trigger an approval via Teams. If the approval is granted, the Logic App updates the ERP system (SAP) and sends a payment notification to the bank via SWIFT connector. Challenges: handling large attachments (up to 80 MB on Consumption plan), ensuring compliance (audit trails), and managing failures (retry with exponential backoff). In production, they use an Integration Service Environment (ISE) for higher throughput and VNet isolation. Misconfiguration: forgetting to disable 'Split On' for the trigger when the email contains multiple attachments – causing duplicate processing.
Enterprise Scenario 2: Real-time Inventory Sync
A retail chain uses Logic Apps to synchronize inventory between on-premises SQL Server and cloud-based Dynamics 365. The Logic App is triggered by a Service Bus message when inventory changes in the store. It reads the message, calls a stored procedure on SQL Server via on-premises data gateway, transforms the data, and updates Dynamics 365 via its connector. The workflow includes error handling: if the gateway is unreachable, it retries 3 times with 10-second intervals, then sends an alert to the operations team via email. Performance considerations: the on-premises data gateway introduces latency (typically < 100 ms), and the Logic App should be in the same region as the gateway. Common mistake: using a polling trigger instead of Service Bus, causing unnecessary load and delays.
Scenario 3: B2B EDI Message Processing
A manufacturing company exchanges EDI 850 (Purchase Order) messages with suppliers. They use Logic Apps with an Integration Account to process incoming X12 messages. The Logic App triggers when an AS2 message arrives via HTTP. It decrypts and verifies the message using certificates stored in the Integration Account, transforms the X12 to XML using a map, and inserts the order into the ERP system. The Logic App also generates an EDI 997 acknowledgment and sends it back. Common issues: certificate expiry, map mismatches, and agreement misconfiguration. In production, they monitor using Azure Monitor and set up alerts for failed EDI transactions. The exam tests knowledge of Integration Account components: schemas, maps, agreements, and certificates.
Exactly What AZ-305 Tests
AZ-305 objective 4.4: "Design an integration solution" – specifically, selecting appropriate Azure integration services. The exam expects you to differentiate Logic Apps from Azure Functions, Service Bus, Event Grid, and API Management. Key scenarios:
Business process automation: Logic Apps is best for multi-step workflows with human approval.
Enterprise integration: Use Logic Apps with Integration Account for B2B/EDI.
Hybrid integration: Logic Apps with on-premises data gateway for connecting to on-premises systems.
SaaS integration: Logic Apps with 400+ connectors for Office 365, Dynamics, Salesforce, etc.
Common Wrong Answers and Why
Choosing Azure Functions for orchestration: Functions are stateless and good for code execution, but they lack built-in connectors and stateful orchestration. Logic Apps has a visual designer and connectors. Wrong because Functions require custom code for each integration.
Selecting Event Grid for polling triggers: Event Grid is push-based, not pull. Logic Apps can use Event Grid as a trigger (push), but if the scenario describes polling a database every minute, Logic Apps' recurrence trigger is correct, not Event Grid.
Ignoring limits: Exam may ask about maximum actions (500 for Consumption, 100,000 for ISE) or message size (80 MB for Consumption, 1 GB for ISE). Candidates often assume unlimited.
Confusing retry policy: Default is exponential backoff with 4 retries, not fixed interval or infinite.
Specific Numbers and Terms
Pricing tiers: Consumption (pay-per-execution), Standard (fixed hourly), ISE.
Integration Account: Required for B2B. Tiers: Free (only for Consumption), Basic, Standard.
On-premises data gateway: One gateway can support multiple connections. Must be in same region as Logic App.
Limits: Consumption: 500 actions, 80 MB request/response, 90-day run retention. ISE: 100,000 actions, 1 GB, unlimited retention.
Edge Cases
Split On behavior: When a trigger returns an array, by default each element triggers a separate run. If you want to process the entire array in one run, set splitOn: 'none'.
Async operations: Actions that return 202 Accepted are polled for completion. Timeout can be up to 2 days.
Throttling: Connectors have limits (e.g., Office 365: 30 requests per minute). Logic Apps handles retries but can cause delays.
How to Eliminate Wrong Answers
If the scenario requires stateful orchestration with multiple steps, conditions, and connectors, eliminate Functions (stateless) and Event Grid (not orchestration).
If the scenario involves human approval, eliminate Functions and Service Bus – Logic Apps has built-in approval actions.
If the scenario requires B2B EDI, look for Integration Account – if not mentioned, the answer is likely wrong.
If the scenario mentions long-running workflows (hours/days), Logic Apps supports async patterns, but Functions may be better for very long runs (up to 5 minutes for consumption plan, no limit on dedicated).
Azure Logic Apps is a declarative integration platform for automating workflows across cloud and on-premises services.
Each Logic App has exactly one trigger (polling or event-based) and multiple actions.
Default retry policy: exponential backoff with 4 retries over ~7.5 minutes.
Consumption plan limits: 500 actions, 80 MB request size, 90-day run history retention.
ISE (Integration Service Environment) provides dedicated storage, VNet injection, and higher limits (100,000 actions, 1 GB).
Integration Account is required for B2B features like EDI, AS2, and XML transformation.
On-premises data gateway enables connectivity to on-premises data sources.
Use managed identities for secure authentication to Azure resources without secrets.
Azure Logic Apps is best for multi-step orchestration with connectors; Azure Functions for custom code.
Common exam scenarios: SaaS integration, hybrid connectivity, business process automation, and B2B EDI.
These come up on the exam all the time. Here's how to tell them apart.
Azure Logic Apps
Declarative workflow designer (no-code/low-code)
Stateful orchestration with built-in connectors
Over 400 prebuilt connectors for SaaS and on-premises
Built-in retry policies, error handling, and monitoring
Best for business process automation and integration
Azure Functions
Code-first approach (C#, JavaScript, Python, etc.)
Stateless by default (can be stateful with Durable Functions)
Limited built-in connectors; uses custom bindings
Requires custom code for error handling and retries
Best for custom code execution, heavy computation, or simple API endpoints
Logic Apps (Consumption)
Pay-per-execution pricing
Multi-tenant environment
Max 500 actions per workflow
Max request size 80 MB
Automatic scaling with high latency
Logic Apps (Standard)
Fixed hourly pricing (predictable cost)
Single-tenant or dedicated environment
Max 100,000 actions per workflow
Max request size 1 GB
VNet injection and better performance
Mistake
Logic Apps can only connect to cloud services.
Correct
Logic Apps can connect to on-premises systems using the on-premises data gateway. The gateway acts as a bridge, allowing connectors like SQL Server, File System, and SAP to communicate with on-premises data sources securely.
Mistake
All Logic Apps connectors are free.
Correct
Some connectors are free (e.g., HTTP, Service Bus), but many standard connectors (e.g., Office 365, Salesforce) incur charges per action or per execution. Enterprise connectors (e.g., SAP) require an Integration Account and may have additional costs.
Mistake
Logic Apps run indefinitely without timeout.
Correct
Each action has a default timeout of 120 seconds. For synchronous operations, you can increase up to 1 hour. For async operations (202 pattern), the timeout can be up to 2 days. The entire workflow run also has a timeout of 90 days for Consumption plan.
Mistake
You can have multiple triggers in one Logic App.
Correct
A Logic App can have only one trigger. If you need multiple triggers, you must create separate Logic Apps or use a trigger like 'When an HTTP request is received' and call it from multiple sources.
Mistake
Logic Apps cannot handle large messages.
Correct
Consumption plan supports messages up to 80 MB (request/response). For larger messages (up to 1 GB), use ISE. For even larger payloads, use Azure Blob Storage to pass references (claim check pattern).
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Azure Logic Apps is a declarative, low-code platform for building workflows with prebuilt connectors. It is ideal for integrating SaaS applications, on-premises systems, and orchestrating multi-step processes that require human approval. Azure Functions is a code-first, event-driven compute service for running custom code. Functions are stateless (unless using Durable Functions) and better for heavy computation or simple API endpoints. The exam expects you to choose Logic Apps when the scenario involves orchestration, connectors, and minimal code.
The on-premises data gateway is a software component installed on a server inside your corporate network. It acts as a bridge between Logic Apps and on-premises data sources (SQL Server, File System, SAP, etc.). When a Logic App action calls an on-premises connector, the request is sent to the gateway, which then connects to the data source. The gateway supports multiple connections and must be in the same Azure region as the Logic App. It uses Azure Service Bus for secure communication.
An Integration Account is an Azure resource that stores artifacts for B2B integration: schemas, maps, agreements, certificates, and partners. You need an Integration Account when your Logic App processes EDI messages (X12, EDIFACT), AS2 messages, or performs XML transformations using maps. It is also used for trading partner management. There are three tiers: Free (limited to Consumption), Basic, and Standard. The exam expects you to know that Integration Account is required for enterprise integration scenarios.
Yes, but with limits. On the Consumption plan, the maximum request/response size is 80 MB. For larger messages (up to 1 GB), use the Standard plan or ISE. For even larger payloads, use the claim check pattern: store the large file in Azure Blob Storage, pass the blob reference in the Logic App, and process it later. The exam may test these limits, so remember the 80 MB and 1 GB thresholds.
Use managed identities to authenticate to Azure resources (e.g., Azure SQL, Blob Storage) without storing secrets. For non-Azure services, use Azure Key Vault to store secrets and reference them in the Logic App. For incoming HTTP triggers, restrict access using IP whitelisting, Azure AD authentication, or shared access signatures (SAS). For on-premises connectors, ensure the gateway is secured and uses encrypted communication.
Consumption plan is multi-tenant, pay-per-execution, with limits of 500 actions and 80 MB request size. Standard plan is single-tenant, fixed hourly cost, with limits of 100,000 actions and 1 GB request size. Standard also supports VNet injection, better performance, and deployment slots. ISE is a dedicated environment for high-scale enterprise needs. The exam expects you to choose Standard or ISE for scenarios requiring VNet injection or higher limits.
Use the Azure portal's Run History to view each execution's status, inputs, outputs, and duration. For failed runs, you can resubmit with the same inputs. Enable diagnostics to send logs to Log Analytics for advanced querying. Set up alerts on failed runs using Azure Monitor. For performance issues, check connector throttling limits and consider using ISE for higher throughput.
You've just covered Azure Logic Apps for Integration — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?