Treat Form Responses as Workflow State, Not Just Submissions

A developer argues that form responses should be treated as workflow state rather than mere data submissions. The post outlines a structured approach with fields like owner, status, and next_action, and emphasizes separating AI suggestions from confirmed operational state to enable better automation and querying.

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: