Choosing a Nexus approach
Workflows and Activities provide durable execution. An Activity that runs without a Workflow is a Standalone Activity.
Nexus exposes capabilities through a service contract, with durable communication and controlled access across Namespace boundaries.
Two options remove a Workflow from either end of a Nexus call. Standalone Nexus Operations (SANO) let applications call a service without a caller Workflow. Nexus Standalone Activities (SAA) let a service execute a single durable action without a handler Workflow.
Nexus is Generally Available. Standalone Nexus Operations and Nexus Standalone Activities are currently in Pre-release. APIs are experimental and may be subject to backwards-incompatible changes.
When to use Workflows vs Nexus vs SANO vs SAA
| Capability | When to use it | Example |
|---|---|---|
| Start a Workflow directly | The application owns the process and can depend on its Workflow API. The same team invokes and owns the Workflow. | An order application starts its own fulfillment Workflow. |
| Expose a Nexus Service Interface | Other teams want to call your application using clean contracts. | A billing team exposes ChargeCustomer for other teams to consume. |
| Call Nexus from a Workflow | The process orchestrates multiple Nexus Operations across Namespace boundaries. | An order Workflow reserves inventory, calls billing, and arranges shipping. |
| Use a Standalone Nexus Operation (SANO) (Pre-release) | An application, script, or gateway needs to invoke a Nexus Service with minimal overhead and no multi-step orchestration requirements. | An admin application, which is not implemented on Temporal, calls ProvisionAccount through Nexus. |
| Use a Nexus Standalone Activity (SAA) (Pre-release) | A Service Operation performs one durable action and needs Activity retries and timeouts. | The ChargeCustomer Nexus Operation uses a Nexus Standalone Activity so that the Stripe API call can be made durably. |
Decide whether you need a service boundary
Starting a Workflow or Standalone Activity directly already provides durability.
Use Nexus when callers should depend on a business capability, such as ProvisionAccount, while the service owner controls its implementation.
Callers use the service contract without needing to know its Workflow IDs, Task Queues, or backing implementation.
This is particularly useful across teams and isolated Namespaces.
Choose how to call the Nexus Service
- Call from a Workflow when the caller needs durable business logic, coordination, or state. An existing Workflow can also call a single Nexus Operation.
- Use a Standalone Nexus Operation when code outside a Workflow needs to invoke the service. The called Operation can still run a complex Workflow; a Standalone Nexus Operation removes only the need for a caller Workflow. That is, when the Nexus Operation is the only work you need to do, and there is no other processing required.
- An HTTP endpoint or webhook receiver can use a Standalone Nexus Operation through an adapter that makes the SDK Client call. A Standalone Nexus Operation does not itself provide a public HTTP endpoint.
Choose how to implement the Nexus Operation
- Use a Workflow when the Operation needs multiple steps, durable intermediate state, timers, or coordination.
- Use a Nexus Standalone Activity when the Operation performs one durable action, such as calling a third-party API, writing to another system, or running a computation.
These choices work together. For example, an existing checkout application can use a Standalone Nexus Operation to call a Nexus billing service implemented with a Nexus Standalone Activity. An order Workflow can call that same service as part of a larger process.