A form goes live on Monday. By Thursday someone asks whether the third applicant ever got a reply, and nobody can answer, because the only record of that submission is a spreadsheet row that nobody opened. The usual first fix is a Google Forms email notification, so that at least one person sees each response as it arrives. That fix works, and it is worth setting up properly. It also has a shape, and knowing the shape early saves rebuilding the whole thing in three months.
There are three ways to get a Google Form to send mail, they fail in different places, and the difference matters as soon as more than one person is responsible for what comes in.
The built-in toggle, and what it actually sends
Google ships a notification switch inside Forms. Open the form, click Responses at the top, click the More icon, and click Get email notifications for new responses. That is the whole setup. From then on, the account that turned it on gets a message when a response lands.
The important detail is what that message contains. It is a notice that a response arrived, addressed to the form owner, with a link back to the form. It is not the answers, it is not addressed to a shared address, and it is not configurable. There is no subject line to edit, no second recipient to add, and no way to route submissions from the recruiting form to one person and submissions from the enquiry form to another.
Google itself points past this in the help article for managing responses: the tip under the toggle says that for more notification options and customised follow up emails to respondents, you should install the Form Notifications add-on. That is an honest admission of scope. The toggle exists so that a single owner does not miss a response. It was never built for a team.
One consequence catches people out. The notification goes to the Google account that owns the form. If that account belongs to a person who leaves, the notifications leave with them, and the form keeps collecting responses in silence. Forms created inside a shared drive avoid part of this problem, but the notification setting is still per user, not per form.
Three routes, and where each one stops
| Route | Setup effort | Who can receive | Contains the answers | Reply to the submitter |
|---|---|---|---|---|
| Built-in toggle | Two clicks | The account that enabled it | No | Not supported |
| Form Notifications add-on | Install and configure | Addresses you list | Yes | Supported by the add-on |
| Apps Script trigger | Code, tested | Anything the script sends to | Whatever you write | You build it |
| Form tool with response management | Sign up, build form | Team members and shared views | Yes, on the record | Built in |
The first three all end at an inbox. That is the thing they have in common and the reason they run out at the same point.
The add-on route
The Form Notifications add-on is published by Google in the Workspace Marketplace, and it does the two things the toggle will not: send the actual answers, and send a message to the person who filled in the form. Installation is a Marketplace grant, which means an admin in a managed Workspace domain may have to approve it before anyone can use it. Worth checking before promising a delivery date.
Add-ons run under the installing user's authorisation. The same succession problem applies. When the person who installed it moves on, someone has to install and configure it again.
The Apps Script route
This is the route engineering teams pick, because it removes every limitation above at the cost of owning the code. Open the form, go to the script editor, write a function that reads the submission, and attach it to an installable on form submit trigger. Inside that function you can format the answers however you like, set a subject line that includes the applicant's name, send to a shared address, and set the reply address to the submitter so a reply goes straight back to them.
It is perhaps fifteen lines. The cost is not the writing, it is the quotas.
The numbers that decide whether a script survives
Apps Script publishes its quotas, and they are per user and reset twenty four hours after the first request. Three of them decide whether a notification script keeps working.
Email recipients per day is 100 for consumer accounts such as gmail.com, and 1,500 for Google Workspace accounts. That is the number that ends most scripts. A recruitment form that sends one notification to a shared address and one confirmation to the applicant consumes two recipients per submission. On a personal Google account that caps out at fifty submissions in a day. A form attached to a campaign that lands on a Monday morning will exceed that before lunch, and the script does not degrade gracefully. It throws an exception and execution stops, which means the last responses of the day generate no mail at all and nobody is told.
Email recipients per message is 50. Fine for a notification, relevant if the same script also does a round of follow ups.
Triggers total runtime is 90 minutes per day on a consumer account and 6 hours on Workspace, and a single script execution is capped at 6 minutes. A notification script that does nothing but format and send never approaches this. A script that also writes to a sheet, calls an external API to enrich the submission, and generates a PDF will get closer than expected once volume rises.
You can check the remaining allowance from inside the script with MailApp.getRemainingDailyQuota(), which is worth logging. The failure mode people actually hit is not knowing they hit it.
There is a second, quieter cost. A script that sends mail is a piece of software that nobody owns. It has no tests, no alerting, and no on-call. When it breaks, the symptom is silence, and silence is exactly what the notification was supposed to prevent.
Sending a copy to the person who filled in the form
Half the requests that start as a question about notifications are really a question about the other direction: how does the person who submitted know it arrived. Google Forms supports this directly. In the form settings, under responses, you can collect respondent email addresses and send response receipts, either always or when the respondent asks for one. The receipt is a copy of what they submitted.
This is the single highest value thing to turn on, and it is often skipped. A receipt removes the duplicate submissions that arrive because somebody was not sure the first one went through, and it removes a whole category of email asking whether the application was received at all. Both of those land in the same inbox that the notification is trying to keep readable, so a receipt makes the notification more useful by making the inbox quieter.
It does not, however, tell the respondent anything about what happens next, because a receipt is a copy, not a reply. If the form is a job application, the receipt confirms the file arrived and says nothing about when a decision comes. That gap is where the follow up emails come from, and it is the reason the add-on route exists: the Form Notifications add-on can send a customised message to the respondent rather than a bare copy, which lets you set expectations in the same breath as the confirmation.
Where the notification stops being the problem
Notifications solve visibility for one person. Everything after that is the actual job, and no version of email notification touches it.
Consider what a team needs to know about a set of responses. Who is looking after this one. What stage it is at. Whether a reply has gone out and what it said. Whether the person who handled it last week is on holiday this week. An inbox answers none of these. It gives each person a private copy of an event and then relies on a chain of forwards and verbal agreements to keep two people from replying to the same applicant.
The failure is not dramatic. It looks like this: two replies to the same person with different information, one submission that nobody replies to because each person assumed the other had it, and a question two weeks later about what was agreed with a candidate that nobody can answer because the reply went out from a personal mailbox.
That is why the third route, Apps Script, so often becomes a fourth project. Once the script sends the notification, the next request is to write the status back to a sheet, then to send a reply from the sheet, then to stop two people sending the same reply. At that point the team has built a small response management system out of triggers, and it is still nobody's job to maintain it.
The alternative shape
The other option is a form tool that holds the response rather than forwarding it. The unit of work is the response itself, not a message about it. Each one carries an owner, a stage, and the history of what has been sent, and the reply goes out from the same screen where the answers are. Notifications still exist, and they go to Slack, Teams, Chatwork or Discord as well as email, but they are pointers into a shared record rather than the record itself.
Whether that is worth switching for depends entirely on how many people touch the responses. One person handling a contact form is well served by the built-in toggle and a response receipt. Three people handling applications need something that survives one of them being away, and that is a different tool, not a better script. The features page lays out what that looks like in practice, and the use cases show the shapes it tends to take: applications, event sign ups, enquiries, grant programmes.
Price also behaves differently depending on the model. Tools that meter responses charge more as the form succeeds, which is an awkward incentive for a recruitment campaign. Tools that charge by seat charge more as the team grows, which at least tracks the thing that actually made the work harder.
What to change first
Turn on response receipts today, before touching notifications at all, because it removes the most email for the least work. Then decide honestly how many people are responsible for what the form collects. If it is one, the built-in toggle is enough and the Apps Script route is a liability you do not need. If it is more than one, stop building notification plumbing and try a tool where the response, the owner and the reply live on one screen; the demo runs without an account so it takes about five minutes to find out whether that model fits, and Halict prices by the number of people rather than the number of responses, which is the variable that changed when the second person joined.
Q1. Can I send Google Forms notifications to more than one email address?
Not with the built-in toggle, which only notifies the Google account that turned it on. To reach several addresses you need either the Form Notifications add-on published in the Google Workspace Marketplace, which lets you list recipients, or an Apps Script trigger that sends to whatever addresses you specify. Both remain subject to the Apps Script daily recipient quota.
Q2. Why did my Google Forms notification emails suddenly stop?
The most common cause is the Apps Script email quota. Email recipients per day is capped at 100 for consumer accounts such as gmail.com and 1,500 for Google Workspace accounts, and when a script exceeds the quota it throws an exception and stops rather than queueing. The other common cause is that the account that enabled notifications no longer has access to the form.
Q3. Does the built-in notification include the answers from the form?
No. The built-in notification tells you that a response arrived and links back to the form. To receive the actual answers in the email you need the Form Notifications add-on or your own Apps Script function that reads the submission and formats it into the message body.
Q4. How do I let the person who filled in the form know it was received?
Google Forms can send response receipts. Collect respondent email addresses in the form settings, then choose to send a receipt either always or when the respondent requests one. The receipt contains a copy of what they submitted, which prevents duplicate submissions, though it does not tell them what happens next.
Q5. Is there a limit on how many responses a Google Form can collect?
The response collection itself is not the constraint people hit. The constraints appear in the automation around it: Apps Script caps email recipients per day, triggers have a total daily runtime limit of 90 minutes on consumer accounts and 6 hours on Workspace accounts, and a single script execution is capped at 6 minutes.