What an Inbox CRM Action Changed—and Who Authorized It

An Inbox CRM action is a written instruction that a rule raises when a deal changes stage in Salesforce, HubSpot or Microsoft Dynamics 365, and that runs only when you click Run in chat. Insulin records it in two parts: a receipt written at the click, naming who authorized it and when, and an outcome written when the run ends, showing what changed.

---

A deal moves to Proposal in Salesforce. A rule you wrote fires, and two things wait for you in the Inbox app, side by side: a drafted follow-up email, and a CRM action that reads “update the CRM with a short summary of the latest email thread.” You send the email, click Run in chat on the action, and the agent writes to the opportunity.

Months later, a RevOps lead or an auditor asks the question every AI write to a system of record eventually gets: what exactly did it change, and who said it could?

For CRM actions in Insulin’s Inbox, the answer is one row in Approvals ▸ History, written in two parts at two different moments. The split is the design worth understanding: the authorization and the result are recorded separately, so a run that never finished shows as unfinished rather than as a success, and the run itself cannot reach any integration other than the CRM the action came from. The email you sent is not in that row at all: it was a separate authorization.

This post covers exactly that surface: CRM actions, which only a rule triggered by a Salesforce, HubSpot or Dynamics 365 event can raise. What an agent audit log should capture in general is a wider question, covered in what an AI agent audit log should record.

What is an Inbox CRM action?

An Inbox CRM action is a written instruction that a CRM-triggered rule places in Approvals ▸ Pending, where it appears as its own block: the instruction, beside a Run in chat button. It is never executed silently. Nothing happens until you click, which hands the instruction to the agent in the Inbox chat rail and lets you watch it run.

Three facts about where it comes from set the boundaries for everything below:

• Only a CRM-triggered rule can raise one. Salesforce, HubSpot and Dynamics 365 all support it. An email rule can draft a reply, but it cannot raise a CRM action.
• What you authorize is the instruction. It is required, and it is what the card shows, rather than a set of field values.
• It combines with the rule’s other outputs. The same rule can also draft an email and send you a Slack DM, which is where the question of what one click covers begins.

Does one approval send the email and run the CRM action?

No. The email and the CRM action are separate authorizations, each with its own click. When a CRM-triggered rule drafts an email and raises a CRM action from the same event, both wait in Approvals ▸ Pending side by side, and each leaves the queue on its own terms:

	The email the rule drafted	The CRM action the rule raised
What waits in Pending	A new email with an editable To, Subject and body	The written instruction, beside Run in chat
What authorizes it	Send, then confirming “Send this email?”	A click on Run in chat
What happens next	It is sent from your mailbox, with no unsend or recall	The agent runs the instruction in the Inbox chat rail, limited to the CRM the action came from

Pressing Send authorizes nothing about the CRM action, and clicking Run in chat authorizes nothing about the email. Setting up the rule that raises both is covered in auto-drafting a follow-up when a deal stage changes.

What does an Inbox CRM action’s History row record?

Two parts written at two moments: a receipt the instant you click Run in chat, and an outcome when the agent finishes. Keeping them apart is what lets one row tell authorized from done. Here is the row, part by part:

Part of the row	What it holds	What it tells a reviewer
The action	The deal it belongs to, the instruction, and its status	Which deal, and what was asked
Receipt, written when you click Run in chat	The instruction, Authorized by, and when	Who authorized this instruction, and when
Outcome, written when the agent finishes	Whether the CRM write succeeded or failed, the agent’s short summary, and the records it created or updated	What the agent recorded as the result
Before and after, within the outcome	For each record written, its field values before and after the write, where the agent was able to read that record	What changed, not only that something did
not captured	Shown for a record whose prior values could not be read	The prior values are unknown, which is not the same as nothing changing
outcome not recorded	Shown when the agent never got to record an outcome	The result is unknown, and it is never presented as a success
Conversation link	A link to the chat-rail conversation the action ran in, while that conversation exists	Where to read the run itself

Two properties make the row evidence rather than decoration:

• The receipt exists before the result does. A run that stops halfway still leaves a record that it was authorized, by whom and when.
• Only the run launched from the action’s own card can write its outcome, and the outcome always lands on that action, so a result cannot end up on another action’s row.

History is also not the chat transcript. It is the durable record, and it outlives the conversation; the row’s link to that conversation works only while the conversation exists.

What does one click on Run in chat authorize?

The instruction on the card, run once, against the one CRM connection the action was raised from. When you click, Insulin works out what the run may touch from the stored action, not from your browser. What the click covers:

• The instruction, not a set of values. The field values the agent writes show up afterwards, in the outcome.
• One CRM connection. The agent can use only the Salesforce, HubSpot or Dynamics 365 connection whose event fired the rule, plus the step that records the outcome.
• Nothing else. Your other integrations, the Inbox mail tools, rule creation, jobs, the browser, the file sandbox, memory and goals are out of reach for the run.
• No questions mid-run. The agent can’t stop to ask you anything, so the time to read the instruction is before you click.
• One run at a time. Click Run in chat on several actions and the rail runs them in order, each waiting for the previous one to finish.
• That one run. The limit covers that run only: a message you type in the rail afterwards is an ordinary rail conversation again.

One kind of action can’t be run at all. An action queued before Insulin recorded its CRM connection can’t be run: in place 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.”

What happens when a run fails or never finishes?

History tells three endings apart: succeeded, failed, and outcome not recorded. A write that failed is recorded as failed. A run that never got to record an outcome, after a tool failure or a closed tab for example, shows outcome not recorded rather than a fabricated success, so the authorization and the result are always told apart.

A failed run offers no Retry. The CRM write may already have happened before the reply stopped, so instead of a Retry button 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.”

That is the right default for a write to a system of record. A retry button assumes a failed run changed nothing. Here the write may already have landed, and running the same instruction again unchecked could apply it twice. The reviewer’s corollary: treat outcome not recorded as unknown, neither done nor undone, and settle it against the record in the CRM itself.

What doesn’t History show?

What you archived, and what you only previewed. Two gaps matter to a reviewer:

• Items you archived. Archiving an item in Approvals ▸ Pending discards it without adding a History row.
• Rule previews. A rule Preview writes no approval row and takes no CRM action, so testing a rule adds nothing to History.

Inside a row, the gaps are the ones it names itself: not captured for prior values it could not read, and outcome not recorded for a run that never recorded its result.

How do you export Inbox CRM action records for a review?

Export a date range from Approvals ▸ History as a CSV, check whether the file ends with a truncation marker, and narrow the dates until it doesn’t. Each exported row carries its receipt, its outcome and any captured before/after diff, so the record can be pulled without asking engineering. As a routine:

1. Spot-check first. Search History by deal name, instruction or outcome summary to find one deal’s actions.
2. Export the period. Export downloads the ledger for a date range as a CSV.
3. Check the end of the file. A very large range is capped, and a capped file ends with a truncation marker. If yours does, split the period into narrower ranges and export each, until no file ends with one.
4. Settle the gaps in the CRM. For every outcome not recorded, and every record marked not captured, open the record in the CRM itself.
5. Keep your own copy. CRM-action records are kept for two years from the moment they were authorized, then removed; sent-email records follow the mailbox’s own retention. If your policy needs the record for longer, export before rows age out.

Frequently asked questions

Does one approval send the email and run the CRM action?

No. They are separate authorizations. The email goes out when you press Send and confirm; the CRM action runs when you click Run in chat.

Who authorized an Inbox CRM action, and when?

The receipt says. It is written the moment you click Run in chat and holds the instruction, Authorized by, and when. It sits in the action’s History row next to the outcome, which is written when the agent finishes.

Can I see what an Inbox CRM action changed?

Yes, where the agent could read the record. The outcome lists each record the agent wrote, with its field values before and after the write. A record whose prior values couldn’t be read is shown as not captured, rather than as an empty change.

What does outcome not recorded mean?

The agent never got to record a result, after a tool failure or a closed tab, for example. History shows outcome not recorded instead of a fabricated success. A failed run offers no Retry, so check the record in your CRM before running the action again.

What can a Run in chat reach?

Only 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 for that run.

How long are Inbox CRM action records kept?

Two years from the moment each was authorized, then they are removed. Sent-email records follow the mailbox’s own retention instead. To keep a longer record, export a date range from Approvals ▸ History as a CSV.

Takeaways

• An Inbox CRM action is a written instruction that only a rule triggered by Salesforce, HubSpot or Dynamics 365 can raise, and it runs only when you click Run in chat.
• The email and the CRM action are separate authorizations: Send for one, Run in chat for the other.
• A CRM action’s row pairs a receipt written at the click with an outcome written when the run ends, and shows outcome not recorded when no outcome was written.
• Before-and-after values appear where the agent could read the record; otherwise the record shows not captured.
• One click reaches one CRM connection, for one run, and a failed run offers no Retry.
• Export by date range, watch for the truncation marker, and keep a copy before the two-year retention removes rows.

An AI that writes to your CRM earns an auditor’s trust by keeping the click and the result apart. See how the Inbox app turns a deal-stage change into a drafted email and a CRM action, and read Approvals ▸ History in the Inbox documentation for the full reference.