English for Temporal Workflows

Temporal solves a problem most developers have hacked around badly for years — reliably running a long, multi-step process across failures and restarts — and its vocabulary is precise in ways that matter for correctness, not just style.

Key Vocabulary

Durable execution — Temporal’s core guarantee that a workflow’s progress and state survive process crashes, deployments, and restarts, resuming exactly where it left off rather than starting over or losing state. “We don’t need to build our own retry and checkpoint logic for this multi-day process — durable execution means Temporal automatically resumes the workflow exactly where it left off, even if the worker process crashed halfway through.”

Workflow — the orchestration code defining the sequence of steps in a process, written as ordinary code but executed by Temporal in a way that’s deterministic and replayable, distinct from the activities that do the actual work. “The workflow itself just orchestrates the order of steps — it calls out to activities to do the actual work like charging a card or sending an email, the workflow code itself should stay free of side effects.”

Activity — a unit of actual work with real side effects, like an API call or a database write, invoked from within a workflow, and independently retried by Temporal if it fails without needing custom retry logic. “Charging the customer’s card should be a separate activity, not inline workflow code — that way if the payment API call times out, Temporal retries just that activity according to our retry policy, without rerunning the whole workflow from scratch.”

Replay — Temporal’s mechanism for reconstructing a workflow’s current state after a crash by re-executing its history of events, which is why workflow code must be deterministic — the same inputs must always produce the same sequence of decisions. “This bug happened because the workflow code called a random number generator directly — during replay, that produces a different result than the first execution, and Temporal detected the non-determinism and failed the workflow.”

Signal — an external message sent into a running workflow to affect its behavior, such as canceling an order or approving a step, allowing a long-running workflow to react to events that happen after it started. “We’re not polling for the approval — the workflow just waits, and when a manager approves the request in the UI, that sends a signal into the running workflow, which then continues to the next step.”

Common Phrases

• “Is this durable execution actually guaranteeing recovery here, or are we still relying on manual retries somewhere?”
• “Should this logic live in the workflow, or does it belong in an activity?”
• “Is this workflow code deterministic enough to survive a replay?”
• “Could we use a signal here instead of polling for external events?”
• “What’s the retry policy on this specific activity?”

Example Sentences

Explaining the core value proposition: “The reason we moved this order fulfillment process to Temporal is durable execution — previously, if our service crashed mid-process, we’d lose track of which step an order was on. Now the workflow just resumes exactly where it left off.”

Correcting a design mistake: “This external API call needs to be its own activity, not inline in the workflow — if it fails, we want Temporal retrying just that call according to a defined retry policy, not replaying the entire workflow’s history from the start.”

Debugging a determinism issue: “This workflow failed during replay because the code reads the current system time directly, which gives a different value on replay than it did originally — we need to use Temporal’s deterministic time API here instead.”

Professional Tips

• Lead with durable execution when explaining why Temporal was adopted — it’s the single property that eliminates a whole category of hand-rolled retry and checkpoint code.
• Keep the workflow function itself free of side effects and non-determinism — all actual work, like API calls or database writes, belongs in an activity.
• Understand replay deeply before writing workflow code — any source of non-determinism, like random numbers, current time, or unordered map iteration, will eventually cause a replay failure.
• Use a signal for anything a running workflow needs to react to externally, like approval or cancellation, rather than building a custom polling loop.
• Set explicit, workload-appropriate retry policies on each activity — the default retry behavior isn’t always right for every kind of external call.

Practice Exercise

1. Explain the difference between what belongs in a workflow versus an activity.
2. Describe why workflow code needs to be deterministic, referencing replay.
3. Write a sentence explaining how a signal lets a workflow react to an external event.