The Gmail Node

What it actually does

The Gmail node lets a workflow interact with a Gmail inbox directly — most commonly sending email, but also reading incoming messages, searching, and applying labels. It’s frequently the final step in an automation: the point where an automated process needs to actually notify a human, rather than just moving data quietly between systems.

The core operations split into two directions. Sending: compose a message with a to address, subject, and body (plain text or HTML), pulling any of those from earlier workflow data via expressions — so “send a confirmation email” can include the actual customer’s name and order details, generated fresh each time rather than a static template. Reading: search an inbox by sender, subject, label, or date range, and pull matching emails into the workflow as data to act on.

Like Google Sheets, this node needs a Google credential connected first — see the OAuth setup walkthrough if you haven’t done this yet. The same credential works across both nodes once it exists.

A worked example

The closing step of the Webhook example from earlier: a form submission triggers a workflow, the data gets tidied up, and a Gmail node sends a formatted notification email — subject line and body built from the actual submitted fields via expressions, so every notification is specific to that particular submission rather than a generic alert.

A read-based example: a Schedule Trigger runs every morning, a Gmail node searches for unread emails with a specific label (say, “Support”), and each one gets logged into a Google Sheets row for tracking — turning an inbox into a lightweight ticket log without needing dedicated helpdesk software.

The mistake almost everyone makes first

Sending plain text when HTML was intended, or vice versa — the node has a separate field/toggle for each, and pasting HTML markup into the plain-text field just sends the raw tags as visible text rather than rendering them. If an automated email arrives looking broken, with stray tags in it, this is usually the cause. Double-checking which mode is active before testing a real send avoids the classic “why does my email have `<b>` written in it” moment.