A form response is often treated as a row.
That is fine for collection.
It is not enough for operations.
Once a person or system needs to act on the response, the row needs workflow state.
owner
status
next_action
notification_state
review_state
last_event_at
Without those fields, the response exists but the work is ambiguous.
A Submission Is An Event
The submit event answers one question:
Did someone send the form?
That event can trigger useful work:
send an auto-reply
post to Slack
append to a spreadsheet
create a CRM record
ask AI for a summary
But those side effects do not answer the operational questions:
Who owns this?
Is it new, in progress, done, or excluded?
Was the notification sent?
Does a human need to review it?
What is the next action?
Those questions need state.
The Minimum Response State Record
The first useful record can be small.
response_id
source_form
submitted_at
payload_summary
owner
status
next_action
notification_state
ai_summary_state
human_review_state
exclusion_reason
last_event_at
The key is not the storage choice.
It can live in a database, CRM, Sheet, Airtable, or internal admin view.
The key is that the team agrees what each field means.
Side Effects Are Not Status
A common workflow looks like this:
Form submitted
-> Slack notification sent
-> email sent
-> row appended
That can work for a prototype.
In production, each side effect can succeed or fail independently.
slack_notification_state = sent
auto_reply_state = failed
crm_sync_state = pending
status = new
The response can still be new even if Slack was notified.
The auto-reply can fail even if the response was saved.
The CRM sync can be pending while the owner is already assigned.
Do not collapse these into a single done flag.
AI Output Is Not The Source Of Truth
AI can be useful here.
It can summarize, classify, detect urgency, suggest an owner, or draft a reply.
But the model output should be stored as suggestion state, not final operational state.
owner_candidate
suggested_category
ai_priority
reply_draft
human_check_required
Then keep confirmed fields separately:
owner
final_category
final_priority
sent_reply_at
status
This gives you AI assistance without making the model the source of truth.
Queries Become More Useful
Once response state exists, the questions get better.
Instead of:
Summarize these responses.
You can ask:
Show high-priority responses with no owner.
Summarize responses that have been new for more than three days.
Find low-score responses with follow-up permission.
Show excluded responses and their reasons.
Summarize recurring themes from done responses this month.
The AI step becomes more useful because the data carries operational memory.
A Practical Rule
If a submitted response can affect a customer, applicant, attendee, lead, support request, or internal decision, treat it as workflow state.
At minimum:
[ ] Keep the original response
[ ] Add owner
[ ] Add status
[ ] Add next_action
[ ] Separate notification state from response status
[ ] Separate AI suggestions from confirmed fields
[ ] Require a reason for exclusion
[ ] Log state changes
That is the difference between form collection and form automation.
The broader FORMLOVA form automation model is here:
