Step 3 - Choose the backing implementation
The contract says nothing about what runs behind an Operation. That is deliberate — it is the handler's private decision, and it can change later without touching callers.
There are three shapes to choose from, and picking the wrong one is the most common source of trouble later.
Standalone Activity
One step, no waiting, no state. Call an external API, run a computation, send a notification.
The Operation starts an Activity Execution with no parent Workflow, and completes when the Activity returns. You get retries and a durable record without a wrapper Workflow that exists only to call one Activity.
The tradeoff is that an Activity has no Workflow's ability to receive messages or hold state, and cancellation only works if the Activity heartbeats. See Nexus Standalone Activity.
Workflow
More than one step, or any need for durable intermediate state.
The Operation starts a Workflow and completes when that Workflow returns, so the Workflow's return value is the Operation's result. Use this when the work orchestrates several Activities, needs a timer, or needs to survive a Worker restart partway through.
Entity Workflow
A Workflow that represents one long-lived thing and stays available for interaction while it runs.
The distinguishing feature is that it accepts messages — Signals, Queries, and Updates — against a stable Workflow Id derived from the entity it represents. It is still a Workflow-backed Operation; "entity" describes how you use it, not a separate mechanism.
The choice for the approval Service
The approval problem needs both.
| Operation | Backing | Why |
|---|---|---|
requestApproval | Entity Workflow | Blocks for a human decision, holds the reminder count, and must accept messages while pending |
notifyRequester | Standalone Activity | One outbound notification, no state, nothing to wait for |
An approval is a textbook entity: it exists for a while, it has identity, and other systems interact with it during its lifetime. Backing it with an Activity would not work at all — an Activity cannot block for a human and cannot receive a Signal.
The notification is the opposite. It is a single side effect with nothing to orchestrate, so a Workflow would add an Event History and a Workflow Id for no benefit.
Give the entity a stable Id
An Entity Workflow needs a Workflow Id derived from the entity, not a random one, so that later messages can find it. Deriving the approval's Workflow Id from the approval id means a caller that knows the approval id can reach the right Execution.
This also makes the start idempotent. A retried Nexus start request targets the same Workflow Id rather than starting a second approval.
Next
Implement the Service with a Workflow-backed Operation.
- Nexus Standalone Activity for Activity-backed Operations.
- Workflow message passing for what makes a Workflow interactive.
- Nexus patterns for Service and Worker topology choices.