Flowgrammer

Dropbox Document Approval Workflow

Run document approval when Dropbox holds the file. Use folder naming, file id, rev, and a DecisionEvidence log. Not comments. Not Dropbox Sign.

— Craig Major

A Dropbox approval workflow uses Dropbox as the file system of record and an explicit DecisionEvidence log for approve, reject, or request-changes. Capture file id, rev, and optional content_hash before a named person decides. Comments, activity, version history, shared links, and folder moves are not evidence. File request is intake only. Dropbox Sign is e-sign, not this job.

Start with the published Document Approval Workflow if you still need the app-neutral status and role model. The paired Dropbox Approval Folder / Decision Log Template is the Dropbox implementation.

Who this is for

Use this when controlled procedures already live in a Dropbox team or shared folder and the missing piece is a named decision bound to a frozen version.

Prerequisites:

  • One document family for the first build
  • A Dropbox folder you can name Intake, In Review, Approved, and Rejected
  • A named requester and a named approver
  • A place to store DecisionEvidence (the paired workbook, Sheets, or another exportable log)
  • Fictional or approved samples before any live write

Leave these out of the first system: anonymous approval, comment-as-approve, file-request-as-decision, Dropbox Sign as internal approval, DocSend analytics as identity proof, Dropbox as IDP or OCR, payment, bank-detail changes, final accounting writes, and any claim that version history or activity export certifies compliance.

If you still need to decide what to automate first, use Document Processing Automation. If the pain is unread PDFs, use intelligent document processing. Dropbox does not extract invoice fields by itself. If the job is a money register, use invoice processing automation. If the job is a renewal register, use the contract tracker.

What Dropbox implements from the parent

The parent owns the control job: closed statuses, named authority, version lock, reminders that never auto-approve, and one idempotent downstream action. This page does not invent a second schema.

Dropbox implements the file half:

  • Path plus native file id
  • rev and optional content_hash from metadata
  • Plan-gated version history
  • File requests as intake
  • Shared-link password, expiry, and disable-downloads on listed plans
  • Comments and team activity as collaboration or support, not evidence
  • Webhooks that name accounts with changes, then a cursor poll

The published Document Approval Status and Role Matrix stays the app-neutral field and status list. Parent closed statuses stay 1:1: draft, submitted, in_review, changes_requested, pending_escalation, approved, rejected, cancelled, superseded, duplicate. Dropbox overlay statuses record access and exception states: access_verified, unauthorized_attempt_logged, external_access_denied, link_expired_or_denied.

Folder naming and intake

Create a controlled root, then four working folders the team can see without guessing:

Folder What belongs there What it is not
Intake New uploads and file-request drops A decision
In Review Frozen file id and rev awaiting a named person Approval
Approved Files that already have DecisionEvidence approve on the current rev A signature packet
Rejected Files with a named reject A deleted record

Add Changes-Requested and Exceptions if you want the extra states visible in the tree. A folder move is a downstream action after a decision. It is not the decision.

File requests collect files from people who may not have Dropbox accounts. Official Help (re-fetched 8 September 2026) lists file requests on all plans. Basic, Plus, and Family accept uploads up to 2 GB. Professional, Essentials, Business, Business Plus, Standard, Advanced, and Enterprise accept uploads up to 250 GB. Deadline and late-upload control sit on that Professional-and-above list. The destination folder is private by default. A team admin can disable file requests. Those gates are mutable. Recheck Help on publish day. Cite plan categories only.

A closed file request stops uploads. It does not approve, reject, or request changes.

File identity, rev, and content_hash

Prefer native file id over path. Paths move when you tidy folders. The API metadata fields used for change detection include rev, content_hash, and server_modified. Official content-hash examples show how the hash is computed. You do not need the API to start: copy file id and the current revision from file details when your tenant shows them. Label tenant UI needs_live_proof.

Freeze identity when the row enters in_review:

  1. file_id
  2. rev
  3. optional content_hash
  4. path as a human pointer
  5. server_modified if you have it

A later decision that cites a different rev or a different hash is stale. Void it. Recapture metadata. Start a new cycle. Do not reuse the prior decision_id.

Version history is a restore window, not a certified approval audit. Help lists 30 days on Basic, Plus, and Family; 180 days on Professional, Essentials, Business, and Standard; 365 days on Business Plus, Advanced, and Enterprise. Upgrades are not retroactive. Version history does not apply to Paper, Google Docs, Sheets, Slides, or Microsoft Office Online files. Data Governance questions, including extended version history, stay questions. Do not certify records retention.

DecisionEvidence field list

Every terminal action writes a row. The reader columns are:

Field Job
request_id Stable request key
doc_id Business document id
file_id Dropbox native id
rev Frozen revision
content_hash Optional byte hash
path Human pointer
requester Named person
approver Named matrix actor
decision approve, reject, or request_changes
decided_at When the person decided
rationale Why, required on reject or changes
next_action notify, move_to_approved, hold, or none

Keep the parent keys beside those columns: decision_id, authority_rule_id, duplicate_key as lower(file_id)|lower(rev), idempotency_key as request_id|decision_id|action, downstream_write_count as 0 or 1, and access_test_result.

Comments, activity rows, version-history restores, shared-link opens, and folder moves may be linked as discussion or access refs. They never stand alone as approval evidence.

Comments, activity, shared links, and folder moves

Anyone with access can comment unless commenting is turned off. @mentions and reactions exist. You can download comments to a .txt file. That is collaboration.

Team activity is available to certain admins on Standard, Business, Advanced, Business Plus, and Enterprise. Actions usually appear in a few hours and at most 24 hours. File-operation events are listed for Business Plus, Advanced, and Enterprise. Help also states that some events are not logged, including Made a Comment and Deleted a comment. Microsoft co-authoring session activity is not in the team log. Third-party Sign integration activity may not appear there either. Activity export supports investigation. It is not DecisionEvidence.

Shared-link password, expiration, and disable-downloads are listed for Professional, Essentials, Standard, Advanced, Business, Business Plus, and Enterprise. Link settings apply to people who use the link. They do not change people already invited with direct access. An expired link shows an error. That is an access test, not a reject decision.

A move into Approved after a matching DecisionEvidence row is the allowed downstream action. A move with no log row is a mess, not an approval.

Dropbox Sign and DocSend walls

Dropbox Sign is a separate e-signature product. Official callback docs describe account and app callbacks, event_hash verification with the API key, and an HTTPS callback URL. Signature-request events such as sent, signed, or downloadable are e-sign lifecycle events. Signature complete is not internal approval. It is not renewal. It is not termination. Do not build a Sign guide in this unit. Planner phrases for Sign workflow automation have No reported data. The Sign brand volume is navigational. Do not use it as this page's demand.

DocSend can require email, verify email on listed plans, watermark, expire a link, or collect an NDA click. Those controls identify a visitor for a share. They are not named organizational approval and they are not identity proof for a controlled procedure. DocSend volume is not supplied. There is no DocSend page in this unit.

Dropbox Replay is a rich-media review surface for video, image, and audio. It is useful for creative review. It is not the controlled-document DecisionEvidence ledger.

Worked example

Cedar & Quay Fabrication Ltd is a fictional Toronto fabricator. Quality owns supplier procedure DOC-CQ-PROC-014. Version 1.4 is the candidate. Jordan Hale drops the PDF into Intake. Morgan Reid is the named approver. The DecisionEvidence row stores request REQ-CQ-2026-0914, doc_id DOC-CQ-PROC-014, file id id:FICTION-CQ-PROC-014, rev rev:1a2b3c4d5e6f014, optional content_hash, path, requester, approver, approve, decided_at, rationale, and next_action move_to_approved. Write count stays 1.

That clean path is case 1 in the Dropbox Approval Folder / Decision Log Template. The other six cases reuse the same document family.

The Dropbox approval workflow

  1. Intake. File request or a manual drop lands in Intake. Register request_id, requester, and a pointer. Do not approve on upload.
  2. Access test. Confirm the named approver can open the file on a direct invite, not only a public link. Failures become link_expired_or_denied or external_access_denied.
  3. Identity. Capture file id, rev, and optional content_hash. Refuse in_review if identity is missing.
  4. Assign. Name the requester and the authorized approver. The submitter does not self-approve when the SoD flag is on. Folder Admin and Team Admin are not Approver by title.
  5. Decide. Write DecisionEvidence: actor, time, decision, rationale, rev cited. Approve, reject, or request-changes.
  6. Remind and escalate. Remind before due. After timeout, set pending_escalation and notify Avery. Timeout does not approve.
  7. Invalidate stale versions. If rev or hash changed, void the open decision.
  8. Stop duplicates. A second request for the same file id and rev is duplicate. A replayed webhook or callback with the same decision_id is ignored. Write count stays 1.
  9. Handoff. After approve, move or shortcut once to Approved. Retry with the same idempotency key.
  10. Evidence. Export the log. Keep Sign, DocSend, Replay, and activity CSV as out-of-band support if you need them.

If you later add an integration, official webhook docs say the POST body lists account IDs with changes, not the files. Your app stores a cursor and calls list_folder/continue. Verify X-Dropbox-Signature. Respond within about ten seconds. Dropbox retries failures and can disable a noisy webhook. Exact numeric rate quotas are unpublished. Handle HTTP 429 and Retry-After. too_many_write_operations can appear on a contended namespace. Label live wiring needs_live_proof.

What can run automatically, and what cannot

Situation Automatic action Person required
File request lands in Intake Optional notify No
Required file id or rev missing Stay submitted or exception Owner captures identity
Named approver chooses approve Status approved; one folder move The decision itself
Request-changes Status changes_requested Owner uploads a new rev
Actor not in the matrix Exception unauthorized_approver Process owner. Status stays in_review
Decision cites an old rev or hash Exception stale_version Restart on the current metadata
Second request for the same file id and rev Status duplicate Continue the canonical request
Webhook or Sign callback replay Ignore the second write Confirm write count 1
Shared link expired or password blocked Status link_expired_or_denied Restore access or reassign
SLA missed Reminder, then escalate Escalation approver. No auto-approve
Payment or bank-detail change Never Entirely outside

Human decisions

A person keeps these decisions:

  • Approve, reject, or request-changes
  • Authority and self-approval conflicts
  • Stale-version restarts
  • Duplicate versus canonical request
  • Shared-link or ACL failures
  • Escalation after timeout
  • Whether Sign or DocSend is even in scope, as a separate job
  • Payment release and any supplier bank-detail change

A comment can send a person to the file. It cannot approve. A folder move cannot approve. A Sign callback cannot approve this SoR.

Failure paths

Failure Expected status Downstream Payment
Unauthorized actor or comment-as-approve in_review plus unauthorized_approver No write Blocked
Stale rev or hash stale_version, still in_review No write Blocked
Duplicate request duplicate No second write Blocked
Replayed callback duplicate_ignored Write count stays 1 Blocked
Shared-link denial link_expired_or_denied No decision yet Blocked
Timeout with no person pending_escalation No auto-approve Blocked
File request only submitted or file_request_only_no_decision No approve Blocked
Sign complete treated as approve Exception sign_confused_as_approval No internal approve Blocked
DocSend visit treated as identity Exception docsend_analytics_as_identity No approve Blocked
Any payment or bank-detail change Forbidden Forbidden Forbidden

Test cases

The seven Cedar & Quay cases are control fixtures. They are not customer results.

Case Input Without DecisionEvidence After the control
Clean approve DOC-CQ-PROC-014 v1.4, Morgan named File sits in In Review Approve plus one Approved-folder write
Request changes then new rev Morgan asks for section 4 Old comment looks like progress New rev; prior decision not reused
Unauthorized approver Teammate comments "approved" Status flipped by chat unauthorized_approver; stays in_review
Stale rev or hash Approve cites v1.4 after a new upload Wrong file marked approved Void; recapture current rev
Shared-link denial External link expired Reviewer guessed and approved link_expired_or_denied
Timeout / escalation due_at 1 September 2026, as_of 8 September Silence treated as approve pending_escalation to Avery
Duplicate / idempotent callback Webhook replay for the same file id and rev Second Approved move First write wins; write count 0 on the replay

The paired template walks each case on its own sheet and in csv/case-recalc.csv.

What to measure

Record requests received, share of rows with file id and rev captured, unauthorized attempts blocked, duplicate callbacks suppressed, timeouts escalated without auto-approve, access tests passed before in_review, and approvals that have a folder or log write ref. Keep those as definitions. Do not invent a benchmark, accuracy rate, or ROI figure.

There is no live production Dropbox approval metric here, and no Flowgrammer customer Dropbox case.

How to use the template

The paired asset is an editable DecisionEvidence workbook and CSV pack. It is not a Marketplace listing and not a live Dropbox folder.

  1. Open Instructions. Acknowledge comments-versus-evidence, Sign, DocSend, file-request, and no-Marketplace caveats.
  2. Create Intake, In Review, Approved, and Rejected folders from the naming sheet.
  3. Import csv/decision-evidence-import.csv. Keep the internal names.
  4. Leave Config as_of at 8 September 2026 while you walk Case01 through Case07.
  5. Confirm case 3 does not move to Approved and case 7 does not write a second time.
  6. Answer the security and retention questions. Labels alone are not a records program.

Read the setup guide in the download. The useful rules also sit on this page so the download is not the only answer.

Realistic limitations

  • Dropbox stores the file. It does not become approval authority.
  • No official ordinary-file Approvals product was found in current Help and developer docs on 8 September 2026. Do not claim one. Recheck on publish day.
  • Version history, file-request size, shared-link controls, activity export, and Replay add-ons are plan-gated and mutable. Cite categories. Do not publish seat prices.
  • Exact API rate quotas are unpublished.
  • Tenant screens differ. Label them needs_live_proof.
  • This system does not sign a document, pay anyone, run OCR, or change supplier bank details.
  • This guide does not rank Dropbox against Drive, SharePoint, or Box, and it is not a Sign or DocSend buyer's guide.

Next step

Download the Dropbox Approval Folder / Decision Log Template and walk the seven fictional cases.

Keep the parent Document Approval Workflow and Document Approval Status and Role Matrix nearby for the shared model.

If reviewers, authority, or the destination log are still unclear, start with an AI Success Audit. If those pieces are already named, book a fit call to scope an AI Automation Systems build.

Sources

Frequently asked questions

What is a Dropbox approval workflow?

It is a controlled path that uses Dropbox as the file SoR and an explicit DecisionEvidence log for a named approve, reject, or request-changes decision bound to file id and rev.

Does Dropbox have a native Approvals product for ordinary files?

Not in the official Help and API sources reviewed on 8 September 2026. Replay is a rich-media review surface. Sign is e-sign. Protect is access governance. None of those replace DecisionEvidence for a controlled procedure.

Are comments or version history enough?

No. Anyone with access can comment. Version history is a restore window. Team activity can miss comment events. Keep a named decision row.

Is a file request an approval workflow?

No. A file request collects files. Deadline and password options do not decide the document.

Is Dropbox Sign the same job?

No. Sign completes a signature request. Internal approval is an organizational decision. A file may need both, in that order, under a separate policy.

Do DocSend analytics prove who approved?

No. Email verification and visit tracking identify a viewer for a share. They are not named approval authority.

Can timeout auto-approve?

No. Timeout becomes pending_escalation. A person still decides.