English Vocabulary for Temporal Workflow Developers

Temporal is a durable execution platform for writing reliable, long-running workflows in code. It is used by engineering teams at companies like Netflix, Stripe, and Datadog to orchestrate complex processes — from multi-step business workflows that span days to distributed transactions that must survive infrastructure failures. Temporal has a precise and distinct vocabulary: Workflows, Activities, Signals, Queries, child workflows, and versioning concepts that are fundamental to using the platform correctly. If your team runs Temporal, mastering this vocabulary is necessary for participating in design reviews, debugging production incidents, and writing workflow code that your colleagues can maintain. This post covers the essential Temporal terms.

Key Vocabulary

Workflow A durable, deterministic function that orchestrates business logic by coordinating Activities and other Workflows. Temporal guarantees that a Workflow will execute to completion even across server restarts, crashes, and network failures. Workflow code must be deterministic — given the same event history, it must always produce the same decisions. Example: “Write the order fulfillment logic as a Temporal Workflow — if the server crashes mid-execution, Temporal will replay the Workflow history and resume exactly where it left off.”

Activity A function that performs a non-deterministic side effect — calling an external API, writing to a database, sending an email, or any other operation that interacts with the outside world. Activities are called from Workflows and are automatically retried on failure. Unlike Workflows, Activity code does not need to be deterministic. Example: “Wrap the Stripe charge call in an Activity — Activities are retried automatically on failure and they can safely make external API calls that a Workflow cannot.”

Signal An asynchronous message sent to a running Workflow that can change its state or unblock it from waiting. Signals are sent externally (from application code or another Workflow) and are received by the Workflow’s Signal handler. Signals are durable — they will be delivered even if the Workflow is sleeping. Example: “Send a cancel-order Signal to the fulfillment Workflow when the user clicks cancel — the Workflow’s Signal handler will stop the fulfillment process and trigger a refund Activity.”

Query A synchronous, read-only mechanism for inspecting the current state of a running Workflow. Queries do not modify Workflow state and are answered immediately from the Workflow’s in-memory state. Use Queries to expose progress, current step, or accumulated data from a running Workflow. Example: “Add a Query handler that returns the current step and percentage complete of the data migration Workflow — the status endpoint will call this Query every 5 seconds to show progress in the UI.”

Child workflow A Workflow started from within another Workflow. Child Workflows run independently and can be configured to continue even if the parent Workflow is cancelled. They are useful for parallelism (fan-out patterns), for breaking large Workflows into manageable units, and for reusing Workflow logic. Example: “For each order in the bulk batch, start a child Workflow to handle the individual order — child Workflows run in parallel and the parent Workflow waits for all of them to complete before proceeding.”

Schedule Temporal’s built-in mechanism for running Workflows on a recurring schedule, defined by a cron expression. Schedules replace the need for external cron jobs or scheduled tasks — Temporal manages timing, handles missed runs, and provides a history of scheduled executions. Example: “Create a Temporal Schedule with a 0 3 * * * cron expression to run the nightly reconciliation Workflow at 3 AM — you can view and manage it from the Temporal web UI without touching any infrastructure.”

Workflow versioning The mechanism for safely changing Workflow code that is currently running in production. Because Temporal replays Workflow history to reconstruct state, changing Workflow logic can cause non-determinism errors for in-flight Workflows. Versioning (via workflow.getVersion() or the Patching API) lets you introduce changes without breaking existing runs. Example: “Use workflow.getVersion() to introduce the new payment retry logic — in-flight Workflows will follow the old path, new Workflows will follow the new path, and once all old Workflows complete you can remove the version branch.”

Temporal Cloud Temporal’s fully managed SaaS offering, which runs the Temporal server infrastructure (scheduling, persistence, history storage) on Temporal’s infrastructure rather than your own. Teams use Temporal Cloud to avoid operating Temporal’s server, Cassandra database, and Elasticsearch cluster themselves. Example: “We migrated from self-hosted Temporal to Temporal Cloud last quarter — we eliminated the Cassandra operational burden and the engineering team focuses entirely on Workflow code instead of infrastructure.”

How to Use This Vocabulary

Temporal design discussions center on the separation between Workflow logic (orchestration, state, decisions) and Activity logic (side effects, external calls). A common review comment is “this external API call should be in an Activity, not directly in the Workflow” — because Workflow code must be deterministic and external calls are not.

Signal and Query discussions come up when building Workflows that need to interact with user-facing systems. Teams discuss “what Signals does this Workflow need to receive?” and “what Queries should we expose for the status API?” Versioning is a recurring topic whenever a long-running Workflow needs to be updated — the discipline of “always use getVersion when changing Workflow logic” is a standard Temporal best practice.

Example Conversation

Vera: I need to update the payment retry logic in the refund Workflow. It’s been running for some orders for 3 days. Omar: Don’t change the Workflow code directly — you’ll cause non-determinism errors for in-flight runs. Use workflow versioning. Vera: Right — I’ll use getVersion to branch on the new logic. Old runs keep the old path. Omar: Exactly. Also add a Query handler so the support team can check the retry count without looking at the database.

Practice

1. Explain the difference between a Workflow and an Activity to a developer who is new to Temporal. Use an analogy (e.g., a project manager vs. a contractor) and then map it back to the technical concepts of determinism and side effects.
2. Design a Temporal Workflow for a user account deletion process: the Workflow should send a farewell email (Activity), wait for a 14-day cooling-off period, check if the user re-activated (Query), and then delete the account (Activity). Identify where you would use Signals, Queries, and Activities.
3. Explain workflow versioning to a colleague using the metaphor of a running assembly line. Why can’t you just change the code and redeploy? What problem does getVersion solve?