The Three Durable Function Forms: Orchestrators, Activities, and Entities (With Real Code)

TL;DR: The thing that pushed me toward Durable Functions wasn't some architectural epiphany — it was a cron job graveyard. I had a payment retry workflow split across three Azure Functions, a storage table acting as a makeshift state machine, and a timer trigger that woke up every five

📖 Reading time: ~26 min

What's in this article

1. Why I Keep Reaching for Durable Functions (And Where People Get Lost)


2. Quick Setup Before We Dive In


3. Form 1: The Orchestrator Function


4. Form 2: The Activity Function


5. Form 3: The Entity Function (The One Nobody Explains Well)


6. Putting All Three Together: A Real Workflow Example


7. Picking the Right Form for Your Situation

Why I Keep Reaching for Durable Functions (And Where People Get Lost)

The thing that pushed me toward Durable Functions wasn't some architectural epiphany — it was a cron job graveyard. I had a payment retry workflow split across three Azure Functions, a storage table acting as a makeshift state machine, and a timer trigger that woke up every five minutes to check "did the thing happen yet?" It worked until it didn't. Race conditions, missed retries, and zero visibility into what state any given workflow was actually in. The real problem isn't compute — serverless handles that fine. The problem is that you need your logic to remember things across invocations, and bolting that onto stateless functions with blob storage and timers is a slow-motion disaster.

Durable Functions solves this cleanly, but the documentation does something that trips up almost everyone I've seen onboard to it: it introduces all three forms — orchestrators, activities, and entities — in the same breath. Most tutorials then spend 90% of their time on the orchestrator/activity pair (the fan-out/fan-in example is everywhere), slap a one-paragraph mention of entities at the end, and call it done. So you come away thinking entities are some niche edge case. They're not. I've shipped production code where entities were the primary form, not an afterthought. The confusion compounds because entities have a fundamentally different mental model — they're not about sequencing work, they're about owning state — and that distinction never gets explained clearly enough.

Here's exactly what this article covers, so you can decide if it's worth your time. First, a concrete working example for each of the three forms: the orchestrator (long-running sequential logic), the activity (the actual unit of work), and the entity (the stateful actor). Second, the gotchas I actually hit in production — not the "remember functions must be deterministic" warning you've already read, but the specific ways things break that aren't in the README. Third, an honest take on when not to reach for each one, because Durable Functions has real overhead and there are workflows where a simple queue-triggered function is the right answer. For a broader look at tools that handle workflow automation without writing infra code, see our guide on . Follow for more developer-focused tooling reviews and productivity guides.