A simple approval workflow for shared notes and draft versions

Approval is useful when it records a specific agreement. A vague “looks good” in a message thread can be difficult to interpret later. Was the recipient accepting the wording, the dates, the budget or the entire plan? Did the material change after that response?

A lightweight approval workflow gives the decision a scope and a version. It also makes room for questions and changes before acceptance. This guide describes a practical process for ordinary notes and project material; it does not treat a product approval button as a legal signature or substitute for a required contract.

Define the decision before asking for approval

Write down what the reviewer is accepting. If the note contains instructions, approval might mean the instructions are accurate and ready to use. If it contains a draft invitation, approval might mean the wording can be sent.

Say what is outside the decision. Approving the invitation text does not necessarily authorize its distribution, a purchase or a booking. Separate those actions when they require different people or controls.

A useful request is specific:

Review version 2 for the arrival instructions and equipment list. Approval means those details are ready to share with participants. The venue booking and payment remain separate decisions.

This protects the review from becoming a broader agreement than the recipient intended.

Identify the right reviewer

Choose the person who can make the decision. Several people may provide comments, but that does not mean each person has authority to accept the result.

Record the reviewer's role in the brief or invitation. If more than one decision is needed, define the order. A factual check may come before a final communication review. Avoid sending competing requests that can produce inconsistent instructions.

Draftnod's project access remains based on the existing link and PIN workflow. This guide does not imply individual recipient accounts, per-person roles or a new multi-approver permission system. Use the product within the access model it actually provides.

Publish the version that is ready for a decision

Save the draft privately and review it yourself. Check that it contains the actual material you want approved. Remove placeholders or label them clearly if they are part of the decision.

Publish the version so it appears in the project portal. Send the project link and PIN privately, name the task and identify the version. Saving a draft alone does not make it available to the recipient.

The sharing guide explains these publication boundaries, and the clear brief guide helps define acceptance criteria before the work begins.

Separate comments from decisions

A comment can ask a question, suggest an improvement or identify an error. It does not necessarily close the review. The owner should understand whether the recipient is requesting a change that blocks acceptance or merely offering an optional suggestion.

When a published version is awaiting review, the portal's existing decision controls let the recipient approve the version or request changes and save that decision. Encourage a short explanation when changes are requested.

A useful change request names the issue and the desired outcome. “Please fix the equipment section” is less clear than “Add whether participants should bring a mat, because the current list does not say whether one is provided”.

Revise with a visible response to feedback

Create a new version for substantive changes. Summarize what changed and which feedback it addresses. If you decided against a suggestion, explain the reason in the shared record.

Do not silently change the meaning of material after a recipient approved it. If a revised date, requirement or instruction changes the agreement, request a decision on the revised version.

The version history guide describes how to keep earlier comments and approvals understandable. The asynchronous feedback guide helps when reviewers respond at different times.

Keep an explicit pending state

An unanswered review request should remain pending. Do not assume that silence means approval unless a suitable rule was explicitly agreed outside the tool.

If the deadline passes, follow up with the same task and version reference. Ask whether the reviewer needs more information or a new response window. Avoid creating a duplicate task just to restart the conversation.

If the work must proceed before approval, record who made that decision and under what conditions in your ordinary process. A product status should describe what happened, not hide an exception.

A reusable approval request

Use a short request the recipient can act on:

Task: participant instructions. Version: 2. Review scope: arrival route, start time and equipment. Acceptance criteria: the instructions are accurate, complete and ready for participants. Response requested: approve this version or request changes with the missing detail. Deadline: specify the date and time zone. Separate decisions: venue booking and distribution.

Adapt the fields to your context. A casual note may need only a comment, while a business deliverable may need additional records outside Draftnod.

Readable review requests help reduce confusion. W3C's accessible writing tips recommend clear headings and meaningful link text, which make it easier for reviewers to identify the scope and destination.

Close the task with the decision's scope intact

After approval, summarize the accepted outcome and the next action. If someone else receives the approved material, include the version reference so they know which record supports the handoff.

Use the project handoff checklist when responsibility transfers after the decision. The handoff should preserve what was approved and what remains open.

Open your workspace and test the workflow with one low-risk note. The success criterion is simple: another person can identify the decision, the approved version and the next step without reading a separate message history.