# Step 8 - Send messages

> Call the Signal, Query, and Update Operations from a caller Workflow, and start an approval with Signal-with-Start.

From the caller's side, the three messaging Operations are just Operations. They are called through the same generated Service stub as `requestApproval`, with the same type checking.

The caller does not know that one is a Signal, one is a Query, and one is an Update. That is the handler's implementation detail, and it can change without breaking callers.

## Nudge, check, and decide

`{sample code will be here}`

What differs between them is what you get back and how long it takes.

`remindApprover` returns nothing and completes as soon as the Signal is accepted. Accepted is not the same as handled — the Signal is durably recorded and the Workflow will process it, but the Operation does not wait for that. If the caller needs confirmation that the nudge took effect, it needs an Update, not a Signal.

`getApprovalStatus` returns the current progress immediately. Call it when something needs to report on a pending approval; do not call it in a loop waiting for the decision.

`submitDecision` returns confirmation that the decision was recorded. This is the point of using an Update: the caller learns the outcome of its own message. Once it succeeds, the approval Workflow unblocks and completes, which resolves the `requestApproval` Operation that the original caller is still awaiting.

## Start and Signal in one call

Sometimes a caller wants to start an approval and immediately attach information to it, without a race between the two calls.

Signal-with-Start does both atomically: if the target Workflow is not running it is started, and either way the Signal is delivered. It is a sync side effect on the Nexus-aware Client, reached through `client.getWorkflowClient()`, so a handler Operation can offer it directly.

This is also how you make a Signal safe to send to an approval that may not exist yet. A plain Signal to a missing Workflow fails; Signal-with-Start creates it.

`{sample code will be here}`

> **⚠️ Caution:**
> Update-with-Start is not yet available
>
> Update-with-Start — starting a Workflow and running an Update against it atomically — is not available in any SDK yet. See [Nexus SDK V2](/nexus/sdk-v2).
>
> Until it lands, an Operation that needs both must start the Workflow and then submit the Update as a separate call, which is not atomic. Signal-with-Start is available and covers the case where the caller does not need a response.
>

## You cannot re-attach to get a result

A caller that did not start an approval cannot ask Nexus for its final decision.

`requestApproval` delivers the decision to whoever awaited it. There is no Operation that attaches to an already-running approval and waits for its result, because Get Workflow Result as an async backing is [not yet available](/nexus/sdk-v2) in any SDK.

If several systems need the outcome, either have the caller that started the approval distribute it, or have the handler notify them — which is what the notification in the next step does.

## Next

[Add a Standalone Activity](/develop/java/nexus/development-walkthrough/add-a-standalone-activity) to notify the requester once a decision is final.

> **💡 Tip:**
> RESOURCES
>
> - [Sending messages](/sending-messages) for Signal, Query, and Update semantics.
> - [Nexus SDK V2](/nexus/sdk-v2) for which capabilities are available per SDK.
> - [Java Nexus feature guide](/develop/java/nexus/feature-guide) for the caller API.
>