Airtable Forms vs row-edit links: which one do you actually need?

It's 5pm Friday. You're staring at two rows in your Airtable. Both are PO-1024. One is the original. The other arrived an hour ago from the Airtable Form you sent the vendor on Monday, with an updated delivery date and a slightly different version of the vendor's name. You're going to copy two fields from row two into row one, delete row two, and pretend this is a workflow.

It's not. You picked the wrong tool a week ago, and Friday afternoon is the bill arriving.

Here's the difference, in one sentence:

Forms create new records. Row-edit links update existing ones.

Get the choice wrong and your week ends with copy-paste from a duplicate row. Get it right and the vendor's edit lands in the original record before you've finished your coffee.

Reply rate, not feature parity, decides the choice

Most "should I use a Form?" questions are really "how do I get this external person to update this record?" Pick the wrong tool and the answer becomes: send the link, wait two days, send a follow-up, get back a duplicate row, hand-merge it Friday afternoon, repeat. Pick the right tool and the answer becomes: send the link, get the row updated, move on. The choice is about how much of the data actually comes back, not about which tool ships more checkboxes.

Where Airtable Forms shine

Forms are an Airtable-native feature. You design them in the same UI as your tables. A submission becomes a row. Anyone with the link can submit; no login. Field types and required fields are enforced, so a bad email gets rejected before it hits the table. You can hide and reorder fields without exposing your whole schema. They cost zero extra dollars — they're included on every Airtable plan, including Free.

Forms are the right tool for inbound leads, support requests, application intake (jobs, vendors, signups), survey responses, and any workflow where each submission is a new row. If that's your job, stop reading and use Forms.

Where Forms break: the duplicate-record problem

The moment you need the recipient to update an existing record, Forms fall apart. The Airtable Form has no concept of "this submission is editing record recXYZ123." Every submission creates a new row.

The failure cases rhyme. A vendor needs to flip the status on PO-1024 from "in transit" to "delivered" — Form gives you a second PO-1024 row. A customer wants to fix a typo in their billing address — Form gives you a duplicate. A freelancer logs hours per project, where each project has one row that should accumulate — Form forces you to either accept duplicates or build a merge automation that introduces its own bugs.

We've watched ops teams build elaborate Airtable Automations to deduplicate, merge, or reconcile form submissions back to existing records. It works until the merge logic gets a corner case wrong. Then you're debugging an automation while the customer is on the phone, and the chase has gotten worse instead of better.

What a row-edit link actually is

A row-edit link is a per-row, scoped form. The link maps to one specific row (recXYZ123). It can show specific fields with their current values pre-filled. The recipient edits, submits, and the same row is updated. The link can expire, be revoked, be single-use, or be reusable. The recipient sees only the fields you allowed and only the row you targeted — no portal, no account, no Airtable seat.

This is the pattern RowRouter ships. It's also the pattern most teams DIY with a webhook + a form + Apps Script after they've done the reconciliation dance for six months. It's the closest thing the Airtable ecosystem has to Smartsheet's Update Requests, except with field-level access controls, replayable audit logs, and review-before-publish. (Head-to-heads: vs. Airtable Update Requests and vs. Smartsheet Update Requests.)

The decision tree

Does the recipient need to UPDATE an existing record?
├─ No (they're submitting fresh data)
│   └─ Use Airtable Forms.
└─ Yes
    ├─ Do they need to update ONE specific record per link?
    │   └─ Use a row-edit link (RowRouter or DIY).
    └─ Do they need to pick from multiple records?
        └─ You probably need an Airtable seat, an Interface,
           or a portal builder (Softr, Stacker) — though
           reply rate drops sharply once login is required.

Side by side

Capability	Airtable Forms	Row-edit link
Create new records	Yes	No
Update existing record	No	Yes
Field-level scoping	Yes	Yes
Pre-fill from existing data	Limited (URL params)	Yes (server-side, live values)
Per-link expiry	No	Yes
Per-link revocation	No	Yes
Audit trail	No	Yes (timestamped, replayable)
Single-use enforcement	No	Yes
Conflict detection	No	Yes
Recipient login required	No	No
Recipient seat cost	$0	$0
Built into Airtable	Yes	No
Reply-rate impact	Medium (dedupe burden)	High (one click, right row)
Operator cost	$0	$49/mo flat

Edge cases worth knowing

"I want a Form, but pre-filled with the recipient's existing data." Airtable supports prefill via URL params (?prefill_FieldName=Value). It works for static prefill (a vendor name) but not for live values that may have changed since you generated the link. Row-edit links fetch the live record on form load, so the recipient is always editing against current state.

"I want a Form that creates a new record OR updates an existing one based on email." Build an Airtable Automation that runs after submission, looks up by email, and merges. Works, but the merge logic is fragile. If the email doesn't match exactly, you get a duplicate. If two submissions land in the same minute, ordering matters.

"I want the recipient to update one of several rows." Forms with a hidden record-link field, set to "single record only," can technically work — but only if the record is selected by the operator before sharing. At that point you've reinvented row-edit links badly.

"I want the recipient to edit one row, then optionally edit another row." Generate two row-edit links and send both. Don't try to do it with one Form.

When the right answer is neither

If the recipient is going to be in your Airtable a lot — picking from views, running searches, looking at history — they need an Airtable seat or a real portal. Don't fight it. Pay the $20/$45 or build the Softr.

The seat tax is only a tax when the recipient's job is one row at a time. For everything else, Airtable's actual product is what you should be paying for. (Math: Cheaper alternative to Airtable seats for vendors.)

TL;DR

For a new record, use Forms. For an existing record, one at a time, where you want the data back fast, use row-edit links. For existing records with multiple-per-session, ongoing access, use a seat or portal.

If you've been duct-taping a Form + Zap + lookup loop because Airtable doesn't ship a first-class update-by-link, RowRouter is the dedicated tool for it. Free during the founding beta. Same flow on Notion, HubSpot, monday.com, Smartsheet, Shopify, and QuickBooks Online.