Stateful vs Stateless Workflows — When to Use Which

Azure Logic Apps (Standard) offers two workflow types: stateful and stateless. Choosing the right type impacts performance, cost, and observability. This tutorial explains the differences and helps you decide which to use.

What Is a Stateful Workflow?

A stateful workflow persists its run history and state to external storage (Azure Storage) at each action. This enables:

• Run history — Full visibility into past executions, inputs, and outputs
• Long-running operations — Supports workflows that run for hours, days, or longer
• Durable execution — Survives host restarts; resumes from the last checkpoint
• Resubmit capability — Re-run failed actions from the run history

What Is a Stateless Workflow?

A stateless workflow runs entirely in memory without persisting run history. This provides:

• Faster execution — No storage I/O overhead between actions
• Lower latency — Ideal for synchronous request-response patterns
• Reduced cost — No storage transactions for run state
• No run history — Once complete, execution details are gone (unless you enable Application Insights)

Comparison Table

When to Use Stateful

Choose stateful workflows when you need:

• Business-critical workflows — Order processing, approvals, orchestrations
• Debugging and auditing — Run history for troubleshooting and compliance
• Long-running processes — Waiting for human approval or external callbacks
• Retry and resubmit — Ability to replay failed runs from a specific action
• Batching and chunking — Processing large datasets over time

When to Use Stateless

Choose stateless workflows when you need:

• High-throughput processing — Event-driven microservices handling thousands of requests/sec
• Request-response APIs — Synchronous endpoints where latency matters
• Low-latency transformations — Data mapping, validation, routing
• Cost optimization — High-volume scenarios where storage costs add up
• Simple integrations — Fire-and-forget or lightweight orchestrations

Step-by-Step: Create Both Types and Compare Behavior

Step 1: Create a Stateful Workflow

1. Open your Logic App (Standard) in the Azure Portal
2. Navigate to Workflows → + Add
3. Enter a name: order-processing-stateful
4. Select State type: Stateful
5. Click Create

Step 2: Create a Stateless Workflow

1. Navigate to Workflows → + Add
2. Enter a name: order-validation-stateless
3. Select State type: Stateless
4. Click Create

Step 3: Add Identical Logic to Both

Add the same actions to both workflows for comparison:

1. Trigger: When an HTTP request is received
2. Action 1: Compose — transform the input payload
3. Action 2: Compose — add a timestamp
4. Action 3: Response — return the result

Step 4: Test and Compare

Trigger both workflows with the same HTTP request and observe:

• Stateful: Run appears in run history with full input/output per action
• Stateless: No run history; response returns noticeably faster

Performance Benchmarks

Approximate latency differences for a 3-action HTTP-triggered workflow:

Note: These are approximate values. Actual performance depends on action complexity, connector types, and hosting plan (WS1/WS2/WS3).

Converting Between Stateful and Stateless

You cannot change the state type of an existing workflow in-place. To convert:

Stateful → Stateless

1. Open the stateful workflow in the Designer
2. Select Code view and copy the workflow.json definition
3. Create a new stateless workflow
4. Paste the definition into the new workflow's code view
5. Remove any actions that require run history (e.g., resubmit patterns)
6. Save and test

Stateless → Stateful

1. Open the stateless workflow in Code view
2. Copy the workflow.json definition
3. Create a new stateful workflow
4. Paste the definition and save
5. Run history will now be available for future executions

Via host.json (Enable Run History for Stateless — Preview)

You can temporarily enable run history on stateless workflows for debugging:

{
  "extensions": {
    "workflow": {
      "settings": {
        "Runtime.FlowRunRetryableActionJobCallback.StatelessRunHistory": "true"
      }
    }
  }
}

Warning: This adds storage overhead and should only be used for debugging, not production.

Summary

Choose stateful when you need visibility and durability. Choose stateless when you need speed and throughput.

← Previous: Calling APIs from Workflows | Next: CI/CD for Logic Apps →