A form has been collecting submissions for three weeks and nobody is quite sure who is answering them. Two people on the team turned on notifications, so both get the mail. One assumes the other replied. The other assumes the same. The submission from Tuesday is still sitting there, and the only reason anyone noticed is that the person who sent it followed up asking whether the form worked.
The notification itself is not the problem. Google Forms will tell everyone who asked to be told. What it will not do is decide who owns the submission, and that gap is where most form workflows leak. This covers what the built-in setting actually sends, the two escalation routes that exist inside Google's own tooling, the sending limits that come with them, and the point at which notifying people stops being the useful lever.
What the built-in setting sends, and to whom
The setting lives with the responses, not with the form design. Google's documentation for managing form responses gives the path as: open the form, click Responses at the top, click More, then click Get email notifications for new responses.
Two details about that switch matter more than the click path.
It is per person, not per form. The switch turns notifications on for the account that flipped it. Another editor who wants the same mail has to open the same menu and flip it for themselves. There is no field anywhere in the form where an address can be typed. This is why a form handed over to a new colleague goes quiet: the previous owner's notification is still running, and the new owner never turned one on.
It is a notice, not a record. The mail tells the recipient that a response arrived and gets them back to the responses. It does not become a task, it does not change state when someone acts on it, and it does not disappear when the work is done. Once two or three people have the switch on, the same submission exists as an unread mail in several inboxes at once, and every one of those copies looks identical whether the submission has been handled or not.
The second point is the one that quietly decides how well a form scales. A notification is a broadcast. Work needs an addressee. A form collecting five submissions a month survives the difference. A form collecting fifty does not.
Turning it off again
The same menu turns it off, and it is worth doing deliberately when a form is retired rather than leaving it running. Google's help page on the topic also notes that a collaborator who has access to the form may also have access to the form's linked spreadsheet, and that removing someone means removing them from the form and the spreadsheet separately. Access and notification are two different lists, and clearing one does not clear the other.
The add-on route
Google's own page points past the built-in switch: to get more notification options and to send customised follow-up emails to respondents, it directs readers to download the Form Notifications add-on. That is the sanctioned next step, and it is worth understanding what the step buys.
An add-on can do three things the built-in switch cannot. It can send to addresses that are not form editors, which is what makes routing possible at all. It can include the answers in the body of the mail, so the recipient can triage without opening the form. And it can send to the person who submitted, which turns a one-way collection into an acknowledgement.
What an add-on does not change is where the work lives. The submissions are still rows. The state of each row still lives in somebody's head or in a colour a person applied to a spreadsheet cell by hand. An add-on improves the alert and leaves the tracking alone.
There is also an ownership question that surfaces months later. An add-on runs under the account of the person who installed and authorised it. When that person leaves, or has their access reduced, the notifications stop, and the failure is silent. Nothing bounces. The form simply stops telling anyone, and the first sign is a complaint from outside.
Three things are worth settling before an add-on is installed on a form that matters. Which account will authorise it, and whether that account will still exist in a year. Whether the notification body will carry the answers, because an alert without content only moves the click somewhere else. And what the add-on does when it cannot send, since a rule that fails quietly is worse for a team than no rule at all. None of those questions is about features, and all of them decide whether the setup is still working next quarter.
The sending quota that comes attached
Both the add-on route and the do-it-yourself script route run on Apps Script, and Apps Script has published per-user daily quotas. The email recipients per day figure is 100 per day for consumer accounts and 1,500 per day for Google Workspace accounts. Trigger total runtime is capped at 90 minutes per day for consumer accounts and 6 hours per day for Workspace accounts.
Those numbers are generous for a contact form and tight for anything that mails both the team and the respondent at volume. A form taking 200 submissions a day, sending one internal alert and one acknowledgement each, is asking for 400 recipients. On a consumer account that fails four times over, and it fails by going quiet rather than by raising an error anyone sees.
The quota is counted per user, not per form or per script. Three different forms, each with its own notification script, all installed by the same person, draw from one pool of the same daily figure.
Routing by answer instead of by broadcast
Once routing is on the table, the question changes from who gets told to which submissions go to whom. There are only a few mechanisms available, and they differ in how much they cost to maintain.
| Mechanism | How routing is decided | What breaks it |
|---|---|---|
| Built-in notification | Not possible. Every subscribed editor gets everything. | Nothing, because nothing is routed |
| Add-on rules | A condition on an answer, set in the add-on | The answer wording changes and the rule silently stops matching |
| Apps Script trigger | Code reading the response and choosing a recipient | Nobody maintains it after the author leaves |
| Separate forms per team | The form's identity is the route | Respondents pick the wrong form |
| A form tool with response management | An owner field on the submission itself | The owner field is left empty |
The last row is different in kind from the others. The first four route an email. The last one routes the submission, which means the assignment survives after the mail is read, deleted or missed. Anyone looking at the list can see that submission 41 belongs to a named person and is still open, and that nothing else is unassigned.
The distinction becomes concrete when somebody is away. With email routing, a submission sent to a person on holiday sits in a mailbox nobody else opens, and the team does not know it exists. With an owner on the record, the same submission is visible and can be reassigned in a second. Reviewing how other teams structure that split is easier with worked examples, and the use cases page is organised that way.
Do not route on a free-text field
Where routing is implemented on an answer, the answer needs to be a fixed choice. A dropdown with five options routes reliably. A short-answer field asking which department the request is for produces spellings and abbreviations no rule anticipated, and those submissions fall through to whatever the default branch does, which is often nothing.
Telling the person who submitted
Half of the follow-up traffic on a form is people asking whether their submission arrived. Google supports an answer to that without any add-on, and the setting is separate from the internal notification. Email collection has to be on, chosen as either verified or responder entry, and then next to Responses the option Send responders a copy of their response can be set to when requested or to always.
Google's own documentation attaches a caveat worth repeating internally: in certain circumstances respondents may not receive expected response receipts, because of spam filters or other counter-abuse measures. A receipt is best effort. It reduces the follow-up volume without eliminating it, and it should not be the only record on the respondent's side of anything that matters.
The receipt also has a second effect that is easy to miss. It gives the respondent a message to reply to. Those replies arrive as ordinary mail, outside the form, with no connection to the row they belong to. A team that adds receipts without deciding where replies land has moved the mess rather than cleared it.
Where notifications stop being the lever
There is a point at which adding notification machinery makes a workflow worse. The signs are recognisable.
Several people get the same mail and none of them is named as responsible. Someone has to search a mailbox to find out whether a submission was handled. A submission's status is a colour in a spreadsheet, or a reply buried in a thread. The question "what is still open" cannot be answered without asking around.
A useful diagnostic is to count the steps between the alert arriving and the reply going out. On a form wired only with the built-in switch, the count is typically five: read the mail, open the responses, find the row, check whether a colleague already answered, then compose a reply somewhere else entirely. Four of those five steps exist only because the record and the reply live apart. Adding a better notification shortens none of them, and an add-on that includes the answers removes one at best.
None of those is fixed by a better alert. They are all the same missing piece: the submission has no state and no owner, so every fact about it has to be reconstructed from mail. Notifications multiply the copies of the question without answering it.
That is the argument for handling the reply where the submission lives. When each response carries an owner and a status, the notification goes back to being what it should be, a nudge, and the record stays in one place. Tools built this way tend to price on the number of people rather than on submission volume, which matters for a form whose traffic is unpredictable, so it is worth reading the pricing page of any candidate before counting responses.
What to change first
Before installing anything, check whether the form's notifications are still going only to people who have left or moved on, because that single check explains most forms that appear to have stopped working. Then decide who owns a submission as a written rule, not as a habit, and pick the mechanism that can express that rule. If the answer is that each response needs a named owner and a status that outlives the email, that is the case for moving the work into a tool that holds both, and the shortest way to see the difference is the demo of a form tool like Halict.
Q1. Why am I not getting email notifications from my Google Form?
The notification switch is per account, so it has to be turned on by each person who wants the mail, under Responses and then More in the form. A form inherited from someone else will still be notifying them and not the new owner. Check the switch on the account that expects the mail rather than assuming the form is broken.
Q2. Can a Google Form send a notification to someone who is not a form editor?
Not with the built-in setting, which only notifies the account that enabled it. Sending to an arbitrary address requires an add-on or an Apps Script trigger, and Google's own documentation points to the Form Notifications add-on for exactly this. Both routes run under the account that authorised them.
Q3. Does the built-in notification include the answers?
The built-in setting tells the recipient that a response arrived and takes them back to the form's responses. Including the answers in the body of the mail is one of the reasons teams move to an add-on. If triage needs to happen from the mail itself, the built-in switch will not be enough.
Q4. How many notification emails can a Google Form script send in a day?
Apps Script publishes a quota of 100 email recipients per day for consumer accounts and 1,500 per day for Google Workspace accounts, counted per user rather than per form. A setup that mails both the team and the respondent uses two recipients per submission. Exceeding the quota stops the sending without any visible error on the form.
Q5. Should each submission get its own owner, or is a shared inbox enough?
A shared mailbox works while everyone can see the whole list and the volume is low enough that nothing is missed. Once submissions need a status that survives the email being read or deleted, a named owner on the record does what a mailbox cannot. The practical test is whether anyone can answer what is still open without asking a colleague.