Posted on Jun 24 • Edited on Jul 18
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
Enter fullscreen mode Exit fullscreen mode
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?
Enter fullscreen mode Exit fullscreen mode
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
Enter fullscreen mode Exit fullscreen mode
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?
Enter fullscreen mode Exit fullscreen mode
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
Enter fullscreen mode Exit fullscreen mode
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
Enter fullscreen mode Exit fullscreen mode
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
Enter fullscreen mode Exit fullscreen mode
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
Enter fullscreen mode Exit fullscreen mode
Then keep confirmed fields separately:
owner
final_category
final_priority
sent_reply_at
status
Enter fullscreen mode Exit fullscreen mode
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.
Enter fullscreen mode Exit fullscreen mode
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.
Enter fullscreen mode Exit fullscreen mode
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
Enter fullscreen mode Exit fullscreen mode
That is the difference between form collection and form automation.
The broader FORMLOVA form automation model is here:
답글 남기기