Designing a Reject Reason People Actually Read

When a workflow instance reaches a Human Review node, DAVE creates a task in the Task Inbox. The reviewer navigates to Tasks in the sidebar, opens the task, reads the Payload section (the JSON data passed from the workflow, containing the content to review and any upstream context), and then makes a decision.

The decision panel at the bottom of the task detail page has three buttons:

• Approve (green): the content meets requirements and the workflow continues on the approval path.
• Reject (red): the content is unacceptable and the workflow continues on the rejection path.
• Request Changes (outlined): the content needs revision before it can be approved.

Above those buttons is a Comment text area. The DAVE help documentation is explicit: the comment is especially important for Reject and Request Changes decisions, so that downstream users and the workflow owner understand the rationale. The comment travels with the task. It appears in the Submitted Result JSON recorded when the task completes, which means it is available to every downstream node in the workflow, to the workflow owner reviewing the instance, and to the audit trail that logs the decision with the reviewer's identity.

The comment is the only structured channel for that information. There is no separate rejection form, no category selector, no severity field. What the reviewer types into the Comment field is what the workflow, the workflow owner, and the audit record receive. That makes the quality of the comment a workflow design concern, not just a reviewer etiquette concern.

Task access requires the Admin or Use role. DAVE ships with six default tenant roles (Admin, Create, Curate, Use, Reporting, and Financial), all editable by your administrator.

A useful reject reason has three parts. Each part does a specific job. All three together give the recipient everything they need to act without asking a follow-up question.

Part 1: Name the specific problem

Not the category of problem. The specific problem. "Tone is wrong" is a category. "The opening paragraph uses first-person plural ('we') but this workflow is configured to produce content in second-person ('you')" is a specific problem. The difference is that the second version tells the recipient exactly what to fix without requiring them to re-read the entire output looking for the issue.

Specific problems also produce better audit records. When a workflow owner reviews a series of rejected tasks to understand why an agent keeps failing the same review step, specific reject reasons let them identify the pattern. "Tone is wrong" repeated ten times tells them nothing. "First-person plural in the opening paragraph" repeated ten times tells them the agent's system prompt needs a constraint on person and voice.

Part 2: Point to the specific location

If the problem is in a specific section, sentence, or field, say which one. "Section 2, second paragraph" or "the meta description field" or "the third bullet point in the recommendations list" is faster to act on than "somewhere in the middle." When the payload contains structured JSON, reference the field name. When the payload contains long-form content, reference the heading or paragraph position.

Location information is especially important when the reject reason will be used by an automated downstream step rather than a human. If the workflow routes a Reject decision to an Agent Interaction node that attempts to fix the problem, the agent's ability to make a targeted fix depends entirely on the specificity of the reject reason in the payload it receives.

Part 3: Describe what a passing version looks like

This is the part most reviewers skip, and it is the part that does the most work. "The tone should be formal and third-person throughout" gives the next step a target. "The meta description should be under 155 characters and end with a call to action" gives the next step a target. "The recommendations should be ranked by implementation effort, lowest first" gives the next step a target.

Without a description of the passing state, the recipient knows what failed but not what success looks like. They make their best guess, resubmit, and the workflow creates another review task. With a description of the passing state, the next attempt has a specific target to hit.

DAVE gives reviewers two ways to send content back: Reject and Request Changes. They look similar and both require a comment to be useful, but they send different signals to the workflow and to the people watching it.

When to use Reject

Reject is the right choice when the content is fundamentally wrong in a way that cannot be fixed by revision: the wrong topic, the wrong format, a factual error that invalidates the entire output, a safety issue, or a structural failure that would require starting over. Reject tells the workflow that this version is not a candidate for approval. The workflow routes to the rejection path, which in a well-designed workflow leads to a different outcome than a revision loop: a notification to the workflow owner, a new Agent Interaction node with a different prompt, or a manual intervention step.

A Reject comment should be direct about why the content cannot be revised into an acceptable state: "This output addresses the wrong audience. The workflow was configured to produce content for technical decision-makers, but this reads as a consumer explainer. A revision of this draft cannot fix that; the agent needs to regenerate from the brief."

When to use Request Changes

Request Changes is the right choice when the content is on the right track but needs specific improvements before it can be approved. The structure is correct, the topic is right, the format is appropriate, but one or more elements need revision. Request Changes tells the workflow that this version is a candidate for approval after revision. The workflow routes to the revision path, which typically leads back to an Agent Interaction node or a User Interaction node for a targeted fix.

A Request Changes comment should be a specific, actionable list: "Three changes needed before approval: (1) Shorten the introduction to two sentences. (2) Replace the passive voice in the third paragraph with active voice. (3) Add a specific call to action in the final sentence." The numbered list format is not required by the platform, but it makes the comment easier to act on and easier to verify when the revised version comes back for review.

The workflow design implication

The distinction between Reject and Request Changes only produces value if the workflow is designed to route them differently. If both decisions lead to the same downstream path, reviewers have no reason to distinguish between them, and the signal is lost. When you design a workflow that includes a Human Review node, design separate outgoing edges for Approve, Reject, and Request Changes, and connect them to meaningfully different next steps.

The most important shift in how to think about reject reasons is this: the comment is not notes for a human reader. It is structured input to the workflow.

When a reviewer submits a Reject or Request Changes decision, the task's Submitted Result JSON is recorded and becomes available to downstream workflow nodes. If the workflow routes the rejection to an Agent Interaction node that attempts to fix the problem, that agent receives the payload from the original task and the submitted result from the review task, including the comment. The agent's ability to make a targeted, correct fix depends on the quality of the comment it receives as input.

This has a practical implication for how reviewer training should frame the comment field. It is not "leave a note so the workflow owner knows what happened." It is "write the instruction that tells the next step exactly what to fix." The audience for the comment is not just a human reading the audit trail: it may be an AI agent that will attempt to act on it directly.

For workflows where the rejection path leads to an automated fix attempt, the comment format matters. A comment structured as a numbered list of specific changes is easier for an agent to parse and act on than a paragraph of narrative feedback. If your workflow uses this pattern, document the expected comment format in the Human Review node's payload so reviewers know what structure to use. The payload is the only in-product channel for that instruction: there is no separate reviewer briefing field in the task UI.

For workflows where the rejection path leads to a human (a workflow owner, a content creator, or a different reviewer), narrative feedback is fine, but the three-part structure (specific problem, specific location, passing state) still applies. The audience changes; the structure does not.

Individual reviewers left to their own devices produce wildly inconsistent reject reasons. One reviewer writes three sentences with a specific location and a passing state. Another writes "needs work." Both click Reject. Both decisions are recorded in the audit trail with equal weight. The difference only becomes visible when the workflow owner tries to understand why the agent keeps failing the same review step, or when a compliance auditor asks for evidence that reviews were substantive.

Consistency comes from three sources: a shared format, a shared standard, and feedback loops.

A shared format

Give your reviewers a template they can fill in rather than a blank text area they have to fill from scratch. A simple template works: "Problem: [specific issue]. Location: [where in the content]. Passing state: [what a correct version looks like]." Post it in your team's documentation. Reference it in onboarding. The template does not need to be enforced by the platform: it just needs to be the default that reviewers reach for.

A shared standard

Reviewers cannot write specific reject reasons if they do not have a specific standard to reject against. Before a workflow goes into production, document the acceptance criteria for every Human Review step. What does a passing version look like? What are the specific conditions that trigger a Reject versus a Request Changes? The more explicit the criteria, the more consistent the reject reasons, and the more useful the audit record.

Feedback loops

Review the Submitted Result records for completed tasks regularly. When a reject reason is vague, follow up with the reviewer and explain what a more specific version would have said. When an agent keeps failing the same review step, look at the reject reasons across those failures: if they are consistent and specific, the problem is in the agent configuration; if they are vague and inconsistent, the problem is in the review standard. The audit trail, accessible at Admin → Settings → Audit Log, records every task completion with the acting user's identity, which makes it possible to identify patterns by reviewer as well as by workflow step.