Bound email
Today, every inbound email lands in someone's inbox. AP gets vendor questions about invoice status. Logistics gets shipment update requests. Support gets order questions. An analyst opens each one, looks up the answer, types a reply, sends it back. Dozens of times a day for the same kinds of questions.
The bound email pattern attaches a mailbox to a specific App so the agent does that loop for you. Inbound mail creates a work item, the runbook does the lookup, the agent composes the reply from one of your email templates, and it goes out through the bound mailbox. It is the difference between "an agent that can read mail" and "an inbox that runs itself".
Audience: builders
What it enables
When a mailbox is bound to an App, the binding lights up three capabilities:
- Read. Mailbox sync, inherited from the workspace credential.
- Triggers. Inbound mail fires a work item.
- Reply. Reply via email template.
This applies regardless of which provider sits underneath. Gmail and Outlook Mail both surface the same shape once bound.
Why the binding matters
The workspace-level Gmail and Outlook Mail integrations are Read-only. The mailbox can be read, but events do not fire and the agent cannot reply on its own.
Binding the mailbox to a specific App is what turns Read into a complete loop: inbound mail becomes a work item, the Runbook decides what to do, and the agent composes a reply using one of the Project's email templates. The bound state is per App, so two different Apps can each own their own mailbox without interference.
Prerequisites
Three things have to be in place before you wire up bound email. The wiring below is fast; the prerequisites take longer the first time.
- A mailbox credential. A Gmail or Outlook Mail credential exists at the workspace level. See Gmail or Outlook Mail for setup. The credential can be IT-provisioned or builder-self-served depending on your org's stage 1 setup.
- An App with a Runbook. The App exists. Its Runbook knows what to do when a new email arrives. See Author the Runbook.
- One or more email templates. Templates are authored in the Project context. See Email templates.
The wiring
Bind the mailbox credential to the Project
In the Project context, pick the Gmail or Outlook Mail credential from the binding picker. This makes the mailbox available to the Project. See Integrations.
Configure the email trigger on the App
In the App's Triggers tab, choose "inbound email" and pick the bound mailbox. Optional filters (sender domain, subject prefix, label) narrow which messages create work items. See Triggers.
Author one or more templates the Runbook will use
In the Project context, author at least one email template named clearly enough that the Runbook can call it by name. Templates are markdown with placeholders for the values the Runbook fills in at reply time. See Email templates.
How the Runbook sees inbound mail
When inbound mail fires, the App creates a work item with the email as structured input: subject, sender, recipient, body, attachments, threading metadata. The Runbook acts on that work item the same way it acts on any other input. Output slots can include the reply itself, the template name to use, and any classification or routing decisions the Runbook made.
How replies work
The Runbook chooses a template by name and provides the placeholder values. The platform renders the template, sends the reply from the bound mailbox, and threads the reply into the original conversation. The full inbound and outbound trail shows up in the audit ledger and in the analyst's review surface.
What this article will cover
- Binding a mailbox credential to a Project
- Configuring the email trigger and its filters
- Reading the inbound work item shape
- Choosing a template at reply time
- Threading behavior and from-address handling
- Common patterns: AP help desk, vendor inquiries, remittance handling
- Troubleshooting: why a message did not create a work item, why a reply did not send