Azure Logic Apps is a managed cloud service for building automated workflows that connect apps, data, and services.

First, What Is a Workflow?

A workflow is a series of steps that happen in a set order to get a job done. Most people already follow workflows in daily life. A recipe is a workflow: gather ingredients, chop, cook, serve. An approval process at work is a workflow: a request is submitted, a manager reviews it, and the result is sent back. In computing, an automated workflow means a computer performs those steps by itself whenever something happens.

The Short Definition

Azure Logic Apps lets you design and run automated workflows in the cloud with very little or no traditional programming. You build a workflow in a visual designer, a canvas where you place steps as boxes and connect them in order. Each step is either a trigger, which is the event that starts the workflow, or an action, which is something the workflow does. Logic Apps comes with a huge library of ready-made connectors, which are pre-built links to other services such as email, spreadsheets, databases, messaging systems, social platforms, and business applications.

“Managed” means Microsoft operates the servers and the workflow engine. You focus on describing the business process. Behind the visual designer, the workflow is stored as a text description, which means it can also be edited as text and stored in source control, but you rarely need to touch that unless you want to.

Modern businesses use dozens of separate systems, and getting them to work together is slow and expensive without a better way.

Islands of Information

A typical company uses an email system, a customer database, an accounting tool, a human resources system, a file storage service, and many specialized applications. Each was built by a different vendor and speaks its own language. When information must move between them, such as a new customer in the sales tool that must also appear in accounting and billing, people often copy and paste by hand. This is slow, error-prone, and frustrating.

Custom Integration Is Heavy

The traditional alternative is to hire programmers to write custom connection code for each pair of systems. This means learning each system’s technical interface, writing and testing code, hosting it somewhere, monitoring it, and fixing it whenever either side changes. For simple jobs, such as “when a form is submitted, add a row to a spreadsheet and send a message,” the effort is far more than the value. Many small but useful automations never get built at all.

What You Gain

Six simple ideas explain almost everything: workflow, trigger, action, connector, connection, and run.

Workflow

The workflow is the whole automated process: one trigger followed by a series of actions, arranged on the designer canvas. Depending on the hosting option, a single logic app resource may hold one workflow or many.

Trigger

Every workflow starts with exactly one trigger. A trigger waits for an event, such as “a new email arrived,” “a file was added to a folder,” “a message appeared in a queue,” “a web request was received,” or “it is 8 a.m. on Monday.” When the event happens, the trigger fires and a new run of the workflow begins.

Action

An action is any step that follows the trigger. Actions do the work: send an email, create a record, call a web service, convert a file, ask for approval, or post a message to a chat channel. The output of one step, such as the sender’s address from an email, can be used as input to later steps.

Connector

A connector is a ready-made package that gives you triggers and actions for a particular service. An email connector offers “when an email arrives” and “send an email.” A storage connector offers “when a file is added” and “create a file.” Connectors hide technical details so you can think in business terms.

Connection

A connection holds the sign-in details that let a connector talk to a specific account of a service. You create it once, for example by signing in to a mailbox, and then reuse it across steps and workflows.

Run

Each time a trigger fires, the workflow executes once from start to finish. That single execution is called a run. The platform keeps a run history that records whether each run succeeded or failed, and what each step received and produced.

flowchart TD
  T["Trigger - an event occurs"] --> A1["Action 1 - read the data"]
  A1 --> A2["Action 2 - make a decision"]
  A2 -->|Yes| A3["Action 3 - take one path"]
  A2 -->|No| A4["Action 4 - take another path"]
  A3 --> E["Workflow run ends"]
  A4 --> E
  E --> H["Run history records every step"]
        

The choice of trigger shapes cost, speed, and reliability, so it is worth understanding the main styles.

Polling Triggers

A polling trigger checks a service on a regular schedule, such as every minute, asking, “Is there anything new?” If there is, a run starts for each new item. Polling is simple and works with services that cannot call you. The trade-off is a small delay, since you only learn about new items at the next check, and a steady stream of checks even when nothing is happening.

Push Triggers

A push trigger, sometimes called a webhook trigger, works the other way around. The workflow tells the other service, “Call me when something happens,” and then waits quietly. When the event occurs, the service sends a notification and the workflow starts right away. Push triggers are faster and avoid wasteful checking.

Request Triggers

A request trigger gives the workflow its own web address. Any program that can send a web request to that address starts the workflow, optionally sending data along. This makes a workflow behave like a small web service, which is handy for connecting your own applications.

Schedule Triggers

A recurrence trigger starts the workflow at times you define, such as every night at midnight or every Monday morning. It is ideal for reports, cleanups, and regular data transfers.

Actions do the work, and data flows from step to step like water through connected pipes.

Passing Data Between Steps

When a trigger fires or an action finishes, it produces outputs, pieces of information such as a sender’s name, a subject line, a file’s name, an order number, or a total amount. Later steps can use these outputs as inputs. The designer shows them as clickable items called dynamic content, so you can drop an email’s subject line into a chat message without writing anything.

Variables

A variable is a named container that holds a value which you can change as the workflow runs, such as a running total, a counter, or a status message. Variables are useful when you need to build up a result across several steps.

Expressions

When simple dynamic content is not enough, you can use expressions. These are small formulas, similar to those in a spreadsheet, that calculate or change values: joining pieces of text, formatting a date, getting the length of a list, checking whether something is empty, or picking out one field from a larger piece of data. Expressions let a no-code designer handle surprisingly detailed tasks.

Common Kinds of Actions

Real processes are rarely a straight line, so Logic Apps includes steps that choose, repeat, and branch.

Conditions and Switches

A condition asks a yes-or-no question, such as “Is the invoice total above ten thousand?”, and sends the workflow down one path if the answer is yes and another if no. A switch handles several possible values at once, such as routing a support request to different teams depending on whether it is about billing, technical problems, or sales.

Loops

A for each loop repeats a set of steps once for every item in a list, such as processing each line of an order or each file in a folder. An until loop repeats steps until a condition becomes true, such as checking a job’s status every minute until it says “finished.” Loops have limits to prevent endless repetition.

Parallel Branches

Sometimes several things can happen at the same time. Parallel branches let a workflow start two or more paths together, such as notifying a customer and updating the inventory system simultaneously, and then continue once all branches finish.

Scopes

A scope is a container that groups several steps together so they can be treated as a unit. Scopes make workflows tidier and, as the next chapter shows, are the key to handling errors gracefully.

Delays and Waiting

Workflows can pause for a period of time or until a specific moment, or wait for something to happen, such as a manager’s approval reply. Waiting does not consume your attention or a server of yours; the platform simply resumes the workflow later.

flowchart TD
  S["Trigger: new order received"] --> C{"Is the order total large?"}
  C -->|Yes| AP["Request manager approval"]
  C -->|No| AU["Approve automatically"]
  AP --> L["For each line item"]
  AU --> L
  L --> P1["Update inventory"]
  L --> P2["Notify the customer"]
  P1 --> D["All branches complete"]
  P2 --> D
  D --> F["Mark the order as processed"]
        

Connectors are what make Logic Apps feel like building with blocks instead of writing code.

Two Families of Connectors

Connectors come in two broad families. Built-in connectors run directly inside the Logic Apps engine. They cover core tasks such as HTTP calls, schedules, data handling, and a growing set of Azure services like storage, messaging, and databases. Because they run inside the engine, they tend to be faster and, in some hosting options, cheaper. Managed connectors are hosted and run by Microsoft separately. They provide access to a very large catalog of services, including email, calendars, collaboration tools, social platforms, customer relationship systems, and many business applications. Some managed connectors are classified as standard and others as premium, which can affect pricing.

Custom Connectors

If a service you need has a web interface but no ready-made connector, you can create a custom connector. You describe the service’s operations once, and from then on it appears in the designer like any other connector. Teams commonly build custom connectors for their own internal applications so that colleagues can use them without learning technical details.

Logic Apps can run in two main ways, and the choice affects cost, networking, features, and how you develop.

Consumption: Pay for What Runs

In the Consumption model, your workflow runs on shared, multi-customer infrastructure managed entirely by Microsoft. Each logic app resource contains a single workflow. You pay for each execution and for each action that runs, so a workflow that rarely runs costs very little, and one that never runs costs almost nothing. It scales automatically and needs almost no setup, which makes it excellent for getting started, for light or irregular workloads, and for simple integrations.

Standard: A Dedicated Home for Many Workflows

In the Standard model, one logic app resource can hold many workflows and runs on a dedicated hosting plan that you size, in the way web applications run on a hosting plan. You pay mainly for the reserved compute rather than for each action, and built-in connector actions are billed through that plan. Because the environment is dedicated to you, Standard offers stronger network isolation, including integration with your own virtual networks and private endpoints, and it supports local development and testing on your own computer using Visual Studio Code. It also introduces both stateful and stateless workflows, explained in the next chapter.

A Note on the Retired Environment

An older option called the Integration Service Environment, a dedicated environment for isolated workloads, was retired by Microsoft in 2024. Its role is now filled by the Standard model, so new projects needing isolation should look at Standard.

In the Standard model you choose whether a workflow remembers its progress, trading durability for speed.

Stateful Workflows

A stateful workflow saves the inputs and outputs of every step to storage as it runs. This provides a complete run history, allows long-running processes that wait for hours or days, and lets the workflow resume after a temporary interruption. The cost is that all this saving takes a little time and storage, so each run has more overhead.

Stateless Workflows

A stateless workflow keeps everything in memory and does not save step details unless you turn on debugging history. It runs faster and costs less to operate, but it is meant for short tasks. If it is interrupted midway, it does not resume where it left off, and it has shorter limits on how long it can run.

Things go wrong in the real world: services time out, files are missing, and networks blink. Good workflows expect that.

Retry Policies

Many failures are temporary. A service may be busy for a few seconds and fine afterward. A retry policy tells a step how many times to try again, and how long to wait between attempts, before giving up. Waiting longer after each failure, a pattern called exponential backoff, is kind to a struggling service and often leads to success on the next attempt.

Run After Settings

By default, a step runs only if the one before it succeeded. A run after setting lets you change that. You can tell a step to run only if the previous one failed, timed out, or was skipped. This is how you build an “if this fails, do that” path, such as sending an alert or writing a note to a log.

Try and Catch With Scopes

A common pattern groups the main steps into one scope, the “try” part, and follows it with another scope configured to run only if the first one failed, the “catch” part. The catch scope can look at what went wrong, notify the right people, undo partial work, and mark the item for later review. A final scope can run no matter what, to clean up.

flowchart TD
  T["Trigger"] --> TRY["Try scope - main business steps"]
  TRY -->|Succeeded| OK["Continue normal processing"]
  TRY -->|Failed or timed out| CATCH["Catch scope - log the error and alert the team"]
  CATCH --> UNDO["Undo partial changes if needed"]
  OK --> FIN["Finish scope - tidy up and record the outcome"]
  UNDO --> FIN
        

Designing for Safe Repetition

Because retries and restarts can cause a step to run more than once, the best workflows are idempotent, a long word meaning that doing the same thing twice has the same result as doing it once. For example, instead of “add 100 to the balance,” a safer step is “set the balance for this order to a known value.” Where this is not possible, check whether the work was already done before repeating it, such as looking for an existing record before creating a new one.

Workflows touch email, files, and business data, so securing them matters as much as building them.

Who Can Start and Manage a Workflow

Workflows that start from a web request have an address that can be called by anyone who knows it, unless you restrict it. You can limit callers by allowing only specific network addresses, requiring sign-in through Microsoft Entra ID, or placing the workflow behind an API management layer. Separately, Azure role-based access control decides who may create, edit, run, or view logic apps in the management portal, so you can give operators the ability to view run history without letting them change workflows.

How Workflows Prove Their Identity

When a workflow calls other services, it must sign in. The weakest approach is storing a password or key inside the workflow. The better approach is a managed identity, an identity Azure creates and manages for the logic app so no secret is stored. You then grant that identity permission to reach specific resources, such as a storage account or a key vault. Many built-in connectors and the HTTP action can use managed identities.

Keeping Secrets Out of Workflows

If a workflow must use a secret, such as a key for a partner’s service, keep it in Azure Key Vault and have the workflow fetch it when needed rather than pasting it into steps. Secure input and output settings can also hide sensitive values from run history, so passwords and personal data do not appear in logs that many people can read.

Network Protection

For private data, the Standard model supports virtual network integration for outgoing calls and private endpoints for incoming calls, keeping traffic inside your own network. For systems inside your office or datacenter, the on-premises data gateway acts as a secure bridge: a small program installed on a machine in your network makes an outbound connection to Azure, so Logic Apps can reach local databases and file shares without opening your firewall to the internet.

A workflow you cannot observe is a workflow you cannot trust.

Run History

The first place to look is the run history of a workflow. It lists each run with its status, start time, and duration. Opening a run shows the workflow with each step marked as succeeded, failed, or skipped, and you can click any step to see exactly what it received and what it returned. This makes finding the cause of a failure much quicker than reading through logs.

Metrics and Alerts

Azure Monitor collects numbers about your workflows, such as how many runs started, succeeded, and failed, how long they took, and how many actions executed. You can build alerts that notify you when failures cross a threshold or when a workflow stops running when it should be running regularly.

Diagnostic Logs

For deeper analysis, diagnostic settings can send detailed records of runs, triggers, and actions to a Log Analytics workspace. There you can search across all workflows, find patterns such as the same step failing every Monday, and keep records longer than the built-in history allows. In the Standard model, Application Insights integration offers extra tracing and performance insight.

Tracking Business Meaning

Technical status is not always enough. A run can succeed technically while the business outcome is wrong. Adding tracked properties, such as an order number or customer identifier, to your logs lets support staff search by the things they care about rather than by run numbers.

Large organizations exchange structured business documents with partners, and Logic Apps has features for that world.

What Is B2B?

B2B means business to business: companies exchanging documents such as purchase orders, invoices, and shipping notices. Many industries use standard electronic formats and protocols for this, with names like EDI, X12, EDIFACT, and AS2. These formats are strict, and both sides must agree on the details.

Building Blocks for Partner Exchanges

Transforming Messages

Even without formal B2B, transforming data is a daily need. One system calls a field “customer_name,” another calls it “ClientFullName,” and a third expects the first and last names split apart. Logic Apps can parse, reshape, and map data between these formats, either with visual data operations or with dedicated mapping tools.

Azure has several services that automate or connect things, and choosing well saves effort.

Logic Apps and Its Neighbors

Working Together

These services are often combined. A workflow might be started by an event from Event Grid, call an Azure Function to do a tricky calculation, put a message on a Service Bus queue for another system, and notify a team through email. Choosing Logic Apps for the orchestration and Functions for custom steps is a very common and healthy pattern.

Costs depend on the hosting model and how many actions your workflows execute.

What Drives the Bill

In the Consumption model, you pay per action execution, with different rates for built-in actions, standard connectors, and premium connectors. Trigger checks also count, which is why frequent polling can add up. In the Standard model, the main cost is the hosting plan, billed for the reserved compute whether or not workflows are running, with extra charges for certain connector types and storage. Prices differ by region and change over time, so always check the current pricing pages.

Practical Ways to Reduce Cost

Every service has speed limits, so well-designed workflows work with them rather than against them.

Why Limits Exist

The platform, and every service your workflow talks to, limits how much work it will accept in a given time to protect itself from overload. If your workflow calls an email service too fast, it may reply “too many requests.” Logic Apps has its own limits as well, on run duration, loop size, message size, and how many actions can execute in a period. These numbers differ between hosting models and change over time.

Concurrency Control

Concurrency means how many things happen at the same time. You can control how many runs of a workflow may execute at once, and how many iterations of a loop run in parallel. Higher concurrency finishes large batches faster but can overload a downstream system or break processes that must happen in order. Setting concurrency to one forces items to be handled one at a time, in sequence, which is important when order matters.

No technology is perfect. Seeing both sides helps you decide where Logic Apps fits.

Comparing Ways to Build Integrations

Teams repeat the same successes and the same mistakes. Learn from both.

Patterns Worth Copying

Anti-Patterns to Avoid

Across industries, teams use Logic Apps to remove repetitive work and connect systems.

A short checklist that captures the lessons from earlier chapters.

Best Practices

Common Mistakes

You can begin with a small, useful automation and build up from there.

No. You can build many workflows with the visual designer and ready-made connectors. Programming knowledge helps for advanced expressions, custom connectors, and code steps, but it is not required to begin.

A trigger is the event that starts a workflow, such as a new email or a schedule. An action is any step that happens afterward, such as sending a message or saving a file.

A connector is a ready-made package that gives you triggers and actions for a service, handling sign-in and communication details so you can work in business terms.

Start with Consumption for learning, prototypes, and light or irregular loads, since you pay per execution. Choose Standard for many workflows, steady load, local development, or private networking needs. Compare current features and pricing before deciding.

Stateful workflows save every step’s inputs and outputs, supporting history, long-running processes, and resuming after interruption. Stateless workflows keep data in memory for speed and lower cost, but are for short tasks and have no stored history by default.

Use retry policies for temporary problems, group main steps into a scope, and add a catch scope using run-after settings to log errors, alert people, and undo partial work. Also set up alerts on failed runs.

Through the on-premises data gateway, a small program installed inside your network that connects outward to Azure, so no inbound firewall holes are needed. In the Standard model you can also use virtual network integration with private connectivity.

Use managed identities wherever the target service supports them, store unavoidable secrets in Azure Key Vault, and turn on secure input and output settings so sensitive values do not appear in run history.

Common causes are frequent polling triggers, workflows that run far more often than intended, loops with many actions, a workflow that accidentally triggers itself, or premium connectors. Review run counts and action counts, and consider a different trigger style or hosting model.

Microsoft retired it in 2024. For isolation and network control, the Standard hosting model is the intended path. Check Microsoft’s current guidance if you have older workloads that used it.

Use Functions for custom logic, heavy computation, or fine control that is awkward to build visually. Many solutions use both: Logic Apps orchestrates the process and calls Functions for the special steps.

Treat workflow definitions like software. Store them in source control, parameterize environment-specific settings, and deploy through automated pipelines with review and approval steps between environments.

Azure Logic Apps is a managed service for building automated workflows by connecting triggers and actions through a visual designer and a large library of connectors. A trigger starts each run, actions do the work, control steps add decisions, loops, and parallel paths, and scopes with run-after settings provide try and catch error handling. You can host workflows in the pay-per-use Consumption model or in the dedicated Standard model with stronger networking and local development, and, in Standard, choose between stateful and stateless workflows. Managed identities, Key Vault, private networking, and the on-premises data gateway keep connections secure, while run history, metrics, and diagnostic logs make behavior visible.

Success comes from designing the process first, choosing the right hosting model and trigger style, handling failures on purpose, securing identities and secrets, watching cost and limits, and managing workflows like software. The service supplies the engine and the building blocks; your design and discipline decide how reliable the automation becomes.