A client replies “Looks good” to a design preview at 4:12 p.m. Six minutes later, someone replaces the file. A month after launch, the client questions a detail. The team can find the email and the latest file, but not a reliable answer to the awkward question: Which version did the client approve?
This is where a simple Airtable client approval log becomes useful. Airtable can show changes to a record, but a field edit, a comment, and an explicit sign-off are three different events. The workflow below separates them without asking a small agency to buy a full contract-management platform.
Scope: This is an operational sign-off trail for creative deliverables, reports, website drafts, and other routine client work. It is not an electronic-signature service, an immutable audit system, or legal advice. If a contract, regulator, or insurer requires a particular form of authorization, use an approved process for that requirement.
What Airtable revision history can actually tell you
Airtable’s record-level revision history helps explain how fields changed. It does not, by itself, establish that a named client accepted a specific deliverable. A status changed to “Approved” might reflect an internal update, an automation, or an incorrectly mapped submission. A comment saying “fine” may refer to a different draft.
There is also a retention and export problem. As of October 28, 2026, Airtable documents revision-history visibility of two weeks on Free, one year on Team, two years on Business, and three years on Enterprise Scale. Revision history is view-only: it cannot be exported through the product, Web API, or eDiscovery export. Airtable states that comments remain in the activity feed unless manually deleted, although they are not a substitute for a signed-off version. Those distinctions matter if you need to answer a client question after the history window closes.
Quick rule: a change log explains edits, a comment records discussion, and a decision record captures an explicit outcome for a named version.
| Record of activity | What it helps answer | What it does not prove |
|---|---|---|
| Revision history | What changed in a field and when, within the available history window | That the authorized client approved the exact file version |
| Comments or email | What someone said during review | That the words were an unambiguous final decision |
| Separate approval decision record | Who responded, to which version, with which outcome and evidence | Legal enforceability or tamper-proof retention by itself |
The practical distinction is simple: use revision history to investigate changes; use decision records to document decisions.
Airtable approval log template: two tables, eight evidence fields
A single checkbox is convenient until the second revision arrives. Instead, keep one table for the thing being reviewed and another for each response. This gives the team a current status without erasing the sequence of earlier decisions.
Table 1: Deliverables
Create one record per client deliverable. Include a client or project reference, owner, current version label, review-stage status, due date, and a link to the versioned artifact. Keep the latest approved version in its own field rather than assuming it always equals the current working version.
Table 2: Approval Decisions
Create a new record for each approval, rejection, or change request. The following is a practical minimum schema, not an Airtable preset:
| Field | Example / purpose |
|---|---|
| Decision ID | APR-0048; unique reference for support and exports |
| Deliverable link | Linked record to the item under review |
| Submitted version | v3, with a stable file or snapshot reference |
| Approver identity | Verified client contact or clearly labeled self-reported email |
| Decision | Approved / Changes requested / Rejected |
| Decision time | Created time of the decision record, with a stated time zone |
| Conditions and notes | “Approved for homepage only”; do not hide exceptions |
| Evidence reference | Submission ID, original email, or authenticated review record |
Use Airtable’s Created time field for the new decision record. Do not use a general Last modified time field as the approval timestamp: a later typo fix can move it. Record who collected the approval and how identity was checked; an email typed into a public form is a claim, not proof of ownership.
For an agency handling multiple clients, consider a third Clients table to keep approved contacts and their permitted projects. That relationship should drive both who receives the review request and which submissions your team accepts.
Collect a decision without exposing the entire base
The lowest-friction route is often a review email with a stable version link and a small response form. The email should ask for one of three explicit outcomes: Approve this version, Request changes, or Reject. Include the deliverable name and version in the request itself, not only in the button text.
Airtable forms are useful for collecting a new decision because native forms create records rather than editing existing ones. That behavior suits an event log. But a public form does not automatically authenticate the person entering a name and email address. If approval authority matters, use an authenticated client-facing process or verify the response against the approved contact through a separate channel.
If clients need to review records inside Airtable, check the sharing model carefully. Airtable distinguishes sharing an interface from sharing the underlying base; inviting a client to the base grants a different scope of access. Do not solve a sign-off problem by handing out broad editing permissions. Before launch, run the two-client access tests in our Airtable client portal permissions checklist.
For clients who need to correct existing details before approving, treat that as an update workflow, not an approval event. Our guide to letting clients update Airtable records safely explains why the record target matters.
Automate the handoff, but keep one human decision
The automation should react to a new decision record, not to a vague keyword in a comment. Airtable supports a Create record action and an Update record action. An update needs the correct record ID; a static ID in the wrong place can repeatedly overwrite one deliverable.
Use this sequence as a design specification, then configure and test it in your own base:
- Receive: a new Approval Decisions record is submitted and linked to one deliverable.
- Validate: the approver is authorized, the decision is explicit, and the submitted version matches the version currently awaiting approval.
- Route: a change request creates a revision task; a rejection notifies the owner; an approval advances the deliverable only if the checks pass.
- Record: retain the original decision event, send a confirmation, and save the approved version reference in the Deliverables record.
- Reopen: if the file changes materially, issue a new version and request a fresh decision. Do not carry an old approval forward.
A useful guardrail is to stop rather than guess when a version is missing, a client identifier does not match, or two conflicting decisions arrive. Route the exception to the project owner. Automating the notification is valuable; automating the interpretation of an ambiguous “looks fine, except…” message is risky.
Keep receipts separate from sign-off. A confirmation email means the form arrived; it does not mean the project was approved. Our receipt-versus-approval email workflow shows how to avoid that confusion.
Save the version you approved, not just a link to today’s file
A version label such as “v3” is only useful if the content behind it remains identifiable. Save a dated PDF or export, a controlled file version, or another stable artifact alongside the decision. Record the source document link as a convenience, but do not rely on a mutable “latest draft” URL as the only evidence.
Be careful with attachment links. Airtable explains that attachment download URLs expire, while viewer links have different access requirements. If the approval record must be available later, preserve the underlying file in a permission-controlled repository under your organization’s retention policy, not only an expiring download URL.
Export your own decision records periodically if your workflow requires portable evidence. This is different from exporting Airtable’s native revision history, which Airtable does not support. Restrict who can edit or delete decision records, keep dated backup copies with controlled access, and document retention before a dispute occurs. A regular Airtable table is editable by sufficiently privileged users; call it an operational log, not an immutable audit trail.
Four failure tests before inviting a real client
| Test | Expected behavior |
|---|---|
| Client A opens Client B’s link | No unauthorized access to B’s material or approval controls |
| Client approves v2 after v3 is sent | v2 decision is recorded, but v3 is not marked approved |
| Client clicks Approve twice | Duplicate event is flagged or reconciled; no double handoff |
| Client says “approved with one change” | Record the condition and request clarification; do not silently treat it as unconditional sign-off |
Use fictional clients and dummy files for these checks. Test with the same permissions a real client will have, not only with an administrator preview. Then ask a colleague unfamiliar with the setup to retrieve the approved version and supporting decision from a past project. If they cannot do it in a minute or two, the log needs clearer labels or links.
When a project tool is the better place for approval
Not every team needs Airtable. Asana approval tasks provide explicit outcomes such as Approved, Request changes, and Reject. ClickUp Proofing supports comments on visual assets, including assignable feedback. Those are different strengths: a proofing comment is not automatically a final approval, and an approval status still needs to point to the right asset version.
If your agency already keeps projects in Asana or ClickUp, start there. Add a separate decision log only when you need cross-tool reporting, external intake, or a portable record of sign-offs. If you are choosing a database for the process, our Zapier Tables versus Airtable client intake comparison examines the editing and approval boundaries. The goal is not to collect more apps; it is to remove uncertainty about what the client accepted.
WTA VERDICT
Use Airtable revision history to investigate edits, not to stand in for client authorization. For routine agency work, a linked Approval Decisions table, explicit version-specific responses, identity checks, and a retained artifact create a more useful operational sign-off trail. If your work requires legally enforceable signatures or tamper-evident records, choose a system designed for those requirements.
3-Line Takeaway
- Separate events: one new decision record per approval, rejection, or change request.
- Bind the version: never let approval of v2 silently authorize v3.
- Preserve evidence: Airtable revision history has plan limits and cannot be exported.
Leave a Reply