# Automatic sending recipes Each recipe begins with a connected **customer-owned** account, a saved automation on one board and a board manager's [automatic sending consent](/docs/send-mode). New automations stay in review until that manager turns on sending in the web app. These are setup paths, not claims that a service is already connected or its webhook already verified. Provider-side work may be required. ## Lead follow-up that stops on a reply 1. Connect the sending Gmail or Outlook account with its separate send grant. Connect a named Gmail history or Microsoft Graph mail read that can find inbound replies. A draft-only grant does not send and a send receipt does not prove no one replied. 2. Connect the form source. Use a verified webhook event if the form provider offers one; otherwise use the change detector over a declared read. Name the exact form email field as the recipient source. The trigger may start an already-consented send automation directly, without making a card. 3. Save fixed templates for day 0, day 3 and day 10. In the web app consent to the account, source, templates, limits and optional first-send review count. Before days 3 and 10, the journey reads Gmail history or scans the current Outlook mailbox for a matching reply. A visible reply, unsubscribe, hard bounce or complaint stops the remaining messages. If the read is unavailable, revoked, ambiguous, incomplete or over budget, the follow-up pauses. **Outlook reply limit:** Microsoft Graph may delay a reply or omit one already deleted. A complete scan without a visible reply permits the follow-up, so Outlook may send after someone replied. The same check runs again immediately before provider egress. If that risk is unacceptable, keep these follow-ups in review. The same event cannot produce duplicate journey sends, and a send-originated event cannot loop into another same-board send within an hour without a person intervening. ## Weekly report to a saved list Save a schedule and a typed or imported recipient list. Declare the reads and fields that fill the report template, then have the board manager consent to each sending account, source and cap. BakedBrie renders and sends **separately to each address**, checking suppression and the rolling per-recipient limit before each send. A schedule needs no provider webhook setup. The customer is responsible for list quality and applicable email law; marketing mail needs sender identity, postal address and unsubscribe. ## Invoice reminder instead of a draft Connect QuickBooks or Xero for an invoice and customer read. Use the verified customer email field, not an invoice memo or agent text, as the saved recipient source. A schedule or signed accounting event can start the check. In review mode, the existing Gmail or Outlook destination still creates an approved draft. For sending, connect a separate Gmail, Outlook or Resend sending account, choose the reminder template and limits, and have a board manager turn on automatic sending. If the invoice is paid or the recipient is suppressed, do not send. The QuickBooks or Xero webhook needs provider-side registration and signature verification; a schedule can use an accounting read instead. ## Slack or Teams post Choose the connected Slack or Teams account and one pinned channel as the target. Save the template and the board hook or column step; the manager consents to the target and caps. A post then uses that account and channel and records the exact text in its receipt. Incoming Slack events need the installed app and verified event connection. Existing review posts remain in review until their own automation is enabled. ## Social schedule Connect the existing WoopSocial destination and choose the pinned social accounts. Save a schedule and the final caption and media policy. A manager turns on sending for that schedule, with optional first-send reviews. A successful adapter receipt names the exact caption, media, target accounts and provider outcome. A review-mode social schedule still waits for its approval. This recipe needs the customer's own social destination setup; it does not create a provider subscription for a schedule. ## Calendar invitation Choose the customer's connected Google or Microsoft calendar sending account, a pinned calendar destination, a saved event template and a named attendee source. A manager confirms that scope and limits before automatic invitation. A generic calendar write is not an invitation and cannot bypass this consent. The receipt shows the exact invite and attendee. Calendar change watches, if used to start later work, need a verified and renewed provider subscription. ## Any API as a change trigger Connect a service with a declared read operation and attach it to the board. Under **When a service changes**, choose **Check the service every interval**, the read operation, stable key for each item, selected fields, poll interval and daily event cap. Choose whether new or changed items make a card, start a step, or start an already-consented sending automation. The setup estimates reads per month, and every poll counts against the connection's call limit. This works without a webhook, but only at the selected interval. It can recover missed changes only while the service's read or delta history still contains them. For HubSpot, a person may have to set the app-level CRM webhook callback in HubSpot; for Notion, a person creates the subscription in Notion and completes its verification token handshake. Until verification, the source is paused and cannot start a card, step or send. Google and Microsoft subscriptions also need renewal; inspect the source's last verified event, last check and next renewal in the board before treating it as live.