CH05-05: Workflow Orchestration with Logic Apps

Goal

The chapter has covered reliable commands, event notifications, and streams. This section covers workflows: processes that coordinate steps, decisions, connectors, and visibility.

Azure Logic Apps is a workflow orchestration platform. In plain language, it helps teams build integration workflows that connect systems, run steps in sequence, branch on conditions, call connectors, and keep visible run history.

The durable idea is:

Logic Apps is for coordinating process steps, especially when connectors and visible workflow history matter.

The Short Version

Use Logic Apps when the integration problem is not just moving a message. Use it when the problem is coordinating a process.

Examples include:

• Approve a high-value order.

• Move a file from SFTP to Blob Storage.

• Update Salesforce, SAP, or a database after an event.

• Send an email or Teams notification when a business exception occurs.

• Transform and route partner messages.

• Coordinate a process that needs retries, branching, and run history.

Order exception -> Logic Apps workflow
             |-- Check customer status
             |-- Request approval
             |-- Update CRM
             |-- Send message to Service Bus

The workflow is the design unit. The steps and their visibility matter.

Workflow Versus Message Passing

A queue holds work. An event router tells systems something happened. A stream ingests many records. A workflow coordinates a process.

Workflow orchestration usually includes:

• A trigger that starts the workflow.

• Actions that call systems or transform data.

• Conditions and branches.

• Retries and error handling.

• Connector authentication.

• Run history.

• Human or business approval steps.

• Integration with SaaS, enterprise, cloud, or on-premises systems.

If the team is writing a lot of custom glue code just to call connectors, branch on conditions, send emails, retry steps, and show process status, a workflow engine may be clearer.

Connectors and Enterprise Integration

Logic Apps is especially useful when integration crosses system boundaries.

It provides a large connector ecosystem for Azure services, Microsoft services, databases, SaaS platforms, file systems, enterprise systems, and partner integrations. You do not need to memorize the connector list. The important idea is that connectors can reduce custom code when the architecture problem is system coordination.

Examples:

Logic Apps can work with Service Bus, Event Grid, Event Hubs, Functions, APIs, and many other systems. It does not replace them. It often coordinates around them.

Visibility and Ownership

Workflow visibility is often the reason Logic Apps is a better answer than hidden custom code.

For business processes, teams often need to know:

• Which step failed?

• Which approval is pending?

• Which connector returned an error?

• Was the message transformed correctly?

• Did the partner system accept the update?

• Can the workflow be replayed, corrected, or investigated?

Run history and workflow structure help operations and business teams understand what happened. That matters for enterprise integration, support, audit, and incident response.

Error Handling and Idempotency

Logic Apps still requires design discipline.

Important questions include:

• What happens when a connector call fails?

• Which actions should retry?

• Which failures need manual intervention?

• Can the workflow safely run the same step again?

• Where are secrets and connector credentials stored?

• Who owns workflow changes and production support?

• How long should run history and logs be retained?

• Which workflows need private network access or single-tenant hosting?

At-least-once delivery and retries are useful, but they can create duplicate effects if downstream operations are not idempotent. A workflow that sends two payment requests or two shipments is not robust simply because it has a visual designer.

Example: High-Value Order Approval

Imagine a retail platform receives an order above a fraud or value threshold. The order should not go straight to fulfillment.

The integration might look like this:

Order-created event
    |
    v
Event Grid routes exception event
    |
    v
Logic Apps workflow
    |-- Check customer risk profile
    |-- Request approval from operations
    |-- Update CRM with decision
    |-- If approved, send fulfillment command to Service Bus
    |-- If rejected, notify customer support

Event Grid is useful for routing the event. Logic Apps owns the business process. Service Bus carries the fulfillment command after approval because fulfillment is reliable work.

This is the chapter's model in action. Each service has a job.

Common Mistakes

• Writing fragile custom glue code for connector-heavy workflow.

• Using Logic Apps for high-throughput streaming ingestion.

• Hiding critical business process logic without monitoring and ownership.

• Forgetting identity, secrets, retry behavior, and run history retention.

• Treating a workflow diagram as complete architecture without thinking about failure and duplicate effects.

• Putting too much business logic into a workflow when a dedicated service should own the domain rules.

If Someone Asks You

When would you use Logic Apps?

A good answer is:

I use Logic Apps when the integration problem is workflow orchestration: triggers, actions, conditions, connectors, approvals, retries, and visible process history. It is useful for enterprise integration and connector-heavy business processes. I would still design identity, secrets, error handling, idempotency, monitoring, and ownership, and I would combine Logic Apps with Service Bus, Event Grid, Event Hubs, Functions, or APIs when those services have a clearer job.

What You Should Remember

Use Logic Apps when the process, connectors, and workflow visibility are the architecture problem.

Questions to Check Your Understanding

1. What makes workflow orchestration different from message queuing?

2. Why are connectors important in Logic Apps scenarios?

3. What operating responsibilities remain after building a workflow?