Log selected Gmail messages to Google Sheets with Make

Choose a message-level record

Treat one row as one message, not one customer or one subject. Different requests can share both sender and subject. Preserve the provider’s message identifier as the ingestion key. If the business needs case-level status across an email thread, design that case record separately. A message ledger should not silently merge a new enquiry into an older one merely because the wording looks similar.

Prepare a narrow label and a dedicated sheet

Create a practice label containing three messages you control. Prepare columns for message_id, received_at, sender, subject and processed_at. Leave the body out initially. Check who can read the sheet compared with who can read the mailbox, since the automation creates another copy with potentially different permissions. Give the practice table a clear owner before expanding its fields.

Configure the Gmail watcher

Add Gmail > Watch emails and restrict the source using the available label, folder or query settings. Keep the first result limit at one and review the starting point. Do not use unread status as the only evidence of ingestion: a person reading the email changes that state independently. Mailbox reading and ledger completion need separate meanings.

Check the key before appending a row

Look up message_id before appending the ledger entry. Configure the search to continue when it finds nothing, and verify the resulting empty-result filter using the module output. If the ID already exists, do not append. Search-then-insert is still vulnerable to concurrent writers. For a strict uniqueness requirement, use a destination that enforces the key atomically rather than relying on a spreadsheet search.

Map the record and update processing state last

Map the identifier, received time, sender address and subject into their respective columns. Distinguish a display name from the actual sender address. If a processed label is part of the design, apply it after the write and retain the ledger key as evidence. Exclude credential messages and other secrets from the logging scope; they have no place in an operational worksheet.

Test distinct messages and a replay

Test a normal message, a different message with the same subject and one with no body. Each distinct identifier should produce one row. Then replay an already recorded message and verify the deduplication path. Compare source IDs with stored IDs, not just total row counts. An equal count can conceal one missing message and one duplicate.

Common question: should the ledger include read or historical mail?

An unread-only rule can omit messages someone opened before the workflow checked them. Prefer business scope such as a dedicated label or approved source instead of treating reading state as intake eligibility. Historical ingestion needs its own period and limit rather than silently joining the live stream.

Run a small historical sample before widening the range, then reconcile IDs and subjects. Starting a backfill and live intake together complicates deduplication and allowance planning. Also prevent historical messages from generating alerts that make old enquiries appear newly received to the team.

Recover from a successful write and failed label update

If the sheet write succeeds and a later label change fails, the row still exists. Search by message ID before choosing the recovery action. Repair the missing state when appropriate instead of blindly replaying the write. Also review acquisition frequency separately from saved-message volume so a quiet inbox does not conceal an unnecessarily frequent polling schedule.

• Prevent duplicate writes in Make with stable keys and recovery states
• Handle Make errors: execution history, incomplete runs and safe retries
• How to estimate Make credits: polling, rows and retries
• Send form confirmation emails with Make: recipients, content and delivery state