Contract Review Workflow: Example Framework

This contract review framework moves a submitted contract through five stages:

1. Submission: A User Interaction node collects the contract text or key contract details from the submitting party.
2. Safety screen: A Safety node checks the submitted content for policy violations before any agent processes it. The Safety node's guardrails propagate to every downstream agent call.
3. AI analysis: An Agent Interaction node reads the contract and extracts key clauses, identifies risk factors, and produces a structured analysis summary.
4. Agent quality check: An Agent Review node evaluates the analysis for completeness and coherence before it reaches the human reviewer, ensuring the reviewer always receives a well-formed summary.
5. Legal review and decision: A Human Review node presents the contract and the AI analysis to a legal reviewer, who makes one of three decisions: approve, redline, or reject.

The three decision paths are:

• Approve: The contract is accepted as submitted. The instance routes to an End node marking the contract as approved.
• Redline: The reviewer has identified clauses requiring revision. An Agent Interaction node drafts a redline summary based on the reviewer's comments. A second Human Review node lets the reviewer confirm the redline before it is issued.
• Reject: The contract is declined. The instance routes directly to an End node marking the contract as rejected, with the reviewer's rejection reason captured in the instance context.

All paths terminate at a named End node. Distinct End node labels make outcomes distinguishable in reporting.

Build the following nodes in the Workflow Editor. Drag each from the Node Palette, drop it on the canvas, rename it in the Properties Panel, and connect edges in the order shown. All edges run from the source handle (bottom) of the upstream node to the target handle (top) of the downstream node.

1. Start

Type: Start (green play icon). Label: "Start". No configuration required. Every workflow requires exactly one Start node.

2. Submit Contract (User Interaction)

Type: User Interaction (blue user icon). Label: "Submit Contract". Fields section: Configure fields to capture the contract text or a structured summary of key contract terms, the contract type (for example: vendor, employment, NDA, SaaS), the counterparty name, and the submitter's name and contact details. These fields populate the instance context for all downstream nodes. User Assignment: Assign to the submitting party or leave open to any authenticated workspace member with the Use role. Notifications: Use the workspace rule (default) to notify the submitter when the task is assigned.

3. Screen Contract Content (Safety)

Type: Safety (teal shield icon). Label: "Screen Contract Content". Place this node between Submit Contract and Analyze Contract. The Safety node runs content safety and compliance checks on the submitted contract content before any agent processes it, and propagates its guardrails to every downstream agent call in the workflow. Fields section: Configure to evaluate the contract text field. Output ports: Configure a pass port (leads to Analyze Contract) and a flagged port (leads to a dedicated End node labeled "Blocked: Policy Violation"). Ensure the flagged path terminates at an End node.

4. Analyze Contract (Agent Interaction)

Type: Agent Interaction (purple bot icon). Label: "Analyze Contract". Agent Assignment: Assign a contract analysis agent. The agent's system prompt should instruct it to read the contract text and contract type, extract the key clauses (term, payment, liability, termination, IP ownership, governing law), identify risk factors relative to your standard contract position, assign a risk level (low, medium, high), and write a structured analysis to named workflow fields: clauseSummary, riskFactors, and riskLevel. Fields section: Configure to read the contract text and contract type fields from Submit Contract. Write clauseSummary, riskFactors, and riskLevel.

5. Check Analysis Quality (Agent Review)

Type: Agent Review (pink bot icon). Label: "Check Analysis Quality". Agent Assignment: Assign a quality review agent. The agent's system prompt should instruct it to evaluate the analysis summary for completeness: confirm that all required clause categories are addressed, that risk factors are specific rather than generic, and that the risk level is justified by the factors listed. Return pass if the analysis meets the standard, fail if it does not. Fields section: Read clauseSummary, riskFactors, and riskLevel. Output ports: Configure a pass port (leads to Legal Review) and a fail port (leads back to Analyze Contract, creating a revision loop). Set routing rules on the fail port to return to Analyze Contract when the agent returns a fail result. Set a priority so the pass rule is evaluated first.

6. Legal Review (Human Review)

Type: Human Review (amber eye icon). Label: "Legal Review". User Assignment: Assign to legal reviewers or a designated legal review role. Fields section: Pass the contract text, contract type, counterparty name, clauseSummary, riskFactors, and riskLevel to the reviewer as context. The reviewer reads the AI analysis alongside the contract and makes one of three decisions: approve, redline, or reject. Notifications: Use Custom audience and notify the task assignee. Legal review tasks are high-priority and should not be subject to a workspace-level notification suppression rule.

7. Route Legal Decision (Routing)

Type: Routing (purple GitFork icon). Label: "Route Legal Decision". Routing Configuration: Configure three output ports based on the Human Review decision field:

• Port "approved": decision equals approved, priority 1. Edge leads to End ("Approved").
• Port "redline": decision equals redline, priority 2. Edge leads to Draft Redline.
• Port "rejected": decision equals rejected, priority 3. Edge leads to End ("Rejected").

8. Draft Redline (Agent Interaction)

Type: Agent Interaction (purple bot icon). Label: "Draft Redline". Agent Assignment: Assign a redline drafting agent. The agent's system prompt should instruct it to read the contract text, the AI analysis, and the reviewer's redline comments, and produce a structured redline summary that identifies each clause requiring revision, states the current language, and proposes revised language. Write the output to redlineSummary. Fields section: Read contract text, clauseSummary, riskFactors, and the reviewer's redline comments field. Write redlineSummary.

9. Confirm Redline (Human Review)

Type: Human Review (amber eye icon). Label: "Confirm Redline". User Assignment: Assign to the same legal reviewer or role as Legal Review. Fields section: Pass redlineSummary and the original contract text to the reviewer. The reviewer confirms the redline is accurate and complete, then approves to issue or requests changes. Output ports: approved (leads to End "Redline Issued") and changes-requested (leads back to Draft Redline, closing a revision loop on the redline path).

10. Route Redline Confirmation (Routing)

Type: Routing (purple GitFork icon). Label: "Route Redline Confirmation". Routing Configuration: Two ports: approved (leads to End "Redline Issued", priority 1) and changes-requested (leads back to Draft Redline, priority 2).

End nodes

Use five distinct End nodes with descriptive labels:

• "Blocked: Policy Violation" (from the Safety node's flagged port)
• "Approved" (from Route Legal Decision, approved branch)
• "Rejected" (from Route Legal Decision, rejected branch)
• "Redline Issued" (from Route Redline Confirmation, approved branch)
• "Analysis Failed" (optional: from Check Analysis Quality fail port if you prefer to terminate rather than loop on persistent analysis failures)

Distinct End node labels make contract outcomes distinguishable in reporting and auditing.

This workflow uses the following named workflow fields. Configure these consistently across all node Fields sections and agent system prompts. Field names are case-sensitive: a mismatch between the name written by one node and the name read by the next is the most common cause of context not flowing correctly between steps.

The instance context accumulates as the instance progresses. Fields written by Submit Contract persist through the entire instance lifecycle and are available to every downstream node without re-passing. The reviewerComments field is only populated on the redline path: ensure the Draft Redline agent's system prompt handles the case where this field may be absent on other paths, if the same agent is reused across paths.

This workflow creates tasks at three nodes: Submit Contract (User Interaction), Legal Review (Human Review), and Confirm Redline (Human Review). Each task appears in the Task Inbox of the assigned user or role when the instance reaches that node.

DAVE ships with six default tenant roles: Admin, Create, Curate, Use, Reporting, and Financial. All roles are editable by your administrator. For this workflow, the relevant role assignments are:

• Submit Contract: Any user with the Use role can submit a contract. If the workflow is used by internal teams submitting contracts for legal review, assign to the relevant team members or leave open to all Use-role users.
• Legal Review: Assign to users with the Use role who are designated legal reviewers. These users receive the AI analysis alongside the contract and make the approve, redline, or reject decision. Because this is a high-stakes decision, consider assigning to a specific named user or a tightly scoped role rather than all Use-role users.
• Confirm Redline: Assign to the same legal reviewer or role as Legal Review. The reviewer confirms the AI-drafted redline summary before it is issued to the counterparty.

The Admin and Curate roles are required to build and modify the workflow in the Workflow Editor. The Create role is required to build and update the contract analysis, quality review, and redline drafting agents. Legal reviewers who only complete tasks need only the Use role.

Notification configuration: Legal Review is configured with Custom audience notification (notifying the task assignee directly) rather than the workspace rule, because legal review tasks are high-priority and time-sensitive. Submit Contract and Confirm Redline use the workspace rule (default). For the Safety node's flagged path, no task is created if the flagged path routes directly to an End node: no notification is needed in that case.

This framework is a starting point. The following variations are common when adapting it to a specific legal operations context.

Adding a CRM or contract management system lookup

Insert an API Call node between Submit Contract and Screen Contract Content to fetch the counterparty's existing contract history from your CRM or contract management system. Map relevant fields (prior contracts, open disputes, relationship tier) into the instance context. The analysis agent can then use this history as additional context when assessing risk. See the guide on calling an external API mid-workflow for configuration details.

Routing by risk level before legal review

Insert a Routing node between Analyze Contract (or Check Analysis Quality) and Legal Review. Configure routing rules based on the riskLevel field: low-risk contracts route to a junior reviewer or an automated approval path, high-risk contracts route to senior legal counsel. This reduces the volume of contracts reaching senior reviewers without removing human oversight from high-risk cases.

Replacing the Agent Review quality check with a Human Review

If your legal team prefers a human to verify the AI analysis before it reaches the primary reviewer, replace Check Analysis Quality (Agent Review) with a Human Review node assigned to a legal operations coordinator. The coordinator reviews the analysis for completeness and either approves it to proceed to Legal Review or sends it back to Analyze Contract for revision. This adds a human quality gate at the cost of an additional task in the process.

Adding a counterparty notification step

Insert an API Call node after the Approved End node (or before it, with the End node following) to send a notification to the counterparty via your email or contract management API. Map the counterpartyName and submitterContact fields into the API Call body. This automates the approval notification without requiring a human to send it manually.

Removing the redline confirmation step

If your legal team is confident in the AI-drafted redline and does not require a second review, remove Confirm Redline (Human Review) and Route Redline Confirmation (Routing), and connect Draft Redline directly to End ("Redline Issued"). This reduces the redline path from four nodes to two and eliminates the second review task.

The Information node (indigo info icon) does not affect workflow execution: it creates no tasks, invokes no agents, and has no effect on the instance context. Its sole purpose is to add notes directly on the canvas for the benefit of anyone who opens the workflow in the editor later.

For a contract review workflow with multiple branches and a revision loop, Information nodes are essential for maintainability. Place them beside (not in) the execution path: a node with no incoming or outgoing edges is purely documentary and will never be reached by an instance.

Recommended Information node placements for this workflow:

• Beside Screen Contract Content (Safety): Document the policies enforced and the flagged path destination. Label the node "Safety: screens contract text before analysis. Flagged path ends at Blocked: Policy Violation."
• Beside Check Analysis Quality (Agent Review): Document the quality criteria the agent evaluates and the loop behavior on failure. Label the node "Agent Review: checks clauseSummary, riskFactors, riskLevel for completeness. Fail loops back to Analyze Contract."
• Beside Route Legal Decision (Routing): Document the three routing rules and their priority order. Label the node "Routing: approved (p1) to Approved End, redline (p2) to Draft Redline, rejected (p3) to Rejected End."
• Beside the redline revision loop: Document the loop. Label the node "Redline loop: Draft Redline → Confirm Redline → Route Redline Confirmation → (changes-requested) back to Draft Redline."
• Beside the field list: List all nine workflow fields, their sources, and their consumers. This is the most valuable annotation for a future editor who needs to add a new step or debug a context issue.