Which ASTRA Actions Need Approval

Reads run free: ASTRA can pull a record, read a transcript, or summarize a call without anyone signing off. Above that, reversible writes with low consequence run on their own too, because they are cheap to undo if something is off. Logging a call as an activity against the right record, creating a Jira ticket from a task a call produced, filling a required field that does not touch pipeline math, and drafting a follow-up email into a holding queue, all fall into this bucket. Drafting itself is always in this category: proposing a change is not the same as making it. The pattern holds across tools, an internal, reversible write in Salesforce, HubSpot, Jira, or Gmail is treated the same way regardless of which system it lands in.

A shorter, specific list covers most of it: opportunity stage changes, amount and close-date changes, forecast and renewal or contract fields, any outbound message that reaches a customer such as a sent follow-up email, and record merges or deletes. These are the writes that are either hard to reverse cleanly or visible to someone outside the company the moment they land. A merged duplicate record, for instance, is one of the few CRM actions that cannot be cleanly undone with a single click, which is exactly why it is treated as consequential rather than routine. The same logic applies to a sent email: once it lands in a customer inbox, no amount of logging pulls it back.

A rule built around specific tasks or tools breaks down fast, because the same tool holds both trivial and consequential writes. The CRM is where you log an activity and also where you change a deal stage; a per-tool allowlist would either gate too much or too little. Gating by consequence sidesteps that: the question is always what the write can break, not what it is called or where it lives. That also means adding a new integration does not require inventing a new policy from scratch, the same read, reversible-write, consequential-write classification applies on day one.

No. Whether the draft is a CRM field change, a ticket, or an email, drafting is the reversible, no-consequence step by definition, ASTRA proposing an action is not the same as the action existing in your systems. What gets gated is the execution of the consequential ones, the moment a stage actually changes or an email actually sends. A draft that nobody reviews simply expires unactioned; nothing happens to your CRM, your ticketing system, or a customer's inbox because a draft sat unreviewed. The gate protects the write, not the proposal.

Yes, deliberately and per action type, not per agent wholesale. Autonomy is earned against a track record: once a specific kind of write, say, a particular field update, has been approved repeatedly with no edits, it can be promoted to run without a human step, while the audit trail keeps capturing every instance. That promotion is a conscious decision your team makes, not something that happens on its own as a side effect of volume. It also runs in reverse: if a promoted action type starts producing edits or rejections again, it can be pulled back under the gate just as deliberately.

Most integrations ship one blanket setting per connection, an app either can or cannot write to Salesforce, full stop. That is a coarser control than gating by consequence, because it cannot distinguish an activity log from a stage change; both are Salesforce writes, so a blanket toggle either blocks the harmless one along with the risky one, or allows the risky one along with the harmless one. ASTRA's gate operates one level down, at the level of the specific write, which is what lets low-consequence work move at full speed while the writes that can actually corrupt a pipeline or reach a customer still stop for a person, inside the same connection to the same tool.

A single call can produce several commitment types at once, and each is gated on its own terms, not as a batch. Say a call ends with a next-step field to update, a Jira ticket for an engineering question, and a promised follow-up email. The field update and the ticket, both reversible and internal, execute without waiting. The follow-up email is drafted and held, because it is customer-facing, and sits in the queue until it is approved, edited, or rejected. Nothing about the batch is held up waiting on the slowest piece; the reversible actions do not sit idle just because one item in the same call needs a human.

Default to gating it. The rule of thumb behind the whole design is that anything hard to reverse or visible to a customer is treated as consequential until it demonstrably is not, rather than assumed safe until proven otherwise. That is a deliberate asymmetry: the cost of holding a genuinely harmless write for one extra approval is a few seconds of a reviewer's time, while the cost of letting a genuinely consequential write run unsupervised is a corrupted record or a message a customer should never have seen. A new integration or a new action type inherits the cautious side of that trade-off by default, and only moves to the automatic side once its actual behavior earns it.