Send form confirmation emails with Make: recipients, content and delivery state

Check whether a native receipt already solves the job

Inspect the form service’s own receipt option first. Add Make when the job needs a specific reference number, selected support contact or other data assembled outside the standard receipt. More configuration also means more ownership. Write one sentence explaining the missing behavior before building, so the new workflow has a clear reason to exist.

Prepare the source and delivery columns

Use columns for request_id, email, category, receipt_sent_at and receipt_message_id. During the first trial, force the recipient to an inbox you control. A syntactically valid email address does not prove ownership, so avoid echoing sensitive form answers. The receipt only needs a reference and the next expected step, not a full copy of everything the person submitted.

Select new responses and validate required values

Read new responses and require the reference and recipient fields before the send action. Where a replay or repair path can revisit a row, inspect its delivery state as well. Put invalid addresses into an operator review queue instead of retrying indefinitely. Keep sender settings and administrative destinations under configuration control rather than accepting arbitrary values from the form.

Configure the Gmail receipt

Add Gmail > Send an email with the approved sender account. Map the recipient and use a subject such as “Enquiry received: TEST-001.” A suitable body acknowledges the reference and says the team will review it. Only state a response deadline if the business can meet it. Keep links and formatting simple while verifying the first version.

Record the message after a successful send

After a successful Gmail action, update the source with the send time and returned message ID. Marking it sent beforehand can hide a failed email. The reverse sequence still has an ambiguity window if email delivery succeeds but the state write fails. Document that case explicitly; a sent flag is useful evidence, not an exactly-once guarantee across two separate services.

Review a controlled test email

In the controlled inbox, inspect recipient, sender, subject, body and the address used when replying. Check a missing optional field, then a different request ID. Separately test your replay rule for an already processed ID. A provider accepting a send request and a person seeing the intended email are different observations; record both where you can.

Common question: how much submitted content belongs in the receipt?

A form may contain someone else’s email address. Keep sensitive answers out of the receipt until the recipient’s identity is appropriate for the disclosure. Be careful when incorporating submitted text into an HTML body so it does not unintentionally become markup or a misleading link.

When someone reports a missing receipt, use the intake reference to distinguish the saved request from the email outcome. A failed acknowledgement does not normally mean an already stored enquiry was never received. That separation helps support staff repair the communication without creating a duplicate business request.

Investigate before resending

After a timeout or bookkeeping failure, inspect Gmail’s sent items and any returned identifier before retrying. If the message exists, repair the record instead of sending another acknowledgement. As volume grows, verify the account’s current sending limits and intended use. A transactional receipt example should not be expanded into bulk promotional sending without choosing an appropriate delivery service.

• Send Google Forms responses to Slack with Make and Google Sheets
• Prevent duplicate writes in Make with stable keys and recovery states
• Handle Make errors: execution history, incomplete runs and safe retries
• Make pricing: choose a free or paid plan around your workload