Contract approval workflow template
This contract approval workflow template sets up routine sign-off: an ordered list of reviewers, clear status changes, resubmission after edits, and approval before signature. It includes a filled example and a RACI matrix.
Approval policy template
A contract approval workflow is a named, ordered list of people who must approve a specific version of an agreement before it is signed. Fill in these fields once per routine contract type.
| Field | How to fill it in |
|---|---|
| Policy name | Name it after the routine it covers, for example "Standard vendor MSA" or "Customer NDA, no changes". |
| Used for | The contract types and conditions where this policy applies. Write this down: the choice is made by the requester, not by a rule. |
| Reviewers, in order | 1 to 10 named people. Put the reviewer most likely to request changes first so later reviewers see a stable version. |
| What each reviewer checks | One line per reviewer, such as commercial terms, payment terms or overall sign-off. Avoid two reviewers checking the same thing. |
| Who may request | Any owner, admin or editor who is not on the policy. Viewers cannot request approval. A requester can never approve their own request. |
| Out of scope | Situations that skip this policy and go to escalation instead, such as uncapped liability or a regulator-facing term. |
Copy-ready version
Copy this block into your own document or wiki and fill it in.
CONTRACT APPROVAL WORKFLOW Policy name: ______________________ Used for (contract types / conditions): ______________________ Out of scope (send to escalation instead): ______________________ Reviewers in order (max 10, requester may not be one): 1. ______________ checks: ______________ 2. ______________ checks: ______________ 3. ______________ checks: ______________ Rules - Approve the current saved version only. - Any edit after a request means a new request. - Team rule (not enforced by LegalDoc): "Request changes" includes a note saying what must change. - Signatures only after the current version is approved. Policy owner: ______________ Review date: ______________
Status transitions
An approval request is always pending, approved, rejected or superseded. These transitions match how team approvals work in LegalDoc, and they are a sound default for any tool.
| From | Event | To |
|---|---|---|
| (none) | Requester submits the current saved version under a policy | pending, waiting on reviewer 1 |
| pending | The next reviewer approves and more reviewers remain | pending, waiting on the next reviewer |
| pending | The last reviewer approves | approved |
| pending | Any reviewer chooses "Request changes" | rejected (later reviewers are not asked) |
| pending or approved | Anyone saves an edit, or a new approval is requested | superseded |
| approved | Signature request sent for that same version | approved (signature request opens) |
| rejected | Requester edits and submits again | a new request starts at pending; the rejected request stays on record |
Rejection, edits and resubmission
Approval always attaches to one version. Once the text changes, earlier approvals no longer count and the agreement goes back through the full sequence.
- A request for changes stops the request; later reviewers are not asked to decide.
- Every saved edit supersedes pending and approved requests, including approvals earlier reviewers already gave.
- The resubmitted version starts again with reviewer 1, so keep notes specific enough to avoid a second round.
- If any active policy exists in the workspace, or the agreement has approval history, signatures can only be requested for an approved current version.
- Rejected and superseded requests, with their notes, stay on record.
Filled example
Illustrative only: Northwind Ltd and Acme Analytics LLC are fictitious. Northwind's policy "Standard vendor MSA" lists commercial counsel, the finance controller and the head of legal, in that order. All three are editors in the workspace, since viewers cannot approve.
| Version | Step | Request status after the step |
|---|---|---|
| v4 | Requested by the contract manager under "Standard vendor MSA" | pending |
| v4 | Reviewer 1, commercial counsel: approve. Note: liability cap matches playbook. | pending |
| v4 | Reviewer 2, finance controller: request changes. Note: payment term is 30 days; our standard is 45. | rejected |
| v5 | Contract manager saves the agreed payment wording and requests again | pending |
| v5 | Reviewer 1 approves again, then reviewer 2 approves | pending |
| v5 | Reviewer 3, head of legal: approve | approved |
| v5 | Contract manager sends v5 to two named signers at Acme Analytics LLC | approved, signature pending |
RACI matrix
R is responsible, A is accountable, C is consulted and I is informed. Adjust the columns to your team; keep one A per row.
| Activity | Requester | Reviewers | Workspace admin | Head of legal |
|---|---|---|---|---|
| Define and maintain approval policies | C | C | R | A |
| Choose the right policy for a request | R | I | C | A |
| Prepare the version to approve | R/A | I | - | - |
| Approve or request changes at each step | I | R/A | - | I |
| Revise and resubmit after changes are requested | R/A | C | - | - |
| Replace a policy when a reviewer leaves | I | I | R | A |
| Send for signature after approval | R | I | - | A |
Questions about approval workflows
How is approval different from escalation?
Approval is the routine sign-off sequence every agreement of a given type goes through. Escalation is for non-standard risk that needs a decision outside that routine; keep those rules in your escalation policy.
Can approvers work in parallel?
Not in LegalDoc. Reviewers decide one after another in the order set on the policy. If two people must both approve, list both.
What if a reviewer leaves the team?
In LegalDoc a policy with an unavailable reviewer cannot be used. An owner or admin creates a replacement policy and the requester submits a fresh request. Earlier decisions stay on record.
Run this workflow in LegalDoc team workspaces, route non-standard risk through the escalation policy playbook, and set request quality upstream with the intake policy template.