Correct and send back
When something is wrong, fix it. Your correction is recorded, and the system learns from it for next time. Nothing changes without your review.
Audience: business users
When to correct, when to approve, when to rerun
Pick the path that fits what you saw on the Review tab.
- Approve. The output is right. Move on; no extra step is needed. The Workflow publishes the result through its trigger (a reply email, a Slack message, a row written to the system of record).
- Correct. The output is close but wrong in a specific way. Open a conversation about the work item and say what to change.
- Rerun. The run got stuck or failed for a reason unrelated to the reasoning (a network blip, a missing credential at the moment, an upstream system that came back online). Use Rerun on the work item's actions row.
If you are not sure, start a conversation. You can always Rerun afterwards.
Open the review conversation
In the work item's actions row at the bottom of the detail pane, click Discuss this. The button becomes available once the run has finished (Completed, Failed, or Cancelled).
Discuss this
Click Discuss this. A new thread opens scoped to this specific work item.
Say what is wrong
Type your correction in the composer at the bottom. Be specific: name the field, the row, the number, the customer. "The invoice total should be 4,820.00, not 4,280.00" beats "the amount is off".
Watch the work happen
The activity stream shows what happens in response. Your Project can re-read the source files, recompute the result, draft a different reply, or ask you a clarifying question.
Confirm or keep iterating
When the corrected output comes back, read it. If it is right, say so. If it is still off, keep going. The conversation is yours until you close it.
If a conversation already exists for this work item, the button reads Open conversation instead. Clicking it picks up where you left off, with the full history available.
How your correction reaches the system
Corrections do not just patch the one work item. They become signals the system can learn from.
- Project memories. When you teach a rule in the conversation ("always use the customer's primary contact, not the billing contact"), the agent can save it as a Project memory if you are a builder on the Project. Builders write Project memories directly, with no review step. A member's conversation cannot change Project memories, so ask a builder to save a rule you want kept.
- The next run benefits. Because memories are part of the Workflow's context, every subsequent work item the Workflow handles has access to the rule you taught. See Project Memories.
Your corrections are recorded. Every conversation, every memory change, and every rerun is captured in the audit trail. A workspace admin can open it from Audit and filter by the Project.
After you correct
The work item's record is updated to reflect the latest run. The Review tab refreshes with the new outputs. The Metadata section shows the new Updated and Completed timestamps and the latest task identifier.
If a builder saved a memory based on what you taught, the rule is part of the Workflow's context from that moment on.
What if I do not see what I want?
A dedicated "Send back with a reason" control is not part of this surface today. The review conversation is how you push back: it gives your reason, the context, and the chance to fix the work item in place. If a follow-up surface for explicit reject-and-route arrives later, it will land in this section.