Automatic sending and service triggers

New automations review before sending. A board manager may choose Send automatically for one destination attachment, column step, board hook, webhook rule or schedule on one board. A managed automation can then send through the customer's own connected account without a person approving each message. Existing review workflows and Gmail or Outlook draft destinations keep their review and draft behavior.

Turn on one automation

1. In the web app, open the board's Automate panel and choose the automation's Sending settings. Only a signed-in person with board manage permission can enable it. MCP and API tokens can read the setting but cannot turn it on, allow AI-written text, raise a cap, clear suppression or clear the board stop switch.
2. Check the named sending account and pinned target, recipient source and preview, exact saved template or the separate Let the AI write the message choice, and the limits. The default first-send review count is 0; you may set a positive count. Confirm the screen and select Turn on automatic sending. If the account, target, source, template, AI text choice or higher limit changes, the old consent is stale and a manager must confirm the new revision in the web app.
3. Find the current mode and remaining cap beside the automation. Stop this automation takes effect before its next send. The board header's Stop all automatic sends stops every automation on that board before another send lane cycle. A manager can resume the board there after checking the settings.

The usual starting limits are one recipient per send, 100 sends from one automation per UTC day, 1,000 per calendar month, and three to one recipient in a rolling 30 days. The manager can choose lower limits. A daily cap pauses the automation and creates Needs you: Sending paused: daily limit reached. Nothing past a reached cap sends. These app limits do not replace the sending provider's mailbox limits.

Recipient and message rules

A recipient must come from the source saved on that automation: a person's saved typed or imported list, a named field of a connected service read, a named card field, or a named field of a verified inbound event. The source and its revision are recorded with each send. Agent prose, a provider memo, a subject line, or an undeclared field cannot add a recipient. Workspace suppressions for opt-outs, bounces, complaints and manual blocks stop sends to that identity on every channel.

A saved template with named, checked fields is the default. AI-written free text requires the manager's separate choice and cannot send when customer or provider free text taints that run. Commercial email needs a customer-owned Gmail, Outlook or Resend sending account, sender identity, physical address and unsubscribe. An imported list is permitted through the customer's own account; the sender remains responsible for lawful basis, list quality and provider rules. A Gmail draft grant creates drafts only: it does not enable automatic Gmail sends. Gmail send needs a separate gmail.send grant after consent; Outlook send needs delegated Mail.Send.

Every send checks current consent revision, account, target, grant, suppression, limits, board stop switch and loop guard before provider egress. A send-origin event cannot start another send on the same board in the same causal chain within an hour unless a person intervenes. If the provider times out after the send may have started, the state is Unknown. BakedBrie does not retry that send automatically. Check the provider's records before a person chooses any new action.

Receipts and stops

The board's View receipts shows the exact rendered message, recipient, named source, sending account, automation, consent version, time and outcome. Accepted by provider means the provider accepted a request; it is not proof of delivery. A bounce adds an outcome and suppresses the recipient. Receipts are visible only to authorized board viewers and never include credentials. An unknown outcome is read-only until reconciled; there is no blind retry button.

When a service changes

In the board's Automate panel, choose When a service changes. Pick either Service sends an event or Check the service every interval, name the connected account, set a daily event cap and choose Make a card, Start a step, or Start a sending automation. The last choice lists only automations already consented for sending. A provider event must pass its signature or channel check and replay and tenant checks before it can start work. An unverified event starts nothing.

For any API with a declared read operation, Check the service every interval can use a stable item key, selected fields and a stored change cursor. It uses the connection's call limit and displays estimated monthly reads. It is scheduled polling, so changes are not instant. It can catch changes after downtime when the service has a readable history; it cannot promise lossless recovery from a source that does not.

HubSpot: its CRM webhook subscription belongs to the customer's app. A person may need to register BakedBrie's callback in HubSpot and choose object events there. The source stays paused until BakedBrie verifies signed events. The app's subscription limits still apply. Do not paste a HubSpot app secret into a board or chat.

Notion: a person creates the webhook subscription in Notion and completes Notion's verification-token handshake. BakedBrie stores the token as a secret and later verifies signed events. Until verification succeeds the source stays paused and starts no work. The Notion event may require a follow-up read for the current page or data source.

Google Drive and Calendar watches and Microsoft Graph subscriptions expire and need renewal. Their notification usually starts a follow-up read. Gmail history polling is used for reply detection; Google Forms and Sheets can use the change detector. A missed or expired subscription appears in Needs you; the source cannot claim verified push delivery while it is down. Use a change detector or provider delta read for catch-up where available.

See automatic sending recipes for complete paths and the setup each needs.

Outlook lead follow-ups use a best-effort scan of the current mailbox before each later send. Microsoft Graph may delay or omit a deleted reply; a follow-up can therefore send after someone replied. An unavailable, incomplete or ambiguous read pauses instead of sending. See the lead follow-up recipe.

To have Claude Code or Codex guide you through connection, provider registration and consent, paste the request in Ask an agent to connect a service. MCP can read list_send_modes, list_send_receipts, list_trigger_sources and get_trigger_source; the manager completes consent and trigger setup in the web app.