# Treat Form Responses as Workflow State, Not Just Submissions > Source: > Published: 2026-06-24 01:09:01+00:00 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. 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 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. A common workflow looks like this: ``` php 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 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. 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. 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: