Check an action result
Read the receipt, not the confirmation toast, to know whether an action finished.
Updated September 27, 2026 3 min read
After preparing or approving an action, your next decision depends on whether it completed. A receipt is the saved record of that outcome. Read it alongside the source screen to distinguish a prepared draft, a completed internal change and a provider response.
Understand the difference
| State | What it tells you | Next step |
|---|---|---|
| Prepared or pending review | A proposal exists | Review its target and content |
| Approved | The action was authorized | Check execution status |
| Failed or unfinished | Work did not reach a confirmed successful outcome | Read the reason and recovery option |
| Send accepted | The provider accepted the message | Check delivery status when available |
| Delivered | A delivery event was recorded | Continue the conversation as needed |
Exact labels vary by screen and provider. Look at what the receipt confirms, not just whether something is green.
Find the supporting evidence
Start at the action or conversation where you did the work, and check its result there first. Activity is where you go next to understand what else changed around it, and Setup is where to look when one provider connection seems to be failing across several different actions at once.
When the screen looks out of date
Today can keep showing its last successfully loaded queue if a refresh fails, so an old row sitting there is a sign to check the refresh status, not proof that the underlying action needs to run again. Look at the last-success time before you conclude anything is stuck.
When an action's result is uncertain, look at the original request before you submit a new one. A retry should reuse that original request's identity, so the same intended effect cannot happen twice by accident. If you need help, hand your workspace administrator the action identifier and the exact error you saw rather than a description of it.
What happens when work times out
A time limit stops the worker from waiting longer, but that says nothing about whether the external service itself cancelled the request. The work engine records that uncertainty honestly, as failed work with a receipt-reconciliation reason and no automatic retry, because a late completion arriving after the timeout cannot retroactively turn that work record into a confirmed success.
Check the linked action and its provider receipt before you retry it by hand. If the provider confirms the work completed, keep that receipt as your answer instead of sending again; if the outcome is still unknown, leave the item held for review rather than guessing. The engine's own failure circuit can pause further work of the same kind inside one running process, but the saved work record is what keeps that hold in place across a restart.