AI Workflows for Structured Approvals: How to Automate an Approval Process Without Losing Human Control

Most approval processes fail not because the approvers are slow, but because the process around them is invisible. A draft gets emailed to a reviewer. The reviewer replies with comments. The author revises and resends. Someone else needs to sign off too, but nobody told the system. The final approved version lives in an email thread that three people have archived differently. Six weeks later, nobody can reconstruct what was approved, when, or by whom.

This is not a people problem. It is a structure problem. The approval process exists, but it lives in human memory and email conventions rather than in a system that can enforce it, track it, and report on it. When you move approval into a structured workflow, every one of those failure modes disappears: the system knows who needs to approve, what they are approving, what their options are, and what happens next depending on their decision.

The addition of AI to this structure creates a further division of labor. AI handles the generative or analytical work that produces the thing to be approved. The workflow routes that output to the right human at the right moment. The human makes the judgment call. The workflow records the decision and continues. Each party does what they are actually good at, and the system holds the whole process together.

The result is an approval process that is faster because humans are not waiting for information to be assembled, more consistent because every approval follows the same path, and fully auditable because every decision is recorded with context, timestamp, and actor.

In DAVE, the mechanism that pauses a workflow for human input is called a task. A task is a discrete work item generated by a running workflow instance when execution reaches an interaction or review node. The workflow stops at that node, creates a task, assigns it to the designated user, and waits. The instance does not continue until the task is completed.

Tasks appear in the assignee's Task Inbox, accessible from the Tasks link in the sidebar. The inbox shows every task assigned to the user across all workflow instances, with columns for task type, status, the parent instance, the assignee, and the due date. Status filters let the assignee focus on pending tasks that need action.

Each task has a payload: a JSON object passed from the workflow to the task, containing the data the assignee needs to make a decision. In an approval workflow, the payload typically contains the AI-generated content or output that is being submitted for review. The assignee reads the payload on the task detail page, then chooses one of three decisions: Approve, Reject, or Request Changes. An optional comment field lets the reviewer explain their reasoning, which is especially important for rejections and change requests.

The decision is not just a record. It is a routing instruction. The workflow graph has outgoing edges from the review node corresponding to each possible decision. When the reviewer clicks Approve, the instance follows the Approve edge. When they click Reject, it follows the Reject edge. This means the approval decision directly determines what the workflow does next: publish, discard, loop back for revision, or escalate to a second reviewer.

Four task types are available, each suited to a different kind of human checkpoint:

• User Interaction (user_interaction): the human provides input or content the workflow needs to continue. Used at the start of a workflow to collect a brief, or mid-workflow to gather additional information.
• Human Review (human_review): the human evaluates content or output and renders a judgment. The primary task type for approval checkpoints.
• Agent Review (agent_review): the human reviews output that was produced by an AI agent, with the option to approve, reject, or request changes before the agent's output is used downstream.
• Safety Check (safety_check): the human evaluates content against safety or compliance criteria before the workflow proceeds.

Task statuses track the lifecycle of each work item: pending (waiting for action), in_progress (opened or claimed), completed (decision submitted), failed (timed out or errored), and cancelled (parent instance cancelled or task superseded). Every status transition is recorded in the audit trail.

Structured approval workflows are not one-size-fits-all. The right pattern depends on the complexity of the content being approved, the number of reviewers involved, and the consequences of an incorrect approval. Here are three patterns that cover the majority of real-world approval use cases.

Pattern 1: Single-stage AI-generate-then-approve

The simplest approval workflow: an AI agent generates content or a document, and a single human reviewer approves or rejects it before it is published or delivered. The workflow graph has four nodes: Start, Agent Interaction (AI generates the content), Human Review (reviewer approves or rejects), End. If the reviewer approves, the workflow routes to End and the content is delivered. If they reject, the workflow routes to a different End node or loops back to the Agent Interaction node with the reviewer's comment as additional context for regeneration.

This pattern is appropriate when: the AI output is well-scoped and the reviewer has clear criteria for approval; the content is low-to-medium risk; and a single reviewer has the authority to approve without escalation.

Pattern 2: Multi-stage review with escalation

A more complex pattern for higher-risk approvals: the AI generates content, a first reviewer does a quality check, and a second reviewer (a senior approver or compliance officer) does a final sign-off. The workflow graph adds a second Human Review node after the first. If the first reviewer approves, the instance routes to the second reviewer's task. If the first reviewer requests changes, the instance loops back to the AI agent with the comment. If the second reviewer rejects, the instance routes to an escalation path.

This pattern is appropriate when: the content has regulatory, legal, or reputational implications; a single reviewer does not have full authority to approve; or the organization's compliance policy requires a second set of eyes on AI-generated output.

Pattern 3: Safety-gated publication

A pattern specifically for content that must pass a safety or compliance check before it can be used externally. The workflow adds a Safety Check node after the AI generation step and before the Human Review node. The Safety Check task is assigned to a compliance reviewer who evaluates the content against defined criteria. Only if the safety check passes does the content route to the standard Human Review approval step. If the safety check fails, the content is rejected without reaching the approver.

This pattern is appropriate when: the content will be published externally or sent to customers; the organization operates in a regulated industry; or the AI model being used has known tendencies to produce content that requires compliance review.

Every task operation in DAVE is recorded in the audit trail. Task completion events capture the acting user, the decision made (Approve, Reject, or Request Changes), and the timestamp. Assignment changes are logged. Submission data, including the payload and the submitted result, is captured with sensitive fields redacted. These events support SOC 2 CC6.1 (logical access) and GDPR Article 30 (processing records) when those compliance standards are active on the tenant.

For approval workflows specifically, this means the audit trail answers the questions that matter in a compliance review or a dispute: who approved this content, when did they approve it, what did they see when they made the decision, and what happened to the workflow after they approved it. The answer to every one of those questions is in the audit log, tied to a specific task ID, instance ID, and user ID.

Role-based access control governs who can see and act on tasks. The Task Inbox and task detail pages are accessible to users with the Admin role and the Use role. Users with other roles, including Create, Curate, and Reporting, cannot access the Task Inbox. This means approval tasks are visible only to the people who are supposed to act on them, not to the whole team.

Due dates and timeouts add a further governance layer. Tasks can be configured with a due date, displayed in the task list and detail view. A task that is not completed before its timeout may be automatically failed or escalated by the system, preventing approval bottlenecks from silently stalling a workflow indefinitely. The failed status is recorded in the audit trail, making it visible that a deadline was missed.

Comments are the human-readable layer of the audit trail. When a reviewer rejects content or requests changes, a comment explaining the reasoning is attached to the task record. That comment is part of the submitted result and is preserved in the audit log. Over time, the pattern of comments on rejected tasks becomes a dataset for improving the AI agents that generate the content: if the same type of content is consistently rejected for the same reason, the agent's instructions can be refined.

The technical structure of an approval workflow is only half the design problem. The other half is making the workflow easy enough for reviewers to use consistently. An approval workflow that is technically correct but practically cumbersome will be bypassed: reviewers will find workarounds, approvals will happen outside the system, and the audit trail will be incomplete.

Four design principles make approval workflows that humans actually use.

Put everything the reviewer needs in the payload. The task payload is the only information the reviewer sees on the task detail page. If the reviewer needs context beyond the AI-generated content itself (the original brief, the target audience, the publication deadline, the compliance criteria), that context should be in the payload. A reviewer who has to leave the task to find context will slow down, make errors, or skip the task entirely.

Make the decision options unambiguous. The three decision options (Approve, Reject, Request Changes) cover most approval scenarios, but the workflow design should make it clear what each option means in context. A comment prompt or a payload field that explains the criteria for approval removes ambiguity and produces more consistent decisions across reviewers.

Set due dates for time-sensitive approvals. A task without a due date has no urgency signal. For approval workflows tied to publication schedules, client deadlines, or compliance windows, set a due date on the task. The due date is visible in the Task Inbox list view, giving reviewers a clear priority signal without requiring a separate notification system.

Use comments as a feedback loop, not just a record. Encourage reviewers to add comments on every non-approval decision. The comment is not just for the audit trail: it is the signal that tells the workflow owner (and eventually the AI agent) why the content was not approved. A workflow that captures structured rejection reasons over time gives the team the data to improve the AI output and reduce the rejection rate, making the approval process faster for everyone.

Does automating an approval process mean the AI makes the approval decision?
No. In a structured AI approval workflow, the AI generates or processes the content that is being submitted for approval. The approval decision itself is always made by a human, using the Approve, Reject, or Request Changes buttons on the task detail page. The AI does not have access to the decision buttons and cannot complete a Human Review or Safety Check task.

What happens to the workflow if a reviewer rejects the content?
The workflow follows the outgoing edge from the review node that corresponds to the Reject decision. The workflow designer configures what that edge leads to: it could loop back to the AI agent with the reviewer's comment as additional context, route to a different agent for revision, or end the instance. The reviewer's decision directly determines the next step.

Can the same person both generate content and approve it?
Technically, a user with the Admin role can both trigger a workflow instance and complete a task on that instance. Whether this is appropriate depends on the organization's governance policy. For regulated content, the workflow should be designed so that the person who initiates the workflow is not the person who approves the output: this is the separation of duties principle. DAVE's role system supports this by allowing task assignment to specific users or roles.

What happens if a reviewer does not complete a task before the deadline?
A task that is not completed before its configured timeout may be automatically failed or escalated by the system. The failed status is recorded in the audit trail. The workflow owner can see the failed task in the Task Inbox (using the failed status filter) and take action: reassigning the task, restarting the instance, or contacting the reviewer directly.

Who can see the tasks in the Task Inbox?
The Task Inbox is accessible to users with the Admin role and the Use role. Users with the Create, Curate, Reporting, or Financial roles cannot access the Task Inbox. Only the assigned user (and Admins) can complete a task.

Is the approval decision recorded for compliance purposes?
Yes. Every task completion event is recorded in the DAVE audit trail with the acting user, the decision, and the timestamp. When SOC 2 or GDPR compliance modes are active on the tenant, these events support SOC 2 CC6.1 and GDPR Article 30 requirements. The audit trail is accessible to Admin role users at Admin, then Settings, then Audit Log.