# Inbox

Inbox is an email-triage workspace that connects your mailbox, labels incoming mail the way your rules say, and drafts replies in your writing style — plus rules that can react to a CRM event. Nothing leaves your mailbox until you approve it, unless you author an auto-send rule yourself.

---

## What Is Inbox?

Inbox is a built-in Insulin app pinned to the desktop Dock. Once you connect a mailbox, Insulin watches for incoming email, checks each message against your rules, and — when one matches — produces something for you: a drafted reply, a Slack notification, or a CRM action. Drafted replies and CRM actions wait in the **Approvals ▸ Pending** queue where you read, edit, and confirm them. A Slack notification is only a heads-up sent straight to you, and an auto-send rule you write yourself sends its reply without stopping in the queue unless its pre-send check holds it back.

Prefer video? Watch a quick overview:

<iframe width="100%" height="480" src="https://www.youtube.com/embed/E_o9oD63F0I" title="Fours Insulin — Inbox App overview" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>

The whole feature is built around one safety promise:

:::warning
**Insulin never sends email on its own.** Every AI-generated reply waits in the **Approvals ▸ Pending** queue until you review it, and pressing **Send** requires a separate confirmation step because sending cannot be undone. The only exception is an **auto-send rule** — a rule you explicitly author that authorizes sending without review, within [strict limits](#when-an-auto-send-rule-may-send). Nothing sends automatically unless you have created such a rule yourself.
:::

:::info
Inbox supports **Gmail** and **Outlook**. Only **one** of them can be the Inbox mailbox at a time — see [Switching between Gmail and Outlook](#switching-between-gmail-and-outlook).
:::

![The Inbox app — the sidebar with Approvals expanded to Pending (with its count badge) and History, Mails expanded to its views, and Settings below, beside the mail list and reading pane](images/21-inbox-mails.png)

## Opening the Inbox App

Open Inbox from the **Inbox** tile pinned to the desktop Dock, or from the **Search apps…** launcher in the System Bar. Like other workspace apps it opens as a resizable window.

A left sidebar navigates the app:

| Entry | What it holds |
|-------|---------------|
| **Approvals** | A group with two entries. **Pending** is everything waiting on you — the tab Inbox opens on, carrying a live count badge of the items in the queue. **History** is the record of everything Inbox has executed: every sent email and every CRM action, with who authorized it, when, and the recorded outcome. |
| **Mails** | Your mailbox, mirrored. Expands to the views **Inbox**, **Starred**, **Sent**, and **Drafts**. |
| **Settings** | A collapsible group with **Account** and **Rules**. |

**Mails** opens on **Inbox**. Labels are declared on rules (see [Labels](#labels)) and appear as chips on the mails carrying them, like Gmail's — they are not a navigation level. **Drafts** lists your provider's drafts live, and archiving mail in your mail client simply removes it from **Inbox** here — nothing is deleted.

## How an Email Becomes an Action

```d2
direction: down
mail: "Incoming email\nGmail or Outlook"
crm: "CRM event\nSalesforce · HubSpot · Dynamics 365"
match: "Rule match\neach rule's filter, then context from the\nintegrations you connected"
draft: "Email draft"
crmaction: "CRM action"
slack: "Slack DM to you" { shape: rectangle; style.stroke-dash: 3 }
auto: "Auto-send\nonly from a rule you wrote, on one exact filter,\nwith no customer, knowledge-base or integration data" { shape: rectangle; style.stroke-dash: 3 }
check: "Pre-send check" { shape: diamond }
gate: "APPROVALS ▸ PENDING\nyou read it, edit it, confirm it"
sent: "Sent from your mailbox"
ran: "Agent runs it live in the chat rail\nlimited to that one CRM"
mail -> match
crm -> match
match -> draft
match -> crmaction
match -> slack: "notification only" { style.stroke-dash: 4 }
match -> auto: "bypasses the gate" { style.stroke-dash: 4 }
draft -> gate
crmaction -> gate
auto -> check
check -> sent: "passes"
check -> gate: "held for review" { style.stroke-dash: 4 }
gate -> sent: "Send, then confirm"
gate -> ran: "Run in chat"
```

Everything on the solid path stops at **Approvals ▸ Pending**. The two dashed outputs are the exceptions: a Slack notification only tells you something happened, and auto-send exists only if you wrote a rule that asks for it — and even then a pre-send check can hand the reply back to the queue.

### When an auto-send rule may send

An auto-send rule is the one path where Insulin sends mail without you, so it is held to a stricter standard than a rule that drafts for review:

- **One exact filter decides whether it fires.** The rule has to compile to a single condition on the sender's address, the sender's name, the subject, or the body — *contains*, *starts with*, *ends with*, *equals*, or a regular expression — and that condition alone decides. The AI never judges whether an auto-send rule applies to an email. Anything that could match every email is refused, including a pattern that would match an empty field.
- **No outside context goes into the reply.** A generated reply is written in your writing style from the incoming message and the rule's own instructions — with no customer or billing data from Fours, no knowledge-base passages, and no lookups in your connected integrations. A rule with pinned canned text sends your saved words instead. If you ask an auto-send rule to look something up (its **Context sources**), it never sends: every reply it produces waits in **Approvals ▸ Pending** instead.
- **A last check runs before anything leaves.** A generated reply is held for review when the AI that wrote it flags it as needing a human, or when a fixed check on its subject and body finds an empty message; something that looks like a card number, a US Social Security number, or a private key; or a link or email address that is not the sender's own address or at the sender's domain. A canned reply's body is your own text, but the subject it repeats from the incoming email gets the same check.

A held reply lands in **Approvals ▸ Pending** like a draft from any other rule. When it was held for its context sources or by the fixed check, it carries a note saying so — see [Before you press Send](#before-you-press-send). Nothing is lost; the send simply waits for you.

Auto-send rules can only be written on the **Rules** page: the [Inbox chat rail](#the-inbox-chat-rail) refuses to create one.

## Connecting a Mailbox

Open **Settings → Account** and find the **Email source** section. Inbox does not run its own OAuth flow — it reuses the connection you set up under Integrations.

Each provider has its own card, and there are two paths to enabling it:

1. **Already connected** — If you have already connected [Gmail](/integrations/google-mail/) or [Outlook](/integrations/microsoft-outlook/) through Integrations, the card shows an **Enable Inbox for Gmail** / **Enable Inbox for Outlook** button. Clicking it health-checks your access, registers the mailbox webhook, and starts building your [writing style](#writing-style).
2. **Not connected yet** — The card shows a **Connect Gmail** / **Connect Outlook** link that takes you to **Settings → Integrations**, where the standard connection lives. Once connected, return to this page and click **Enable Inbox for …**.

A connected card shows **Connected as** your mailbox address, plus an **Inbox enabled** badge once Inbox is running.

:::info
Only **one** email provider can be the Inbox mailbox at a time. While one holds the slot, the other card shows either a **Switch to …** action (if that provider is already connected under Integrations) or the note *"Only one email provider can be connected at a time."*
:::

### Account Lifecycle

The active provider's card exposes two lifecycle controls with very different effects on your data:

| Action | What it does | Effect on your data |
|--------|--------------|---------------------|
| **Disable** | Pauses Inbox — it stops receiving and processing any new email. | Mail Inbox has already processed is **kept**. Re-enable anytime with **Enable**. |
| **Disconnect…** | Immediately deletes the email Insulin has stored and resets Inbox to a never-connected state. | Some things are deleted, some are kept — see [What Disconnect does to each thing](#what-disconnect-does-to-each-thing). Your **actual mailbox is not touched**. This **cannot be undone**. |

:::warning
**Disconnect is destructive, and it is not a full erasure.** It permanently removes Insulin's copies of your triaged email, and it clears your writing style. Disconnect does not delete or modify any message in your real Gmail or Outlook mailbox — the only things Insulin ever writes there are its own drafts, described under [Drafts in your Gmail Drafts folder](#drafts-in-your-gmail-drafts-folder) — and it does not remove the rules you defined — those survive and apply again if you reconnect. A minimal, content-free record of each processed message is also kept for de-duplication and audit.
:::

#### What Disconnect does to each thing

| What | Disconnect | Notes |
|------|------------|-------|
| Stored email records, their AI drafts, and the labels Inbox applied to them | **Deleted** | Hard-deleted. This is the bulk of what Insulin holds about your mail. |
| Your writing style | **Cleared** | Reset to empty. Reconnecting rebuilds it from the mailbox you reconnect. |
| Processing history (execution records) | **Redacted but retained** | The message content, subject, classification and your mailbox address are stripped. A minimal record with no message content is kept for de-duplication and audit. |
| Your rules, including the labels they declare | **Untouched** | Every rule you wrote survives and runs again if you reconnect — only the labels *applied to deleted messages* go away with those messages. |
| Your knowledge-base selection | **Untouched** | |
| Your real Gmail or Outlook mailbox | **Untouched** | Disconnect does not delete or modify any message in the mailbox itself. The only messages Insulin creates are its own mirrored drafts — see [Drafts in your Gmail Drafts folder](#drafts-in-your-gmail-drafts-folder). On mail you received it only ever changed labels and read state. |

### Switching between Gmail and Outlook

When one provider is active and the other is already connected under Integrations, the inactive card offers **Switch to Gmail…** / **Switch to Outlook…**.

:::warning
**Switching permanently deletes the old provider's mail.** The dialog spells this out: your current provider's emails — including AI-applied categories, drafts, and classification history — are permanently deleted, and this cannot be undone. Your writing style is rebuilt from the new mailbox. To confirm, you must type the literal word `SWITCH` into the confirmation box; the **Switch** button stays disabled until it matches exactly.
:::

### If you disconnect the integration itself

Disconnecting the underlying Gmail or Outlook integration (under **Settings → Integrations**, outside Inbox) does not purge your Inbox data immediately. Insulin starts a **7-day grace period**: reconnect the integration inside that window and nothing is lost. If the integration is still missing after seven days, the purge above runs — the stored email records are hard-deleted and Inbox resets to a never-connected state.

The seven days start only once Insulin has confirmed the integration really is gone. If that check cannot run — during a provider outage, for example — the countdown does not begin. Once it has begun it runs on the calendar, but nothing is deleted until a check confirms the integration is still missing, so an outage can only delay the purge, never bring it forward.

![Inbox Settings → Account — the Email source section with Gmail enabled beside the Outlook card and its Switch to Outlook action, the AI model list, the Salesforce, HubSpot and Dynamics 365 triggers, and the Writing style card](images/22-inbox-settings-account.png)

## Approvals ▸ Pending

**Pending**, under **Approvals**, is the queue of everything Inbox has produced for you and is holding until you act. It is the tab Inbox opens on, and its sidebar badge counts what is waiting. Once you act, the item leaves Pending: sending or running it moves its record to [**History**](#approvals--history); archiving it discards the item without adding a History row.

Use the search box to fuzzy-search the queue, and the rule filter beneath it to narrow to one rule's output.

### Reviewing a drafted reply

Selecting a reply draft opens a compose pane on the original thread:

- **To** is editable, and a chevron next to it reveals a **Cc** field so you can copy other people on the reply. **More ▸ Reply all** pre-fills Cc with the thread's wider audience (minus yourself).
- The thread history sits above the editor so you can read what you are replying to.
- The reply body is inline-editable and saves when you click away from the field.
- **Attach** stages files onto the reply (Gmail only — see [Attachments](#attachments)).

#### Drafts in your Gmail Drafts folder

On a Gmail mailbox, Insulin mirrors each AI draft into your Gmail **Drafts** folder so it appears where you already work. It **creates** the Gmail draft when the reply is generated, **updates** it when you edit the draft in Inbox, and **deletes** it when you send or archive the draft from Inbox. Those drafts are the only messages Insulin creates in your mailbox. On mail you received it changes only labels and read state — never the message content, and it never deletes one. Outlook drafts are not mirrored.

| Action | What it does |
|--------|--------------|
| **Save** | Persists your edits to the draft without sending. |
| **Send** | Sends the reply (see the confirmation step below). |
| **Archive** | Drops the draft out of the queue; the mail itself stays in your mailbox and under **Mails**. |
| **More** | Reply all. |

**Sending is a two-step gesture.** Clicking **Send** opens a **"Send this reply?"** confirmation dialog, and you must confirm there before the reply actually goes out. This second step exists because sending is irreversible — there is no unsend or recall.

#### Before you press Send

The reply pane shows what the draft was written from, so you can check it before it goes out:

- **Why it is here.** A reply that an auto-send rule held back says so beneath the draft — *"This rule asks to send automatically, but it also reads customer context — so the draft comes here for review instead of being sent."* when the rule names context sources, or *"The pre-send check flagged this reply, so it was queued for review instead of being sent."* when the fixed check tripped.
- **Customer** — when the draft was written with a customer lookup, who Inbox matched the sender to and what it knew about them. See [The Customer block](#the-customer-block).
- **Text the AI read** — the exact text the AI was given, inside the thread history. See [Checking what the AI read](#checking-what-the-ai-read).
- **Send waits for the email.** **Send** stays disabled until the email you are replying to has loaded. If your mail provider won't return it, the footer reads *"This email can't be read from your mail provider, so there is no way to check what the AI replied to."* with a **Retry** button beside it.

### The Customer block

When your rules run on an email, Inbox tries to match its sender to one of your Fours customers — the sender's address to a contact, the contact to a customer — and a draft for review is written with what it found. The **Customer** block shows that match on the reply pane and in the **Mails** conversation view:

| What it shows | What it means |
|---|---|
| The customer's name, a badge for its cloud marketplace, and *via* the matched contact | Matched. Below it: how many of the customer's entitlements are active (with a few of their names), and — when there are any — its open offers with the next expiry and its unpaid invoices with the amount due per currency and the oldest due date. |
| *"3 customers share this contact — no single customer was matched."* (with the actual count) | Ambiguous. More than one customer claims this contact, so no customer's data was used. |
| *"This sender is not a known contact in your organization."*, *"This contact is not linked to a customer."*, *"The email carried no sender address to match."*, or *"The customer lookup failed — nothing was matched for this sender."* | Not matched, with the reason. The draft was written without customer data. |

The block is a **snapshot** taken when the rules ran — what the AI knew when it wrote the draft, not today's figures — and it is read-only. Replies an auto-send rule writes use no customer data, so they carry no Customer block. The exception is a rule held back for its context sources: its generated draft is written like any other draft for review, customer lookup included.

### Checking what the AI read

A formatted email usually carries two versions of its body, written separately by the sender: a plain-text version and an HTML one. Your mail client shows you the HTML version; the AI reads the plain one. They normally say the same thing — but a sender can hide text in the version you don't see.

So every HTML message in the thread history carries a collapsed **Text the AI read** line: open it to see exactly the text the AI was given. When the plain text contains a passage of about twenty words or more that the visible email doesn't show — text hidden from view counts as not shown — that message shows a warning in place of the line, *"⚠ Possibly malicious email — hidden text differs from what you see. Check what the AI read:"*, followed by the text. If it is the message you're replying to, it is opened for you even when a newer message sits above it. Read that text before you approve a reply. The check only decides how prominently the text is shown; it never blocks anything.

It appears wherever the thread history does: on the reply pane, in the **Mails** conversation view, and in the reply composer.

### Reviewing a new outbound draft

A rule fired by a CRM event — or a draft the AI chat rail created for you — produces a brand-new email rather than a reply. That one opens as a compose pane with an editable **To**, **Subject**, and **Draft** body, and the same **Save** / **Send** / **Archive** actions. The confirmation dialog reads **"Send this email?"**.

### Running a CRM action

A rule can also produce a **CRM action** — a written instruction such as *"update the CRM with a short summary of the latest email thread."* It appears in the queue as its own block showing the instruction and a **Run in chat** button.

:::info
**A CRM action is never executed silently.** Nothing happens until you click **Run in chat**, which hands the instruction to the agent in the [Inbox chat rail](#the-inbox-chat-rail) and lets you watch it run. Once run, the item leaves the queue and the button is replaced by *"Sent to chat"*.

Because the item leaves the queue, its record moves to **Approvals ▸ History** (and to the email itself, whose **CRM action** section shows the same block). The record has two parts. The **receipt** is written the moment you click: the instruction, **Authorized by** *you*, and when. The **outcome** is written when the agent finishes: whether the CRM write **succeeded or failed**, a short summary of what it did, and the records it created or updated. If the agent never gets to record an outcome — a tool failure, a denied action, a closed tab — History shows *outcome not recorded* rather than a fabricated success, so the authorization and the result are always told apart.
:::

**A Run is limited to the CRM the action came from.** When you click **Run in chat**, Insulin works out what the run may touch from the stored action, not from your browser. The agent can use only the connection the action was raised against — the Salesforce, HubSpot or Dynamics 365 connection whose event fired the rule — plus the step that records the outcome. Your other integrations, the Inbox mail tools, rule creation, jobs, the browser, the file sandbox, memory and goals are out of reach, and the agent can't stop to ask you a question. The limit covers that one run: a message you type in the rail afterwards is an ordinary rail conversation again.

```d2
direction: down
card: "CRM action card\nApprovals ▸ Pending"
scope: "Insulin sets the run's reach\nfrom the stored action"
agent: "Agent in the Inbox chat rail"
crm: "The one CRM connection\nthe action came from"
rec: "Outcome recorder"
hist: "Approvals ▸ History\nreceipt + outcome"
other: "Out of reach for this run\nother integrations · mail tools · rules\njobs · browser · sandbox · memory · goals" { style.stroke-dash: 3 }
card -> scope: "Run in chat"
scope -> agent: "one scoped run"
agent -> crm: "reads and writes"
agent -> rec: "when it finishes"
rec -> hist
scope -> other: "withheld" { style.stroke-dash: 4 }
```

- **An action queued before Insulin recorded its CRM connection can't be run.** Instead of **Run in chat**, its card reads *"Queued before this action recorded its CRM connection, so it can't be run — trigger the rule again to raise it."*
- **Several Runs go one at a time.** Click **Run in chat** on more than one action and the rail runs them in order, each waiting for the previous one to finish.
- **A failed Run offers no Retry.** The CRM write may already have happened before the reply stopped, so instead of **Retry** the error card says *"This CRM action may already have run — check the record in your CRM, or the action's outcome in Approvals, before running it again."*
- **Only that Run records the outcome.** An action's outcome in **Approvals ▸ History** can be written only by the run launched from that action's own card, and it always lands on that action.

### Approvals ▸ History

**History**, the second entry under **Approvals**, is the durable record of everything Inbox has executed — it is not the chat transcript, and it outlives it. It lists, newest first:

| Entry | What it shows |
|-------|---------------|
| **CRM action** | The deal it belongs to, the instruction, its status, the receipt (**Authorized by**, when), a link to the chat-rail conversation it ran in while that conversation exists, and the recorded **outcome** — succeeded or failed, the agent's summary, and the CRM records written. |
| **Sent email** | The subject, the recipients, and who pressed **Send** and when. |

For a CRM action the recorded outcome lists each record the agent wrote and, where the agent was able to read that record, its field values **before and after** the write — so you can see what changed, not only that something did. A record whose prior values could not be read is shown as **not captured** rather than as an empty change.

Use the search box to narrow the list by deal name, instruction, or outcome summary. **Export** downloads the ledger for a date range as a CSV — each row with its receipt, outcome, and any captured before/after diff — so a reviewer can pull the record without asking engineering. A very large range is capped: the file then ends with a truncation marker, so narrow the dates and export again. CRM-action records are kept for **two years** from the moment they were authorized and then removed; sent-email records follow the mailbox's own retention.

### Attachments

| Limit | Value |
|-------|-------|
| Files per message | Up to **3** |
| Size per file | Up to **5 MB** |

:::warning
**Attachments are not supported on Outlook, in either direction.** Incoming Outlook messages show no attachment list in Inbox and their files cannot be downloaded from it, and an Outlook send that carries attachments is refused with an error rather than silently going out without them. On an Outlook mailbox the **Attach** control is therefore not shown. Gmail handles attachments normally in both directions, including files forwarded from the original message.
:::

![The Inbox on Approvals ▸ Pending — the queue with its search box and rule filter, the selected AI draft with its editable To and its subject, the draft body and its evidence, the Save / Send / Archive actions, and the chat rail on the right](images/20-inbox-approvals.png)

## Mails

**Mails** mirrors your mailbox. Pick one view at a time from the sidebar:

| View | Shows |
|------|-------|
| **Inbox** | Mail in your provider's inbox. |
| **Starred** | Mail you starred — in your mail client or here. |
| **Sent** | Mail you sent. |
| **Drafts** | Your provider's drafts, listed live. |
| *a label* | Every mail carrying that label, across the views above. One entry per label your rules declare. |

The page has three panes: a searchable mail list, a conversation view, and the [AI chat rail](#the-inbox-chat-rail).

The **conversation view** shows the subject once, the number of messages, the labels applied to it, and a status badge. Older messages in the thread are collapsed and load when you click them.

- **Archive** / **Unarchive** sit in the conversation header, because they act on the whole conversation.
- **Reply**, **Reply all**, and **Forward** sit under the newest message. If Inbox has already drafted a reply for that mail, **Reply** takes you straight to that draft in **Approvals ▸ Pending** instead of opening a blank composer.
- In the reply composer, **AI generate** writes a draft in your learned writing style, which you can then edit before sending.

The conversation view also carries the [Customer block](#the-customer-block) for mail your rules processed and, on HTML mail, the [Text the AI read](#checking-what-the-ai-read) line in each message.

If Gmail is briefly unavailable or rate-limits Insulin while a message is being processed, Inbox tries that message again on later deliveries — three attempts in all — before giving up on it. A message it gave up on shows a **Failed** badge in the conversation view and has no draft; you can still reply to it yourself. A permanent error, such as a revoked connection or a deleted message, is not retried.

:::info
Email bodies are fetched live from your provider each time you open a message, and the **full body is never stored** by Insulin. What Insulin does retain per message: the subject, sender, recipients and timestamps; the short preview line your provider returns with the message (Gmail's snippet, Outlook's body preview), which is what the mail list shows; the labels applied; any structured **extraction** (for example a drafted reply's subject and body); the AI drafts themselves and their edit history; the **Customer** snapshot — which customer the sender was matched to, and that customer's entitlement, offer and invoice summary at the time; a **thread summary** when you request one; and the rule-trace records that explain which rules ran.
:::

### Filtering by email domain

**Mails** and **Approvals** both carry a domain filter — *Filter by domain, e.g. acme.com*. It matches the **sender or any recipient or cc** at that domain **or a subdomain of it**.

The filter runs on the server, so it survives paging rather than filtering only the rows currently loaded, and it composes with the status, label and rule filters instead of replacing them. Input is normalised (`@Acme.com` becomes `acme.com`), and text that cannot be a domain gets a hint rather than silently returning nothing.

## The Inbox Chat Rail

Every Inbox page carries a chat rail down the right-hand side, headed **Chat with your inbox**. It is not the Chat app in a narrow window — it is a conversation about the mail you are looking at.

- **It is always there.** Every page — Pending, History, Mails, Rules, Account — mounts the same rail. Collapse it with the button in its header; a small reopen button then appears at the top-right of the page.
- **It resizes.** Drag the handle on its left edge. The rail can be anywhere between **15%** and **45%** of the window width; it starts at about 30%.
- **It has its own conversation.** The rail runs the built-in Insulin agent on a thread dedicated to Inbox, separate from the [Chat](/insulin/agents/#conversations) app — so your inbox conversation never mixes into your general chat history. Type `/clear` to start a fresh one.
- **It knows what you are looking at.** Every message you send carries the current page as context: which tab you are on, which label is selected, which mail is open, and the mails currently visible in the list. Ask *"what needs a reply here?"* and it answers about the screen in front of you, not about your mailbox in the abstract.
- **It can act.** Beyond reading, listing, searching, and counting your mail, the agent can **create an email draft** for you (it lands in **Approvals ▸ Pending** like any other draft) and **create a rule** from a plain-English description — any rule except one that sends automatically, which you can only write on the **Rules** page. It is also where a **Run in chat** CRM action executes, within the [limits of that run](#running-a-crm-action).

## Rules

Rules control what Inbox does for you — which messages get a drafted reply, which CRM events produce work, and what context the AI pulls in. Open **Settings → Rules**.

The left panel lists your rules, with a search box and a **New** button. Every row carries an enable switch and a delete button, so turning a rule off never requires opening it. Inbox ships no rules of its own — nothing is drafted until you create a rule that asks for it.

### Describing a rule

The rule editor is **natural-language first**. There are only two fields:

1. **Rule name** — optional. Leave it blank and Insulin generates one for you.
2. **Describe the rule in natural language** — a plain-English box where you say what should happen, for example *"When a new email arrives that needs a reply, draft a reply for me to review before it is sent."*

Then click **Save**. That single click both turns your description into a structured rule and saves it — there is no separate generate step. Saving runs an AI model and takes a few seconds; an inline notice asks you not to refresh while it works.

:::info
**Save fails and nothing is written when the rule is missing a prerequisite.** This is deliberate: saving anyway would have replaced the rule's filter with one that matches every email.

It is not only the AI model. Save checks everything the rule needs, and each missing piece appears as its own row with the reason and a link straight to the setting that fixes it:

| Check | Fails when |
| ----- | ---------- |
| **AI model** | No model is available to interpret the description. |
| **Mailbox** | No mailbox is connected, or one is connected but not enabled. |
| **CRM** | The rule uses a CRM, and it is not connected — or is connected with its trigger disabled. |
| **Slack** | The rule delivers to Slack, and Slack is not connected. |
| **Context sources** | A context source the rule names is missing or cannot be resolved. |

All of these are **user-level** integrations, so the fix links point at **Settings → Integrations → User Integrations** or your Account page — connecting one at the organization level does not satisfy them.
:::

Editing a rule works the same way — change the description and click **Save** again. Changing only the name just renames it; the rule's behavior is left alone.

### Preview: run the rule without sending anything

**Preview** sits between **Details** and **Save**, and is enabled exactly when **Save** is — it runs the rule *as you have just written it*, not the version last saved. It walks four steps, narrating each one with how long it took and what it produced:

| Step | What happens |
| ---- | ------------ |
| **Interpret** | Turns your description into a structured rule — the same call **Save** makes. |
| **Check** | Compares what the rule needs against what you have connected. A rule missing a piece stops here: it is not the rule you meant to test. |
| **Sample** | Produces one sample event to run against. |
| **Run** | Does the real matching and drafting, and shows the verdict plus each output, labelled with what a live event *would* have done. |

**Nothing leaves the building.** A preview writes no approval row, sends no email, posts no Slack message, takes no CRM action, and does not move the trigger's stage cursor. Every output card is badged `Preview only - not sent`.

The sample is read-only and says where it came from, so a generated example is never mistaken for a real record — a real record, a template, or written by AI.

Two behaviours worth knowing:

- **Hide only collapses the panel.** Re-showing it does not re-run; use **Run again** for that.
- **Editing the description dismisses the results**, because they belonged to the description they ran on.

### Starter hints on a new rule

A brand-new, still-empty rule shows a hint block under the buttons, which disappears as soon as you type anything.

The top strip spells out the shape of every rule — **Trigger → Integrations → Output**:

| Step | What it means |
|------|---------------|
| **Trigger** | What makes the rule fire — a new email (Gmail or Outlook), a CRM stage change (Salesforce, HubSpot, Microsoft Dynamics 365), or a Fours marketplace event (a co-sell referral, an entitlement, an offer, or a billing event). |
| **Integrations** | The AI can search all of your user-level integrations as context. |
| **Output** | What the rule produces — e.g. an email draft, a CRM update, a Slack DM. |

Below it, **Try an example** chips fill the description box with a ready-made prompt you can edit before saving:

- **Customer question → reply draft** — a full email rule: the filter, the context to gather (Gong calls, offers in Fours), and drafting guidance.
- **Marketplace mail → labels** — a label-only rule: two labels, no draft.
- **Salesforce stage → AWS referral**
- **Technical Validation → intro draft**
- **Stalled 30 days → bump or Slack**
- **Entitlement suspended → Slack**

### Details

**Details** opens a read-only view of the structured rule your description produced: the **Trigger**, the **Filter** (or, for a CRM rule, the stage / amount / owner it matches), the **Context sources** it may search, the **Generation** inclusions and exclusions, and the **Actions** it routes to. You can open the Trigger and Context-source pickers to browse what is supported, but nothing there is editable — to change a rule, change its description and save again.

**Details** is unavailable on a brand-new draft (nothing has been generated yet) and becomes available once the rule is saved.

### Actions

Every rule routes its outcome to one or more action cards:

| Action | What it does |
|--------|--------------|
| **Email reply** | Replies to the sender of the triggering email. Choose one of two modes: **Draft for review → Approvals queue** (the safe default) or **Send automatically**. |
| **Slack** | DMs *you* on Slack when the rule fires, with a link back to the queue. Requires your own [Slack](/integrations/slack/) connection — the card tells you which Slack user will be messaged. |
| **CRM action** | Only on a CRM-triggered rule — Salesforce, HubSpot and Dynamics 365 all support it. Carries a written instruction, which is required, and lands in **Approvals ▸ Pending** behind a **Run in chat** button. It combines freely with the other two. |

The two **Email reply** modes are mutually exclusive — a rule drafts for review or sends automatically, never both.

:::warning
**Send automatically sends without human review — within strict limits.** A rule in this mode sends replies straight to recipients, and the card marks it *no human review*. You can optionally tick **Always send the same text** and provide a fixed reply that is sent verbatim on every matching email; leave it unticked and the AI writes a fresh reply per email in your writing style. Either way the rule has to meet the bar in [When an auto-send rule may send](#when-an-auto-send-rule-may-send), and Inbox enforces it:

- **Save** refuses an auto-send rule whose description doesn't compile to one exact, narrowing condition: the editor says *Nothing was saved.* and gives the reason, and **Preview** stops with the same reason. Describe a specific sender, subject or body condition, or switch the rule to drafts.
- An existing auto-send rule that doesn't meet the bar can't be switched back on until you rewrite it. Switching any rule **off** always works.
- An older auto-send rule saved before this check never fires. Open a mail it should have answered and the **Rules (N of M fired)** list in the conversation view shows it as **Skipped**, with the reason.

Use this mode deliberately.
:::

![Inbox Settings → Rules with a new rule open — the rule list on the left with its enable switches, and on the right the rule name field, the "Describe the rule in natural language" box, the Discard / Details / Save row, and the starter-hint block showing the Trigger → Integrations → Output strip above six example chips](images/24-inbox-rules.png)

## Triggers: reacting to a CRM event

A rule does not have to start from an email. Under **Settings → Account → Triggers**, Inbox lists the CRM sources it can react to (marketplace events need no trigger row — see [Triggers: reacting to a marketplace event](#triggers-reacting-to-a-marketplace-event)):

| Trigger | Fires when |
|---------|------------|
| **Salesforce** | An opportunity moves to a stage you describe. |
| **HubSpot** | A deal moves to a stage you describe. |
| **Microsoft Dynamics 365** | An opportunity moves to a stage you describe. Drafts, Slack notifications and **CRM actions** all work as they do for the other two. A rule written around **won** or **lost** does behave differently here — see the note below. |

All three are live. Each row is driven by *your own* user-level connection to that CRM, so:

1. Connect the CRM first. A row you have not connected shows **Connect**, which takes you to **Settings → Integrations** — see [Salesforce](/integrations/salesforce/), [HubSpot](/integrations/hubspot/), or [Microsoft Dynamics 365](/integrations/microsoft-dynamics365/).
2. Click **Enable** on the row. The row then shows an **Enabled** badge.
3. Write a rule that describes the CRM event you care about, in **Settings → Rules**.

Turning a trigger off with **Disable** keeps your rules: they stay saved and go dormant until you enable the trigger again.

## Triggers: reacting to a marketplace event

Rules can also fire on events from your Fours marketplace data — the reason to run Inbox next to Fours rather than a generic AI email app. There is no row to enable under **Triggers**: describe the event in a rule and saving the rule subscribes to it.

| Family | Fires on |
|--------|----------|
| **Co-sell referral changed** | A referral is accepted, approved, rejected, updated, pending acceptance, received inbound, assigned a cloud-provider team member, or has gone quiet (**stalled**) for a number of days you choose. A referral rule can also name the partner-side sales stage it should react to (for example *Technical Validation*). |
| **Entitlement changed** | An entitlement is created, suspended, cancelled, reinstated, terminated, or ending soon. |
| **Offer changed** | An offer is created, sent for acceptance, accepted, signed, expired, expiring soon, or cancelled. |
| **Billing event** | An invoice is issued, a payment is charged, or a payment is refunded. |

Every family can be narrowed to one cloud partner (AWS, Azure, GCP) and, where it applies, to an entity status or a name. A marketplace rule produces the same outputs as any other: a drafted email in **Approvals ▸ Pending** — for a referral, addressed to the cloud provider's team on the deal when Fours knows them — and, or, a Slack notification. Three of the starter chips on a new rule are marketplace rules: **Technical Validation → intro draft**, **Entitlement suspended → Slack**, and **Stalled 30 days → bump or Slack**.

:::caution[Won and lost look the same on Dynamics 365]
Describe a rule around a deal being **won** or **lost** and it matches that outcome on every connected CRM — `Closed Won` / `Closed Lost` on Salesforce and HubSpot, and `Close` on Dynamics 365.

Dynamics 365 reports a single `Close` stage for both outcomes, and the stage-change event does not carry which one it was. So on Dynamics a **won** rule fires on every closed opportunity — including the ones that were lost — and a **lost** rule does the same. Salesforce and HubSpot distinguish the two correctly.

If that matters, scope the rule to Salesforce or HubSpot. There is no Dynamics-side workaround today — naming the `Close` stage directly does not help, because that is the one stage Dynamics reports for both outcomes.
:::

## Labels

Labels are declared on rules. Write what to label in the rule's description — *"When an email is about an AWS Marketplace private offer, label it with 'Cloud partners' and 'Co-sell'"* — and every mail that rule matches gets those labels. A rule can label only (no draft, no Slack), or label alongside its other outputs; labels are available on email rules only. A rule can declare at most five labels, each label is at most 40 characters, and names Gmail reserves for its own system labels are refused when you save.

On a Gmail mailbox, labels sync to your mailbox as real Gmail labels; they show as chips on each mail in Inbox rather than as a menu entry. Deleting or disabling the rule stops new mail from being labelled; mail already labelled keeps its label.

## AI Model

Inbox needs one working AI model to interpret your rules and draft replies. The **AI model** section of **Settings → Account** lists five model providers — Claude Code, Codex, Anthropic, OpenAI, and Gemini — and shows **Connected** or a **Connect** link for each. A credential whose sign-in has lapsed is treated as not connected and shows **Connect** too — re-authorizing and connecting for the first time are the same flow on the Integrations page. Inbox can also use other AI providers you have connected yourself — including the open-source aggregators, Cloudflare Workers AI, and DigitalOcean GradientAI — even though this section does not list them.

:::warning
With no provider of your own connected, Inbox runs on Fours' hosted models and the card says so; connect a provider below to use it instead. If no model is available at all — no provider and hosted models not allowed for your organization — rules can't be interpreted and no draft is produced; Inbox simply looks quiet. The rule editor's **Preview** names this as the first thing to fix.
:::

Connecting and disconnecting model credentials happens on the Integrations page; this card only reports the state and links you there.

**Inbox falls back to another model rather than failing.** The work Inbox does outside a chat — classification, tagging, drafting a reply or a CRM action, synthesizing a rule, summarizing a thread, building your writing-style profile — now walks the same chain of candidate models the chat agent uses. If your first provider is unavailable or has hit a usage limit, the next connected provider takes over, and Fours' hosted models are the last resort. A single provider running out of quota no longer silently stops every one of those jobs.

## Writing Style

Insulin learns your writing style from your recent sent mail so AI drafts sound like you. It is shown under **Settings → Account → Writing style**, is used **only** for draft generation, and never leaves your tenant.

The card reports one of four states:

| State | What it means |
|-------|---------------|
| **Built from N recent emails** | Ready. A summary below shows your greeting, sign-off, register, and common openers and closers. |
| **Building…** | A build is in progress. It can take a few minutes. |
| **Build failed** | The build failed, with the reason. |
| **No voice profile yet** | Nothing has been built. |

A build starts automatically when you enable Inbox, and **Re-generate** rebuilds it from your latest sent mail at any time — including out of a stuck or failed state.

**Your edits teach it, too.** When you send a reply the AI drafted, Insulin compares what it wrote with what you actually sent. An edit that changes the style — tone, length, a greeting or sign-off, phrasing — yields at most one writing preference; an edit that only corrects facts such as names, dates, amounts or links teaches nothing, and a reply you sent essentially as drafted reinforces the profile you already have. Once ten preferences have collected, they are folded into your writing style. Replies the AI didn't draft — pinned canned text, or mail you wrote from scratch — are not learned from. Learning runs on your own Insulin model, reads only your own mail, and never holds up or fails a send.

## Knowledge Bases

Attach knowledge bases to Inbox and it will consult them while drafting replies — useful for product documentation, canned answers, or a support playbook, so drafts draw on your actual material instead of improvising.

Open **Settings → Account** and find the **Knowledge bases** section. Tick a knowledge base to use it when drafting; untick it to stop. The list shows every knowledge base you can reach, including organization ones shared with you. Leave everything unticked and drafts are written exactly as before, with no knowledge base context.

:::info
Knowledge bases attach to your Inbox **account-wide, not per rule.** One selection applies to every draft Inbox writes for you.
:::

Inbox only ever **reads** a knowledge base — there is no Read/Edit choice here, and Inbox never adds to or changes one. (The built-in Insulin assistant has its own separate selection, which *can* be granted edit access — see [Knowledge Bases](/insulin/knowledge-base/#choosing-which-knowledge-bases-insulin-uses).)

The attached knowledge bases are searched only for drafts on their way to **Approvals ▸ Pending**. A reply that is sent automatically never consults them — no outside context goes into an automatic reply (see [When an auto-send rule may send](#when-an-auto-send-rule-may-send)) — and a rule with pinned canned text involves no model at all.

| Limit | Value |
|-------|-------|
| Knowledge bases you can attach | Up to 100 |
| Knowledge bases searched per draft | The first 3 you still have access to, in the order you saved them |
| Passages taken from each knowledge base | Up to 4 |

:::info
Knowledge base lookup is best-effort. If a search fails or runs long, Inbox still writes the draft — just without the extra context. Access is re-checked every time, so a knowledge base you lose access to is silently skipped.
:::

![Inbox Settings → Account scrolled to Knowledge bases — the Writing style card above a checkbox per knowledge base, showing that knowledge bases attach to the account rather than to an individual rule](images/23-inbox-knowledge-bases.png)

## Use Cases

- **Sort your mail your way** — Write rules that label the mail you actually get, and browse each label under **Mails**.
- **Faster replies in your voice** — Approve AI-drafted replies that already sound like you instead of writing from scratch.
- **Follow up when a deal moves** — Enable the Salesforce, HubSpot, or Dynamics 365 trigger and write a rule that drafts the follow-up email the moment an opportunity changes stage.
- **Keep the CRM current** — Add a **CRM action** to that rule, then click **Run in chat** to watch the agent apply it.
- **Hands-off acknowledgements** — Author a rule that sends automatically with a canned reply, to acknowledge a specific class of email without review.
- **Ask about your inbox** — Use the chat rail to triage out loud: *"which of these need a reply today?"*