Trigger CloudFlow flows with an email

Every published flow can now have its own email address. Send an email to it, and the flow runs. That's the whole feature.

CloudFlow is the FinOps practice automation platform built into Cloud Intelligence™: you build flows that call AWS, Google Cloud, Azure, Oracle and even Cloud Intelligence™ APIs to automate FinOps and CloudOps work — tagging resources, acting on alerts, removing stale resources, etc. Every flow starts with a trigger, and today there's a new one.

You can already trigger a flow from schedules, webhooks, and Cloud Intelligence events (new anomaly, budget threshold met, etc.). Webhooks are great when the sending system supports them. But a lot of the tools you rely on day to day don't. Legacy monitoring systems, ticketing tools, internal apps, that one vendor dashboard nobody wants to touch, what they all can do is send an email. Until now, connecting those to CloudFlow meant standing up middleware or a third-party automation tool just to convert an email into an HTTP call.

Now you skip that step. Add an Email trigger to your flow and publish it. The flow gets a unique, unguessable address like [email protected]. Point your tool's email notifications at it, and every delivery starts a run — with the sender, subject, body, and attachment metadata available to downstream nodes like any other trigger data. If the email body is JSON, we parse it for you, so machine-generated emails arrive as structured fields, not text you have to dissect.

Two examples of where this lands well:

Alert-driven remediation. Your database monitoring tool only sends email alerts. Point them at a flow that extracts the affected service with an LLM node, checks severity, opens a Jira ticket, and posts context to the on-call Slack channel — before anyone has opened their inbox.

Acting on machine-generated emails. A vendor system emails you a nightly JSON report. A flow reads the parsed body, branches on the numbers, and only pings a human when something actually needs attention.

Since email sender addresses can be forged, we didn't stop at the unguessable address. You can restrict senders to specific addresses or whole domains, and verified-sender checking is on by default — emails that fail SPF/DKIM authentication for the sender's domain are rejected outright.

See it in action, start from the template we shipped alongside it: Notify owners of AWS Health scheduled maintenance. Point your AWS Health notifications at the flow's address, and every maintenance email — instance retirements, scheduled reboots - becomes a Slack alert to the instance owner: an LLM node extracts the affected account, region, instances and the deadline for action, an EC2 DescribeTags call finds each instance's owner tag, and the message names who owns what and how long they have to act. It's on the Templates page in CloudFlow, and the tutorial walks through every node.

Email is the lowest common denominator of system integration. Sometimes that's exactly what you need. If a tool in your stack has been sitting outside your automation because it only speaks email, this is your way in — the docs have the details.