Google Forms and CodeWords: automating what happens after submit

Google Forms is the path of least resistance for collecting anything, which is why organisations end up with dozens of them and no idea what happens to the answers. Somebody exports a sheet occasionally. Somebody else checks the email notification when they remember.

Automating the downstream is worth doing, and the first decision is not what to build but what to trigger from — because the Forms API is narrower than most people assume, and the linked Sheet is often the better hook.

What we'll cover

• Where to trigger from
• What the Forms API reaches
• Question schemas, which break in a specific way
• Connecting it to CodeWords
• Seven automations worth building
• Routing responses to the right place
• When Forms is the wrong tool
• Junk, and what to do about it
• Building it so it survives
• What to build first
• Frequently asked questions

Where to trigger from

Three options, and they suit different situations.

The Forms API with watches. Google Forms supports watches that notify on new responses, and this is the cleanest option when you want the response as structured data with its question identifiers intact.

The linked Sheet. Responses land in a spreadsheet, and reacting to new rows there is simple, widely supported, and gives you a durable record you can re-read. The cost is that the Sheet flattens everything to text and column headers rather than stable identifiers.

Apps Script on submit. A script bound to the form can fire on submission and call out to anything. It is the most flexible and it puts logic inside Google's environment, where it is easy to write and easy to forget about.

For most purposes, watch the Form and keep the Sheet as the record. The Sheet is easier to start with; the Form gives you identifiers that survive somebody renaming a question, which is the thing that breaks these automations.

What the Forms API reaches

Form structure — the questions, their types, their options, and their identifiers.

Responses can be listed and read individually, including per-question answers keyed by question identifier.

Watches notify on new responses or on structural changes to the form.

Form creation and editing is supported, including adding and modifying questions, which suits generating forms programmatically.

File upload questions put files in Drive, and the response carries a reference rather than the file itself, so anything processing uploads also needs Drive access.

Quiz grading is available where the form is a quiz, including scores and feedback.

What it does not give you is a general event stream or anything about partial responses. A person who started and abandoned leaves no trace.

Question schemas, which break in a specific way

Form automations break for one characteristic reason: somebody edited the form.

Renaming a question changes its title and keeps its identifier. Automation matching on the title breaks; automation matching on the identifier does not. This alone is the argument for using the API rather than the Sheet.

Adding a question shifts columns in the linked Sheet, which breaks anything reading by position.

Removing a question leaves historical responses that have it and new ones that do not.

Changing a question type — a text field becoming a dropdown, say — changes the shape of the answer.

Reordering changes the Sheet's column order.

Match on identifiers, validate the form structure against what your automation expects, and report when it has changed rather than processing the response incorrectly. Forms are edited casually and by people who have no idea anything depends on them.

Connecting it to CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which form, and what each kind of response should produce.
3. Authorize the connection to Google, including Drive access if the form accepts file uploads.
4. Describe the exceptions: a missing required answer, an unfamiliar question, a response that looks like spam.
5. Submit a test response yourself and watch it flow through before announcing the form.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Seven automations worth building

Create the record where the work happens. A lead in the CRM, a ticket in the helpdesk, an issue in the tracker — whichever system owns that kind of request, with the answers mapped onto real fields rather than dumped into a notes box.

Route by content. Different answers go to different teams, with the relevant people notified where they already work rather than in an inbox they check twice a day.

Acknowledge the submitter. A confirmation that says what happens next and roughly when. Forms can email a copy of responses; what it cannot do is tell somebody what to expect.

Validate and follow up. Check the answers for missing or implausible information and ask for what is needed, rather than discovering it three days later.

Process uploaded files. Read the document, extract what matters, and attach it to the record rather than leaving it in a Drive folder.

Summarise open text. Free-text answers accumulate unread. A periodic summary of themes makes them useful.

Report on the form itself. Submission volume, completion patterns, and which forms have gone quiet. Forms outlive their purpose and nobody retires them.

Routing responses to the right place

Decide what the response is for. A request, a report, a sign-up, and a complaint belong in different systems, and a single form often collects more than one kind.

Map answers to fields, not to a blob. A record where the answers are in real fields is searchable and reportable; one where they are pasted into a description is neither.

Preserve the original. Keep a link back to the response, since a mapping will eventually lose something and somebody will need to see what was actually submitted.

Deduplicate on something stable. The same person submits twice — because they were not sure it worked. Keying on email plus a short window catches most of it.

Handle the anonymous case. Forms that do not collect email produce responses you cannot follow up on, which is worth knowing before you build a follow-up.

When Forms is the wrong tool

Worth saying, since Forms gets used well past its range.

Conditional logic beyond sections is limited. Complex branching becomes unmanageable.

No validation against your own data. Forms cannot check whether an order number exists.

No partial saves for long forms, so anybody interrupted starts again.

No structured file handling beyond Drive links.

No editing after submission unless enabled, which surprises people who mistyped something.

For internal collection and simple external intake, Forms is genuinely good and the automation described here makes it better. For anything transactional or anything where the answers must be valid against your systems, a form that can validate is the better investment.

Junk, and what to do about it

A form linked publicly collects submissions from people who are not your audience, and the automation downstream will faithfully create a record for every one.

Expect automated submissions on any form reachable without a sign-in. The volume varies and it is rarely zero.

Check plausibility before creating records. An email that does not resolve, a message of pure links, and a name matching the message body are all cheap signals.

Quarantine rather than discard. Route suspicious submissions to a holding list a person can scan, because the cost of dropping a genuine enquiry is much higher than the cost of a short review list.

Restrict where you can. Requiring sign-in for internal forms removes the problem entirely, and it is often available and simply not switched on.

Do not send automated replies to unverified addresses at volume, since replying to forged addresses damages your sending reputation for everybody.

Report the rate. A sudden rise usually means the form's link has been picked up somewhere, which is worth knowing.

Building it so it survives

Match on question identifiers, not titles or column positions.

Validate the form structure against what you expect, and report changes rather than guessing.

Make it idempotent. Record the response identifier before creating anything downstream, since watches can deliver more than once.

Handle uploads as references. The response points at a Drive file, so grant Drive access and expect the file to be large.

Report the outcome. Responses processed, records created, and anything skipped with the reason.

What to build first

The acknowledgement with expectations: when somebody submits, they hear what will happen and roughly when. It takes very little building, it needs nothing beyond read access to responses, and it removes the follow-up email from somebody who is not sure the form worked.

Two habits make the difference. Say what happens next specifically rather than "we have received your submission", which tells the submitter nothing they did not already know. And send it only after the downstream record exists, so the acknowledgement is not sent for something that failed to file.

Frequently asked questions

Should I trigger from the form or the linked Sheet?

The form, through a watch, because you get question identifiers that survive renaming. The Sheet is easier to start with and it breaks when somebody edits the form, which happens more often than you would expect.

Why did my automation stop working?

Somebody edited the form. A renamed question, an added question shifting Sheet columns, or a changed question type will all do it. Matching on identifiers and validating the structure prevents the silent version of this failure.

How do I handle file upload questions?

The response carries a Drive reference rather than the file, so the automation needs Drive access as well as Forms access. Process from Drive, and expect uploads to be larger than you planned for.

Can I stop duplicate submissions?

Not at the form, reliably. Deduplicate downstream on email plus a time window, which catches the common case of somebody submitting twice because they were not sure it went through.

Can Forms validate answers against our own systems?

No. Forms validates format, not facts, so it cannot check whether an order number exists. You can validate after submission and follow up, which is worth building, or use a form that can validate if correctness at entry matters.

What should the confirmation say?

What happens next and roughly when, plus a reference if a record was created. "We have received your submission" tells the person nothing, which is why they email to ask.

Is Apps Script or the API better?

The API for anything that belongs with your other automation, since it is visible, versioned, and maintained alongside everything else. Apps Script is convenient and tends to become undocumented logic inside Google that nobody remembers exists.

How do I stop junk submissions creating records?

Check plausibility before creating anything and quarantine what looks wrong, rather than discarding it. Any form reachable without a sign-in collects automated submissions, and a holding list a person scans occasionally is much safer than a filter that silently drops enquiries.

Should the automation reply to every submission?

Not to unverified addresses at volume. Automated replies to forged addresses harm your sending reputation, so confirm the address looks genuine, or reply only once a record has been created successfully.

Can I reuse one form for several purposes?

You can, and it makes the routing harder and the responses less useful. A form collecting requests, reports, and sign-ups at once produces records that fit no system properly. Separate forms are easier to route and easier to abandon when one stops being needed.

Related reading

• Typeform and CodeWords
• Google Sheets MCP
• CodeWords integrations and templates