How do you build workflows that can wait days or weeks for human approval without keeping a worker running the whole time?

What if your approval flows could wait weeks for a human to click “Approve” and still pick up exactly where they left off—without burning a worker, holding a connection open, or duct-taping cron jobs around the gap?

Quick Answer: With Temporal, you model the approval as a Workflow that uses durable timers and signals. The Workflow can wait days or weeks for human input while no worker is actively running, then resume instantly from that exact point when the approval arrives.

Frequently Asked Questions

How can a Workflow “wait” for days or weeks without holding resources?

Short Answer: Temporal persists Workflow state and execution history in a central service, so the Workflow can be completely idle between steps while consuming no worker CPU or in-memory resources.

Expanded Explanation:
In a traditional system, “waiting” usually means blocking a thread, keeping a process alive, or juggling a fragile combination of cron, queues, and state in a database. That doesn’t scale, and it falls apart under failures. Temporal flips this model. A Workflow’s full logical state is stored durably in the Temporal Service as an event history. Workers only load that state when there is actual work to do—running a bit of code, scheduling an Activity, or handling a signal.

When your Workflow reaches a human-approval step, it records that point in its event history and effectively goes to sleep. No worker thread is blocked. No long-lived connection is held. When the human eventually approves (or rejects), a signal or an API-triggered event wakes the Workflow, the worker replays its event history to reconstruct state, and your code resumes from the next line as if nothing happened.

Key Takeaways:

• Temporal stores Workflow state durably, so workflows can be idle for days or months without consuming worker resources.
• Workers wake up only when there’s new work (timers fired, signals received), then replay history to restore state and continue execution.

---

What does the process look like for a long-running human-approval Workflow?

Short Answer: You write a Workflow method that reaches an approval point, waits on a durable signal or timer, and then continues once the approval or timeout arrives.

Expanded Explanation:
From the developer’s perspective, a human-in-the-loop Workflow is just normal code with a “pause here until approval” step. You might create an order, call external services, send a notification to the approver, then wait. Under the hood, Temporal records each of those steps as events. When the Workflow hits the wait—for example, workflow.await or a signal handler—it stops executing and the worker is free to handle other tasks.

When the approver clicks a link in your UI, your app backend calls the Temporal Service to send a signal to the Workflow execution (identified by Workflow ID). Temporal appends that signal to the Workflow’s history. A worker picks up the Workflow Task, replays the history to reconstruct the Workflow’s in-memory state, and then executes the continuation logic after the approval. The same pattern works whether the wait is 30 seconds, 3 days, or 3 months.

Steps:

1. Define the Workflow: Include a step that waits for an approval signal or a combination of signal + timer (approval or timeout).
2. Expose an approval UI/API: Your frontend calls your backend, which uses the Temporal SDK to signal the Workflow when the human acts.
3. Handle both paths: After approval (or timeout), continue the Workflow—e.g., finalize the order, apply a compensating action, or cancel.

---

How is this different from using cron jobs, queues, or a BPM engine?

Short Answer: Cron and ad-hoc queues force you to manually manage state, retries, and recovery; Temporal gives you a single durable execution model where state, timers, and signals are built in and automatically replayed.

Expanded Explanation:
Without Temporal, human-approval flows usually devolve into a mess of state machines: you store “status = WAITING_FOR_APPROVAL” in a database, kick off a cron job or a background worker to poll, glue queues together to send reminders, and scatter retry logic across services. When something crashes, you reconstruct what happened from logs and partial state. When approvals take longer than expected, you stretch TTLs and hope you remembered every edge case.

With Temporal, you model the entire approval lifecycle as a Workflow: pre-approval Activities (e.g., KYC checks), the durable wait, post-approval steps, and compensations on rejection. The Temporal Service manages retries, timeouts, timers, and signals. If workers crash or you deploy new code during a multi-week wait, Temporal just replays the Workflow’s event history into the new worker and continues.

Comparison Snapshot:

• “DIY” (cron + queues + DB): Manual state machines, custom retries, fragile polling, complex recovery scripts.
• BPM/legacy workflow engine: Often external DSLs, proprietary GUIs, weaker code-first testing and replay semantics.
• Temporal Durable Execution: Code-first Workflows and Activities with durable timers, signals, and automatic replay.

Best for: Teams that want long-running, human-in-the-loop flows expressed as normal code, with strong correctness guarantees and no manual orchestration glue.

---

How do I implement a human-approval Workflow with Temporal Cloud or self-hosted Temporal?

Short Answer: Implement a Workflow method that awaits a signal or condition, run workers in your environment using a Temporal SDK, and use your application backend to send approval signals when humans act.

Expanded Explanation:
Implementation is the same whether you run open-source Temporal yourself or use Temporal Cloud. The Temporal Service (or Cloud) stores the Workflow histories and coordinates tasks. Your workers—running in your own infrastructure—execute the Workflow and Activity code. Either way, Temporal never runs or sees your business code; workers connect outward to the Service over secure, unidirectional connections.

You typically map a business entity (like OrderID or ApprovalRequestID) to a Workflow ID. When it’s time for a human to approve, you might send an email or Slack message containing a link. The link hits your backend, which uses the SDK to signal the Workflow. The Workflow resumes, and the Temporal Web UI gives you full visibility into every step—who waited, for how long, and what path the approval took.

What You Need:

• A Temporal cluster (self-hosted or Temporal Cloud) and workers in your environment using a supported SDK (Go, Java, TypeScript, Python, .NET).
• An application endpoint or UI that can send signals to the running Workflow execution when the human approves or rejects.

---

How does this approach improve reliability and business outcomes?

Short Answer: You eliminate orphaned approval flows, reduce manual recovery, and get complete visibility into long-running processes—even when they span days, weeks, or months.

Expanded Explanation:
Human approvals are where systems usually break: people delay, sessions expire, services restart, and you end up with stuck orders and inconsistent state. With Temporal, failures are expected and absorbed into the model. If an API call fails before the approval, you define a retry policy on the Activity instead of hand-rolling retry loops. If a worker deploy happens mid-approval, the Workflow resumes after redeploy. If an approval never arrives, you can enforce deadlines and compensations with a durable timer.

Operationally, support teams no longer have to piece together “what happened” from logs, emails, and partial DB rows. They open the Temporal Web UI, search by Workflow ID or business key, and see a complete history of the approval flow—each Activity, each signal, each retry. They can inspect, replay, and even rewind logic as needed. That translates directly into fewer dropped approvals, cleaner audit trails, and more predictable SLAs.

Why It Matters:

• No lost progress, no orphaned approvals: Every step—pre-checks, notifications, approvals, compensations—is captured and replayable.
• Less firefighting, more shipping: Developers write straightforward code instead of maintaining custom state machines, cron jobs, and recovery scripts.

---

Quick Recap

You don’t need to keep a worker running—or a thread blocked—to wait days or weeks for human approval. With Temporal, you model the approval as part of a durable Workflow that uses signals and timers. The Temporal Service persists the Workflow’s state, workers wake only when needed, and your code resumes exactly where it left off after the approval or timeout. The result is reliable, human-in-the-loop execution without glue code, cron hacks, or manual recovery.

Next Step

Get Started