Email routing combines a service trigger with deterministic filters, optional
AI classification, and one branch per destination.
Start with the narrowest trigger
Use a Gmail or Outlook new-email trigger and configure its built-in filters
when possible. Trigger filters avoid creating runs for messages the automation
will never process.
Remember that subject matching can be case-sensitive. Test with the exact
capitalization and message shapes that arrive in the real mailbox.
Choose deterministic or AI routing
Use deterministic text and logic actions when the rule can be stated exactly:
- sender domain equals a known customer or vendor,
- subject starts with a fixed prefix,
- a label is present,
- body contains a specific identifier.
Use OpenAI Chat with structured output when
the distinction depends on meaning rather than a fixed phrase. Keep the schema
small:
Put hard safety rules before AI classification. For example, ignore your own
automated senders and known newsletters before paying to classify the
remaining messages.
Build the branches
Connect route to a case-selection action or compare it in separate branches:
sales can forward to the sales queue.support can add a label and draft a reply.billing can notify the billing team with the summary.ignore can end without a side effect.
Use Conditional on side-effect actions so only the
matching branch runs. Independent preparation branches can still run
concurrently.
Avoid mail loops
A workflow that sends, forwards, or labels mail can trigger another
email-based workflow—including itself. Filter automated senders, dedicated
labels, or recognizable headers so generated messages do not loop.
- Send representative messages for every route.
- Confirm the trigger data contains the body and attachments you expect.
- Inspect drafts before switching to automatic replies.
- Test the fallback branch for ambiguous messages.
- Review Run History for node errors even when a run status says completed.
See Service event triggers for account and event
lifecycle behavior. 
