A new lead in a spreadsheet should reach the person responsible for following it up. This walkthrough designs a Make scenario that reads new Google Sheets rows and sends a short alert to one fixed internal address. A processing register limits duplicate sends.
This is a documentation-based walkthrough, checked on October 4, 2026. It was not executed in a Make account for this article. All sample inputs and expected results are synthetic, not actual Make output.
1 Prepare a limited test environment
Create a test spreadsheet named lead_alert_lab with a leads tab. Use an authorized Google connection and a test mailbox you control. Review requested permissions before creating a connection. Selecting one tab in a module does not necessarily limit the Google authorization to that tab.
The workflow needs spreadsheet reading and email sending. A built-in connection may request broader permissions; this guide does not promise a send-only Gmail connection. Do not add Additional scopes or custom OAuth credentials without a defined need. Exclude sensitive data.
Approve one internal recipient before testing. The lead’s contact address is not the alert recipient. The example alerts@example.com is a placeholder, not a working test destination. Replace it with your own approved test mailbox before sending.
2 Define the input and stable identifier
Use these headers in columns A through F:
- lead_id: the unique event identifier supplied by the source
- created_at: an ISO 8601 timestamp stored as text, including its timezone
- contact_name: a display name
- contact_email: a reply address, if the business needs to retain it
- request_type: a short value such as consultation
- source: a value such as website
Synthetic input, not Make output:
- lead_id: L-1001
- created_at: 2026-10-04T09:30:00+03:00
- contact_name: Example Contact
- contact_email: lead@example.com
- request_type: consultation
- source: website
The same event must retain the same lead_id on another attempt. A row number is unsuitable, and generating a fresh random ID on every run defeats duplicate checking. Append rows without blank gaps. Avoid renaming columns or sorting while testing.
3 Configure the spreadsheet trigger
Create a scenario with Google Sheets > Watch New Rows. Select the test file and leads tab. Set Table contains headers to Yes, Row with headers to A1:F1, and Limit to 1 for the first test.
In Choose where to start, use All only for the isolated sheet containing your single example. That option can process historical rows in an existing sheet. Save the complete scenario as well as the module.
This polling trigger checks when the scenario runs; adding a row does not promise instant delivery. Keep scheduled activation off while building. A blank row within the table can prevent subsequent rows from being processed.
Add a filter before the next module: lead_id exists AND the length of trim(lead_id) exceeds zero; request_type exists AND the length of trim(request_type) exceeds zero. Insert actual mapped source tokens when building these expressions. A blocked row needs manual review; a filter does not create an error queue.
4 Reserve each lead before sending
Before creating the store, check the account’s unused allocation. According to Make’s documentation, Free includes 1 MB of Data store storage, and each store requires at least 1 MB. That allocation supports one store, not several separate stores for these exercises at the same time. If it is already allocated, stop before creating another store; do not delete existing data or activate a paid upgrade just to follow the exercise.
Create a test Data store named lead_alert_state with a text field called state. Use lead-alert: followed by the mapped lead_id as its key, for example lead-alert:L-1001.
Add Check the Existence of a Record and allow only Boolean false onward. Then add Add/Replace a Record with the same key, state=pending, and Overwrite an existing record disabled. An existing-key error must stop this path rather than bypass the guard.
Recording pending before sending is deliberate: a fresh run should not automatically repeat an email simply because the final step failed. This is a practical guard, not an exactly-once guarantee across services. Avoid overlapping tests or another scenario using the same keys.
In Scenario settings, enable Process data in order and Commit after each module. Keep Store incomplete executions off for this exercise. Attach a Commit error route to Gmail and the final register update. This deliberately preserves pending on failure and stops for review without adding automatic incomplete-execution retries.
5 Map a minimal email
Add the current Gmail > Send an email module, V4. Set To to the fixed test address. Leave CC, BCC and attachments empty, and use the connected sender.
Build Subject from the fixed text “New lead ” and the mapped lead_id. Choose Collection of contents and enter a short text item containing only lead_id, request_type and source. For example:
“New lead L-1001 requests consultation. Source: website. Follow-up details are in the leads sheet.”
This is a synthetic expected message, not a sent email. Names and addresses stay in the sheet. Avoid inserting free-form input into an HTML template; user text added to HTML later needs appropriate escaping.
After Gmail, add Update a Record with the same key and state=sent. Keep Insert missing record disabled, so a missing reservation is not quietly treated as a completed workflow.
6 Test outcomes and ambiguous failures
After checking the recipient and mappings, use Run once in the authorized test environment. Success means one message in the test inbox with L-1001 in the subject, plus a sent record. Module success does not establish inbox delivery.
Synthetic edge cases and expected outcomes:
- Append L-1001 again: no additional email
- Submit L-1002 without request_type: blocked before pending is recorded
- Pre-existing pending record for L-1003: no automatic fresh send; investigate
- Blank row before L-1004: inspect the table gap before resetting the trigger
- Two different lead IDs sharing one contact address: two distinct events
If sending succeeded but the sent update failed, retain the key. Reconcile the sender’s Sent folder and test inbox, then repair only the register when the evidence matches. A send timeout leaves an uncertain outcome. Do not delete pending and blindly replay. Check for scheduled automatic attempts before starting a manual recovery.
Fix authorization failures in the approved connection and field errors in the mapping. For rate or volume limits, inspect both Make and the mail provider, slow down and wait as directed by the error. Repeated Run once clicks do not resolve the cause.
Commit stops the whole run, not just the failed lead. If you later increase Limit, retain the fetched lead IDs and reconcile every one against the register. Later items may not have been processed, and ordinary Run once may not retrieve them again. Replaying historical input requires checking keys and recipients first because it revisits successful steps too.
7 Decide when to activate
Choose a checking interval that reflects the team’s response needs and is available on your plan. Trigger checks, register modules and sending may consume credits even at low volume. Inspect actual consumption, storage allowance and mail sending limits before expanding; this article provides no measured cost estimate.
Assign someone to review blocked rows and lingering pending records. Decide how long to retain event keys: removing them too early removes protection against old events returning. Move beyond the test sheet only after duplicate handling and recovery have been demonstrated in your own environment.
Download the practice files
This pack contains original, manually authored examples, fictional data and expected test outcomes. It has not been executed in Make, is not an importable blueprint and does not run an automation. Use it with the guide in an authorized test environment only.
Download the Make practice pack (ZIP, 6 KB)
For workflow fit, costs and maintenance, read our Make review for small businesses.
Sources
- Make Help Center: Data stores
