Azure Logic Apps & Power Automate

Key Points

• Logic Apps and Power Automate are sibling connector-based workflow engines: same connector library, different audiences. Logic Apps is dev-leaning (JSON/Bicep deployable, ALM-friendly); Power Automate is citizen-developer (Power Platform UI, mostly UI-only).
• Two flavors of Logic Apps: Consumption (multi-tenant, pay-per-execution, no VNet) and Standard (single-tenant on Functions runtime, predictable pricing, VNet integration, stateless workflows).
• Connector ecosystem is the value prop: 1,000+ pre-built integrations (Salesforce, SAP, ServiceNow, Twilio, AAD, Office 365). Cuts integration time from weeks to hours.
• When Logic Apps wins over Functions: heavy connector use, declarative orchestration. When Functions wins: complex compute, perf-sensitive, code-first.
• Pitfalls: connector throttling, hidden Power Automate licensing costs, debugging UX, observability via Log Analytics.

Concepts (deep dive)

What they are

A connector-based workflow engine is the right tool when most of the work is integration: pulling a record out of Salesforce, transforming it, dropping it into SAP, emailing someone on failure. Writing that as a Function means re-implementing OAuth, pagination, retry, idempotency, and schema mapping for every system you touch — weeks of plumbing that has nothing to do with your business. Logic Apps gives you 1,000+ pre-built connectors plus a declarative orchestration layer (triggers, actions, conditions, loops) so the only thing you write is the workflow, not the integrations.

Workflow engines that execute a directed graph of "actions" connected by triggers. Each action is a connector call (HTTP, service-specific API, control flow).

[ Trigger ]                 (HTTP webhook, timer, blob created, queue message, ...)
    │
    ▼
[ Action 1 ]  Get record from Salesforce
    │
    ▼
[ Action 2 ]  Transform JSON
    │
   ◊─────────  Condition: amount > 10000?
    │     │
    Y     N
    ▼     ▼
[ A3 ]  [ A4 ]   Send email     /     Insert SQL row

The workflow definition is JSON (workflow.json or ARM definition block). The engine handles retries, persistence, parallelism, and connector auth.

Logic Apps vs Power Automate

💡 They share a runtime; the difference is packaging + audience. A workflow built in Logic Apps can mostly be ported to Power Automate and vice versa.

Logic Apps: Consumption vs Standard

Consumption: predictable pricing for occasional flows; serverless feel.
Standard:    dev-friendly; feels like Functions; better for heavy workloads.

Connector ecosystem

Connectors come in tiers:

• Standard connectors — included (HTTP, Storage, Service Bus, SQL on-prem via Data Gateway, Office 365, AAD, Twitter).
• Premium connectors — extra cost / Power Platform license (Salesforce, SAP, ServiceNow, Oracle, Adobe Sign).
• Custom connectors — build your own from OpenAPI spec.

Connector = (auth config) + (set of operations: GET/POST/etc.) + (triggers / actions)

Triggers

Polling triggers cost executions even when nothing happens — push wins on cost and latency.

When Logic Apps wins over Functions

• Heavy connector reuse — pre-built Salesforce/SAP/Slack integration.
• Long-running workflows — engine persists state across hours/days, survives restarts.
• Stakeholder-friendly — non-devs can read the diagram.
• Less code — declarative, fewer bugs to write/test.

When Functions wins

• Complex compute — image processing, ML inference, custom algorithms.
• Latency-critical — function call < 10ms; Logic App per-action overhead > 100ms.
• Heavy fan-out / fan-in — Durable Functions handles this with code.
• Dev velocity — devs prefer C# over JSON DSL.

A common hybrid: Logic Apps orchestrate cross-system flow → call a Function for custom transformation → continue.

Logic Apps + brokers

Service Bus / Event Grid as triggers:

[ Service Bus topic: orders ]
   │
   └──► Logic App trigger: "When a message is received"
          │
          ▼
        [ Parse JSON ]
          │
          ▼
        [ Call Salesforce: Create Case ]
          │
          ▼
        [ Send Teams notification ]

Pairs naturally with Service Bus & Event Hubs. Logic Apps subscribes; doesn't poll.

ALM for Logic Apps

repo/
  workflow1/
    workflow.json
    parameters.json
  workflow2/
    workflow.json
  host.json
  connections.json    ← refs to API Connection resources
  bicep/
    main.bicep        ← deploys Logic App + connections
  pipelines/
    azure-pipelines.yml

Deploy via Bicep / ARM. Source-controlled. PR review of workflow.json diff. The definition is portable across envs as long as connection IDs are parameterized.

resource workflow 'Microsoft.Logic/workflows@2019-05-01' = {
  name: 'orderFlow'
  location: location
  properties: {
    state: 'Enabled'
    definition: loadJsonContent('workflow.json')
    parameters: {
      '$connections': {
        value: {
          servicebus: { connectionId: sbConn.id, /* ... */ }
        }
      }
    }
  }
}

Testing Logic Apps

• Run history — every execution stored with full input/output of every action. Replay from any step.
• Local dev (Standard) — VS Code extension runs the workflow on your machine.
• Mock connectors — point HTTP actions at a mock server in test env.
• Integration tests — trigger by HTTP and assert on output / side effects.

There's no good unit-test story; treat them as integration components.

Power Automate Desktop (RPA)

Robotic Process Automation — drives the UI of legacy desktop apps that have no API. "Click button, type text, read screen." Used to be "WinAutomation" before Microsoft acquired it.

Use cases:

• Mainframe terminal screens.
• Legacy desktop ERPs with no API.
• Web apps you can't call directly (login walls, JS-heavy UIs).

[ Trigger: schedule ]
   │
   ▼
[ Open SAP GUI ]
[ Type credentials ]
[ Navigate to TX FB60 ]
[ Read invoice fields ]
[ Write to Excel ]
[ Send email summary ]

⚠️ Brittle — UI changes break flows. Use only when an API truly doesn't exist.

Pitfalls

Connector throttling. Most connectors have per-connection rate limits (e.g., 600 calls/minute for Office 365). High volume → 429 → retries → backoff. Track in Log Analytics.

Hidden costs. - Power Automate "premium" connectors require P1 (~$15/user/mo) or process license (~$100/flow/mo). - Logic Apps Consumption: per-action execution charge — innocuous-looking loops over 10K items × 5 actions = 50K billable executions.

Versioning. - Each save creates a new version. Old versions retained but not auto-cleaned. - No diff UI in portal; rely on JSON in source control.

Debugging UX. - Run history shows actual JSON input/output — gold for diagnosing. - But secrets are masked in run history when correctly marked as secureInputs/secureOutputs. Easy to forget; logs leak.

Observability. - Send to Log Analytics workspace for queries. - Pair with Application Insights (Standard tier supports it natively via the Functions host).

// Find slow runs
AzureDiagnostics
| where ResourceProvider == "MICROSOFT.LOGIC"
| where status_s == "Succeeded"
| extend dur = duration_d
| where dur > 30000
| project TimeGenerated, resource_runId_s, dur

Power Platform vs Logic Apps governance

The pain point: admins often think they're separate worlds, but the connectors are shared. A flow built in Power Automate by an HR analyst can run with their Office 365 credentials and access enterprise data — without IT review. Mitigations:

• Data Loss Prevention (DLP) policies — block premium connectors except for approved environments.
• Center of Excellence (CoE) — Microsoft's solution for governing Power Platform sprawl.
• Environment strategy — separate prod / dev environments; restrict prod to vetted makers.
• Approval workflow — require admin sign-off before production deployment.

For dev shops: prefer Logic Apps (real ALM). For business automation by non-devs: Power Automate with strong DLP.

Quick example

// workflow.json
{
  "definition": {
    "$schema": "https://schema.management.azure.com/...",
    "triggers": {
      "Recurrence": {
        "type": "Recurrence",
        "recurrence": { "frequency": "Hour", "interval": 1 }
      }
    },
    "actions": {
      "Get_pending_orders": {
        "type": "ApiConnection",
        "inputs": {
          "host": { "connection": { "name": "@parameters('$connections')['sql']['connectionId']" } },
          "method": "get",
          "path": "/v2/datasets/.../tables/orders"
        }
      },
      "For_each_order": {
        "type": "Foreach",
        "foreach": "@body('Get_pending_orders')?['value']",
        "actions": {
          "Send_Teams_message": {
            "type": "ApiConnection",
            "inputs": {
              "host": { "connection": { "name": "@parameters('$connections')['teams']['connectionId']" } },
              "method": "post",
              "body": { "messageBody": "Order @{items('For_each_order')?['id']} pending" },
              "path": "/flowbot/actions/notification/recipienttypes/channel"
            }
          }
        },
        "runAfter": { "Get_pending_orders": ["Succeeded"] }
      }
    }
  }
}

Code: correct vs wrong

❌ Wrong: secrets in plain Logic App parameters

{ "parameters": { "apiKey": { "value": "abc123" } } }

✅ Correct: Key Vault reference

{ "parameters": { "apiKey": { "type": "securestring", "value": "@Microsoft.KeyVault(SecretUri=https://...)" } } }

❌ Wrong: polling trigger when push is available

Recurrence every 1 minute polling SQL — costs 43,200 trigger evaluations/month.

✅ Correct: change-based trigger

When an item is created or modified connector trigger — push from source.

❌ Wrong: huge JSON in workflow definition

Embedded HTML email template with hundreds of lines inline.

✅ Correct: external resource

Store template in Storage; load via HTTP action; or use Azure Function for compose.

Design patterns for this topic

Pattern 1 — "Logic Apps for connector-heavy orchestration; Functions for compute"

• Intent: match tool to workload.

Pattern 2 — "Push trigger via Service Bus / Event Grid"

• Intent: zero polling cost; low latency.

Pattern 3 — "Logic Apps Standard for VNet-resident workflows"

• Intent: private connectivity to backend systems.

Pattern 4 — "Power Automate + DLP + CoE"

• Intent: govern citizen-dev sprawl.

Pattern 5 — "Run history as audit trail"

• Intent: every execution is its own incident report.

Pros & cons / trade-offs

When to use / when to avoid

• Use Logic Apps when the work is "call N SaaS systems and stitch results."
• Use Standard tier for VNet, multiple workflows, dev productivity.
• Use Power Automate for HR / ops / business-driven automation.
• Avoid for high-throughput hot paths (use Functions or services).
• Avoid RPA when an API exists.

Interview Q&A

Q1. Logic Apps vs Power Automate? Same engine; different audience. Logic Apps for devs (JSON, ALM); Power Automate for business users (UI-driven, per-user license).

Q2. Consumption vs Standard tier? Consumption: multi-tenant, pay-per-execution. Standard: single-tenant on Functions, VNet, multiple workflows, local dev.

Q3. When Logic Apps over Functions? Heavy connector use; long-running orchestration; non-dev-readable. Functions wins on compute and latency.

Q4. Connector throttling? Per-connection rate limits per second/minute. Track 429s in Log Analytics; consider parallelism limits.

Q5. ALM for Logic Apps? Workflow definition is JSON; deploy via Bicep / ARM; parameterize connection IDs per env.

Q6. Stateless vs stateful workflows? Standard tier lets you mark workflows stateless — no run-history persistence; lower latency, no replay.

Q7. Power Automate Desktop? RPA: drives UI of legacy apps with no API.

Q8. DLP policies? Power Platform admin feature — restrict which connectors flows can use per environment.

Q9. Push vs poll triggers? Push (webhook / Service Bus / Event Grid) is cheaper and lower-latency than polling.

Q10. Run history? Every execution stored with full I/O of each action. Replay from any step. Mark sensitive params secureInputs/Outputs.

Q11. Cost surprises? Power Automate premium connectors require licensing. Consumption logic apps charge per action — large foreach loops add up.

Q12. Source control? Logic Apps: easy (JSON). Power Automate: solutions export + ALM Accelerator; less natural.

Gotchas / common mistakes

• ⚠️ Premium connector in Power Automate without licensing — flow fails at runtime.
• ⚠️ Polling triggers racking up billable evaluations.
• ⚠️ Secrets in parameters instead of Key Vault refs.
• ⚠️ secureInputs/Outputs not set — secrets visible in run history.
• ⚠️ Connector throttling unmonitored — silent 429s.
• ⚠️ No ALM — flows live in production with no version control.
• ⚠️ RPA when an API exists — pointlessly fragile.

Further reading

• MS Learn: Logic Apps
• Logic Apps Standard vs Consumption
• Power Automate
• Power Platform CoE Starter Kit
• Power Platform DLP