# Step 7 - Add messaging

> Expose Signal, Query, and Update on the approval Workflow as Nexus Operations using the Nexus-aware Client.

The approval blocks waiting for a decision. Now give callers a way to interact with it while it waits.

Three Operations get added, one per [message](/sending-messages) type. Which message type to use is determined by what the caller needs back, not by preference.

| Operation | Message type | Why this type |
| --- | --- | --- |
| `remindApprover` | Signal | Fire-and-forget. The caller does not need a response, only for the nudge to happen. |
| `getApprovalStatus` | Query | Reads state without changing it. Never blocks, never writes. |
| `submitDecision` | Update | Changes state *and* returns a result the caller needs — confirmation the decision was recorded. |

## Add the handlers to the Workflow

On the Workflow, add a Signal handler that increments the reminder count, a Query handler that returns the current progress, and an Update handler that records the decision and unblocks the wait.

The Update is what ends the approval. It records `APPROVED` or `DENIED`, which satisfies the condition the Workflow is blocked on, and the Workflow then returns that decision as its result.

`{sample code will be here}`

Two constraints apply to the Query handler. It must not block, and it must not mutate Workflow state — a Query is served by replaying history, so anything it changes is invisible and anything it waits on stalls the Query. Return only what is already in memory.

## Expose them as Nexus Operations

These use `TemporalOperationHandler`, and they divide along the line described in [Nexus SDK V2](/nexus/sdk-v2#the-nexus-aware-client): Signal is **sync messaging**, and Update is an **async backing**.

### Signal

Reach it through `client.getWorkflowClient()` on the Nexus-aware Client, then return `TemporalOperationResult.sync(...)`. The Operation completes immediately, during the handler call.

You can send as many messages as you want in one handler. Using the injected Client rather than your own is what gets the message linked back to the caller.

`{sample code will be here}`

### Update

Use `client.startWorkflowUpdate(...)`, which is an async backing: the Operation completes when the Update completes, and its result is delivered through the Nexus completion callback. If the Update happens to come back already complete — a retried request, or one that failed validation — the result returns synchronously instead.

Because it is an async backing, there is at most one per Operation invocation. A handler can still combine it with sync side effects.

`{sample code will be here}`

> **⚠️ Caution:**
> Query is not in the pre-release
>
> `getApprovalStatus` belongs in the contract, but Query is not available as sync messaging on the Nexus-aware Client in the pre-release, so this Operation cannot be implemented yet. See [Nexus SDK V2](/nexus/sdk-v2).
>
> Adding the Query handler to the Workflow is still worth doing — it costs nothing and the Operation can be wired up once Query lands. Until then, a caller that needs in-flight progress has to obtain it outside this Service.
>

## Keep the responsibilities separate

It is worth restating why there are three Operations rather than one flexible one, because collapsing them is a common mistake.

`getApprovalStatus` reports **in-flight progress only** — whether a decision is still pending, and how many reminders have gone out. It does not return the final decision. The decision is the result of `requestApproval`, which the caller is already awaiting from [step 6](/develop/java/nexus/development-walkthrough/call-the-service).

Using a Query to fetch the outcome would mean polling for something that is already being pushed, and it would break once the [Retention Period](/temporal-service/temporal-server#retention-period) expires and the history the Query replays is gone.

## Next

[Send messages](/develop/java/nexus/development-walkthrough/send-messages) from the caller.

> **💡 Tip:**
> RESOURCES
>
> - [Workflow message passing](/encyclopedia/workflow-message-passing) for Signals, Queries, and Updates.
> - [Handling messages](/handling-messages) for handler constraints, including Query restrictions.
> - [Nexus SDK V2](/nexus/sdk-v2) for the sync side effect and async backing distinction.
>