All articles
4 min readmandda

Submissions are not rows: the case for treating intake as records

Ask a team what happens after someone submits their intake form and you'll usually get a two-part answer. The first part is confident: the response lands in the...

Ask a team what happens after someone submits their intake form and you'll usually get a two-part answer. The first part is confident: the response lands in the form tool. The second part is vague: "and then we work it."

That vagueness is where the operational cost hides. The response is a row. The work is everywhere else.

What a row can't hold

A row holds what the person typed. That's all it was ever asked to do.

But the moment a submission enters a workflow, facts start accumulating that the person who submitted it never provided:

  • Who owns this now.
  • What state it's in — new, in review, waiting on the requester, closed.
  • How urgent it is, relative to everything else in the queue.
  • What was decided, and by whom, and when.
  • What it was classified as, once someone actually read it.

None of that is answer data. It's operational data — and a row has no column for it, so it gets exiled. To a spreadsheet where someone maintains a status column by hand. To a ticketing system that holds a link back to the form. To a Slack thread that holds the real reasoning and disappears in three weeks.

Now you have two records of the same thing, and neither is complete. The form tool knows what was submitted but not what happened. The ticket knows what happened but shows a stale copy of what was submitted. Reconciling them is a permanent, low-grade tax on everyone who touches the queue.

The shape that actually fits

The fix is structural, not procedural. Stop modelling a submission as the answers and start modelling it as a record: the answers, plus the operational state that accumulates around them, in one place.

Three properties make that record hold up under real use.

Operational state is structured, not freeform. A status field with defined values behaves very differently from a notes field where people write "waiting on legal?? (see thread)". Structure is what makes a queue filterable, reportable, and automatable. It's also what lets an agent participate: a machine can set a defined state; it cannot reliably maintain a prose convention.

The metadata schema is versioned. Operational needs change — you add a priority level, you split one status into two. If the schema is versioned, records captured under the old shape stay readable and the migration is a decision you make deliberately rather than a silent data corruption you discover a quarter later.

Every surface writes to the same record. A person triaging in the interface, a REST client, and an agent over MCP are all updating one object. This is the property that actually eliminates reconciliation, and it only holds if the write paths were designed together rather than bolted on in sequence.

What changes when the shape is right

The visible win is that the queue becomes real. You can ask "what's unassigned and older than two days" and get a true answer, because assignment and age are properties of the record rather than of someone's memory.

The larger win is that automation becomes safe to introduce incrementally. When operational state is structured and shared, an agent can take on the narrow, boring part — classify this, enrich that, route the obvious ones — and a human can see exactly what it did, in the same view, on the same object. You don't need to trust the automation completely to get value from it, because its work is legible and reversible. Compare that to automation that acts through a private side-channel and reports back in a webhook log.

The third win is the one teams notice last: history. When decisions land on the record, the answer to "why was this rejected in March" is one lookup instead of an archaeology project across three tools.

Where to start

You don't need to rebuild your intake to test this. Take the single form that generates the most follow-up work and write down every question your team currently answers outside the form tool. Owner? Status? Priority? Decision?

That list is your metadata schema. If your current platform has nowhere to put it, you've found the reason the work feels heavier than the volume justifies — and you've found what to look for in whatever you replace it with.