The send gate
Every message your employee sends to anyone outside your account passes through a server-side screen before it is delivered: live replies, tool sends, approval dispatches, retries, and scheduled messages alike. This page describes what the screen checks and what happens when it says no.
How it works
Section titled “How it works”Before any channel adapter delivers a message, the send gate checks the recipient’s authorization: whether they are you, a verified contact, or an unknown address, and, for contacts, exactly what kind of content your contact record grants them (verification status, permitted data types such as commercial details, allowed classifications, and so on).
Two guarantees shape everything else:
- Fail closed. Any error, ambiguity, or timeout during screening denies the send. A broken gate can never silently let something through.
- Messages to you are never screened. You are the authority that approvals route to; holding your own content from you would be pointless.
What is checked
Section titled “What is checked”Content addressed to anyone other than you is screened for four things:
- Owner-briefing leaks. Internal briefings meant for you are never deliverable to an external recipient, not even with your approval.
- Health information. Health data is never disclosed to external recipients, on any channel, with no override.
- Commercial and financial signals. Pricing, payments, invoices, bank and tax terms, and similar content may only go to recipients your contact record explicitly grants that data type to.
- Third-party contact mentions. Naming someone from your contacts who the recipient is not authorized to hear about is denied.
Inbound, the same conservatism applies: if the gate cannot safely produce a substantive reply, the sender receives only a fixed, neutral acknowledgement (“Thanks, I’ve noted your message.”), never your internal context. If that acknowledgement carries attachments, it is screened like any other send.
What happens on a denial
Section titled “What happens on a denial”Denials are logged and you get exactly one notification per blocked send, showing the channel, the recipient, and why it was held. What happens next depends on the channel and the reason:
| Channel | Denial that can queue an approval for you | Hard deny (never deliverable) |
|---|---|---|
| Commercial/financial, third-party mention, and unknown recipients with no contact record at all | Owner-briefing, health | |
| Slack (member-mode DMs) | Commercial/financial, third-party mention, and unknown correspondents (e.g. a peer bot) | Owner-briefing, health |
| Slack (bot mode) | Commercial/financial and third-party mention for resolved contacts | Unknown recipients, owner-briefing, health |
| Commercial/financial and third-party mention for a resolved contact | Senders with no contact record (WhatsApp is an allowlist channel), owner-briefing, health |
Email is the most permissive here because correspondents come and go and cannot all be pre-registered: an unknown address routes to you instead of being blocked. WhatsApp is the strictest because the channel itself works from an explicit allowlist.
The owner-approval flow
Section titled “The owner-approval flow”When a denial is approval-grantable, the exact message (recipients, subject, and body) is queued as an approval in your dashboard. Nothing is paraphrased: what you approve is what gets sent.
- Your approval is the grant. Approving authorizes disclosure of that reviewed content to those recipients, and nothing else. It is bound to the exact payload and recipient set with a per-approval credential, so an approval for one message cannot authorize a different one.
- Approved dispatches skip the screen on the way out, because your approval already replaced it. This is the only intentional skip in the system.
- Scheduled emails work the same way: the employee drafts a future-dated message, you approve the exact content, and the backend sends it at the requested time.
Owner-briefing and health denials never appear in this flow. They cannot be approved, on any channel.
Last verified: 2026-10-24 against the shipped codebase.