Approve, Edit, or Reject a Drafted Action

It shows a diff, not a payload. A stage change appears as the current stage next to the proposed stage, with the excerpt from the call that justified the move attached, so the reviewer is not reading raw text and guessing at intent. A drafted email shows the full message as it would send. A ticket shows its title, description, and the commitment it was drafted from. The point is that approving something should take seconds, not minutes: the old value, the new value, and the one line of evidence are the only things a reviewer needs to make the call, and that is deliberately all that is surfaced by default.

Approve executes the action exactly as drafted, the write goes through, gets verified, and is logged. Edit lets you correct the draft in place, a wrong amount, a mistimed date, an off-tone line in an email, and it is the edited version that executes once you confirm it, not the original. Reject discards the draft outright: nothing executes, and the account or record is untouched. All three are decisions, not just two, which matters because a wrong draft does not have to be thrown out entirely just to fix one field, and a draft that is simply wrong does not have to be approved to make it go away.

Wherever the team already works, typically Slack for a fast approve or inline edit, or the inbox for anything email-shaped. The underlying write still happens through the scoped integration for the tool it belongs to, a Salesforce or HubSpot field, a Jira ticket, a Gmail draft, but the decision itself is centralized into one queue rather than five separate tool notifications. That matters in practice: a reviewer checking Slack once a day should not also need to separately check a Salesforce approval tab, a Jira notification, and a Gmail drafts folder to know what is waiting on them.

Approval is not the last step. Once you approve, ASTRA executes the write inside your own account, then reads the record back to confirm the change landed as intended, not just that a request was sent. That verification step is what turns "we told the API to update it" into "we confirmed the CRM now shows it." The confirmed write is logged with enough context, the old value, the new value, who approved it, and when, to reverse it cleanly later if it turns out to be wrong for reasons nobody caught in review.

No. A rejection is itself an entry: who rejected it, when, and on which draft, written into the same tamper-evident trail as an approval would be. That is a deliberate choice, not an oversight. It means the trail stays honest even for the actions your team turned down, and it means an identical draft, if the same misread context comes up again, does not silently reappear unexamined, because the earlier rejection is part of the record ASTRA has to work from.

The reviewer is the person the action is about, typically the account owner, the rep on the call, or whoever is named as the accountable human for that workflow. That keeps the review meaningful: the person deciding whether a stage change is correct is the one who was on the call and knows whether the deal actually moved, not a queue triaged by whoever happens to be free. Nothing about the design requires a single fixed reviewer forever, a team can route different action types to different people, but each drafted action has one accountable decision-maker at the point it is approved, edited, or rejected, so responsibility for the call is never ambiguous after the fact.

An unreviewed draft simply does not execute. There is no default outcome that fires on its own after a delay, no silent auto-approve if nobody gets to it, because that would defeat the point of the gate. A queue that quietly executes anything left too long teaches a team to ignore it, which is the same failure mode as not having a gate at all. Instead, an aging, unreviewed draft is a visibility problem to solve on the team's side, worth surfacing again or nudging, rather than something the system resolves by acting anyway.

The review queue is meant to be read as a set, not one notification at a time. Because drafts from a CRM update, a Jira ticket, and a Gmail follow-up all route into the same place, a reviewer catching up after a busy day sees everything waiting on them in one pass rather than reconstructing it from separate tool notifications. That matters for a technical CS or RevOps reviewer covering several accounts at once: reviewing in a batch, several diffs back to back, is faster and less error-prone than context-switching between a CRM tab, a ticketing tool, and an inbox for each individual decision.