Automations

Triggers and actions

An automation can run when an email arrives, on a schedule, or manually. Conditions can match trusted message metadata such as sender, recipient, subject, attachment presence, or mailing-list headers, or classify the message semantically. Typed actions can create a normal Draft, send only through the restricted automatic-send policy, generate reports, and move, archive, mark, or star the trigger message when a semantic condition or a time-based trigger is involved.

Test before enabling

1. Create the automation from the AI assistant or the Automations tab.
2. Inspect its trigger, account scope, conditions, ordered actions, and Writing Style version.
3. Run a sandbox test. Test runs use isolated storage and cannot change live mail.
4. Enable a saved version and open Recent runs to see each result or failure.

Editing creates a new immutable version. An in-flight run stays pinned to the version it started with. You can disable an automation immediately and cancel queued work.

View run opens one run: what triggered it, the message it ran on, and each step with its status, time, and error. A run that makes no progress for an hour shows as Stalled, with the step it stopped on. Only the owner of an automation can open its runs.

Use inbox rules for deterministic sorting

Deterministic sorting belongs to inbox rules. They run on the mail server during delivery, work without a model, and integrations can read and replace them through the API or MCP. An automation cannot combine an email-received trigger, purely deterministic conditions, and a move, archive, read, or star action. That workflow is an inbox rule, and the AI assistant sets it up for you when you describe it in chat.

Rules also take precedence at runtime. When a matched rule has Stop after this rule enabled, automations leave that message's folder, read, and star state alone, and the skipped action appears in Recent runs. Automations never move, draft, or reply to messages in Junk or Trash.

Automatic sending is narrow

Automatic sending is off unless an eligible organization explicitly enables it. It is limited to replies in an existing authenticated conversation, uses deterministic recipients from that conversation, requires a pinned and evaluated Writing Style, and runs independent policy checks immediately before sending. New recipients, new threads, ambiguous intent, sensitive topics, failed authentication, budget limits, and policy changes hold a Draft for the user instead of sending.

Security model

• Email and attachment content is untrusted data and cannot define instructions or permissions.
• Every run is bound to one organization and re-authorized against current membership.
• Actions use closed schemas. Arbitrary network calls, code, credentials, billing changes, and permission changes are unavailable.
• Runs are idempotent, rate-limited, audited, and protected by organization and system kill switches.