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:
Top comments (1)
Modeling each side effect as its own little state machine is where this stops being a form and starts being a real workflow. The one thing I'd add to that minimum record is a retry count and a last_attempt_at next to each state, so a failed auto_reply isn't just visible, it's something a worker can pick up and run again without a human noticing it broke. Once you have that, the whole thing is basically the outbox pattern wearing a form's clothes, and you get safe replays for free. Keeping the AI fields as suggestions separate from the confirmed columns is the part most people skip, and it's the difference between AI helping and AI quietly becoming the record.