Temporal extensibility mechanisms overview
Temporal offers four main mechanisms to augment the functionality of Workflows and Activities: Data Conversion (customize serialization, compression, or encryption of arguments and return values), Context Propagation (pass custom metadata like tracing IDs, tenant IDs, or auth tokens across Workflow, Activity, and Child Workflow boundaries), Interceptors (add cross-cutting behavior such as observability, authorization, and header manipulation before and after SDK operations), and Plugins (bundle interceptors, context propagators, data converters, and built-in definitions into reusable packages).
Data Conversion customization
Data Conversion allows customization of how arguments and return values are serialized, compressed, or encrypted.
Context Propagation use cases
Context Propagation enables passing custom metadata across Workflow, Activity, and Child Workflow boundaries, with common examples being tracing IDs, tenant IDs, and authentication tokens.
Interceptors for cross-cutting behavior
Interceptors allow adding cross-cutting behavior like observability, authorization, and header manipulation before and after SDK operations.
Plugins bundle reusable components
Plugins provide a way to bundle interceptors, context propagators, data converters, and built-in definitions into reusable packages.
What interceptors are and how they work
Interceptors let you add cross-cutting behavior before and after SDK operations such as starting a Workflow, executing an Activity, or handling a Signal. They work like middleware: each interceptor wraps the next, forming a chain that executes around the underlying operation.
Common use cases for interceptors
Common use cases for interceptors include: observability (logging, metrics, tracing), authorization and authentication checks, header manipulation (propagating metadata), and input/output validation.
Nexus provides three types of metrics
Nexus provides SDK metrics (from Nexus Workers), Cloud metrics (from Temporal Cloud), and OSS Cluster metrics (from OSS Cluster infrastructure) in addition to integrated execution debugging.
Nexus Registry scope and uniqueness
The Nexus Registry manages Nexus Endpoints. In Temporal Cloud, the Registry is global across the entire Account, spanning all Namespaces. In self-hosted deployments, it is scoped to a Cluster. Endpoint names must be unique within the Registry.
Nexus Endpoint creation requires Access Policy
Creating a Nexus Endpoint includes setting an Access Policy, which is an allowlist of caller Namespaces permitted to use the Endpoint. No callers are allowed by default, even if in the same Namespace as the Endpoint target.
Nexus Endpoint editable fields
Everything except the Endpoint name can be edited after creation. New Operations route to updated targets immediately.
Changing Nexus Endpoint target Namespace pitfalls
When changing the target Namespace of a Nexus Endpoint: in-flight async Operations have completion callbacks pointing to the original handler Namespace and are unaffected, but Cancel requests route to the new target. Workflow IDs are scoped per Namespace, so Signal-With-Start creates a new Workflow in the new target even if the same ID is active in the old target, resulting in potential duplicates. The recommendation is to drain existing Nexus Operations and underlying handler Workflows before changing the target Namespace.
Nexus Registry RBAC permissions in Temporal Cloud
In Temporal Cloud, Nexus Registry respects RBAC permissions. Viewing or searching Endpoints requires a read-only role (or higher) at the Account level. Managing Endpoints requires a Developer role (or higher) and Namespace Admin on the target Namespace.
Nexus Registry automation options
Nexus Endpoint provisioning and lifecycle management can be automated using Terraform or the Operator API. Terraform is supported for Temporal Cloud. The Cloud Ops API is available for Temporal Cloud, and the Operator API is available for self-hosted deployments.
What is a Plugin and what does it bundle
A Plugin bundles multiple extensibility primitives into a single reusable package. These primitives include interceptors, context propagators, data converters, and built-in Workflow/Activity/Nexus definitions. Plugins allow platform teams and library authors to ship ready-made functionality that application developers can adopt with a single registration call.
Common use cases for Plugins
Common use cases for Plugins include AI Agent SDKs (such as OpenAI Agents, Pydantic AI, and LangGraph), observability packages (tracing, logging, and metrics), encryption or compliance middleware, and shared infrastructure integrations (messaging, payments, and LLM calls).