I noticed something was wrong when a long test email was classified based almost entirely on its opening sentence.
The category was plausible, but the priority and sentiment didn’t match the rest of the message. After checking what was actually being passed to the model, I found that the workflow had been sending only Gmail’s preview snippet—roughly the first couple of hundred characters—instead of the full email body.
The workflow had been running without errors, so I had no obvious reason to suspect anything was broken.
Three Gmail Trigger settings were behind it.
1. “Simplify” was enabled
The Gmail Trigger has Simplify enabled by default.
With it turned on, the output contains Gmail’s snippet rather than the complete message body. That meant my AI classifier was deciding the category, priority, sentiment, and recommended action from the email preview.
Short messages usually looked fine, which made the issue easy to miss. Longer emails—the exact messages where triage is most useful—could be classified before the customer had even explained the real problem.
Disabling Simplify fixed the message input, but it also changed the shape of several other fields.
2. With Simplify disabled, email addresses are objects
After turning Simplify off, the sender field was no longer always a simple string.
It could look something like this:
{
"value": [
{
"address": "customer@example.com",
"name": "Customer Name"
}
],
"html": "...",
"text": "..."
}
My Google Sheets log immediately started showing [object Object] in the From column.
I now normalise the sender before using it. The workflow accepts several possible formats—a plain string, a name and address object, or a raw header—and converts them into a consistent value such as:
Customer Name <customer@example.com>
3. “Read Status” was set to unread only
My Gmail Trigger polls every 15 minutes.
When Read Status was set to unread only, any email I opened before the next poll was skipped completely. It never reached the classifier, never appeared in Google Sheets, and never generated a Slack alert.
This was especially confusing during testing because I was constantly opening incoming messages to check whether the workflow had processed them.
I changed the setting to read and unread so manually opening an email no longer removes it from the workflow.
Current workflow
The workflow now looks like this:
Gmail Trigger
→ Code node: filter and normalise
→ HTTP Request: send the email to the AI model
→ Code node: parse and validate the response
→ IF node: check priority
├ high → Slack alert
└ all inquiries → Google Sheets log
There is also a fallback branch. If the classification request fails or returns invalid data, the inquiry is still logged and marked for human review instead of disappearing silently.
A few other mistakes I found
Blocking noreply@ removed genuine inquiries
I had noreply@ in the sender blocklist.
That turned out to be too aggressive. Many website contact forms send genuine customer inquiries from a generic noreply@ address and put the customer’s real address in the Reply-To header.
The workflow was discarding legitimate messages without leaving any record.
I now block only obvious delivery-system senders such as mailer-daemon, postmaster, and bounce@.
Email content can become a Google Sheets formula
A subject line beginning with = was interpreted as a live formula when written to Google Sheets.
Before writing user-controlled text to the sheet, the workflow now prefixes an apostrophe when a value starts with:
= + - @
Partial validation hid invalid model output
My original validator checked only the category and priority fields.
If the model returned an invalid sentiment value, the workflow replaced it with a default and still logged the classification as successful.
The validator now checks all six expected fields. If any value has to be substituted or repaired, the row is flagged so the classification can be reviewed.
What the workflow deliberately does not do
This workflow is intentionally read-only.
It does not:
- reply to messages
- delete or archive emails
- apply labels
- mark messages as read
- download or process attachments
Messages longer than 4,000 characters are truncated before being sent to the model.
The classification is treated as a signal rather than a final decision. A person still reviews the inquiries that matter.
I packaged the finished workflow with a setup guide here:
The Gmail Trigger settings above are worth checking even if you build the workflow yourself. I’m also happy to answer questions about the implementation.