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: analysts
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 App 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 top of the detail pane, click Start Conversation. The button becomes available once the run has finished (Succeeded, Failed, or Cancelled).
Start Conversation
Click Start Conversation. A new thread opens scoped to this specific work item and brings you to the Conversations tab.
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.
- Memory candidates. When you teach a rule in the conversation ("always use the customer's primary contact, not the billing contact"), your Project can propose a new memory. Memories are submitted as candidates for review and become part of the App's shared context once approved. You will see a "memory candidate submitted" card in the conversation when this happens.
- The next run benefits. Because memories are part of the App's context, every subsequent work item the App handles has access to the rule you taught. See Memories you own.
Your corrections are recorded. Every conversation, every approved memory, and every rerun is captured in the audit trail. You can open it from the work item's Open Audit button.
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 memory was proposed based on what you taught, an admin in your workspace reviews the candidate and approves it. From that moment on, the rule is part of the App's context.
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.