Approve customer email before it runs
Use this pattern when an agent is about to send a customer-facing email, reply, or outbound message that a person should review first.
When to use this
Use this pattern when an agent is about to send a customer-facing email, reply, or outbound message that a person should review first.
Where Stacksona fits
Place Stacksona after the agent drafts the message and before the email send step.
What the reviewer should see
- recipient
- subject
- draft body
- customer or account
- ticket or conversation context
- reason the agent wants to send
- risk or review reason
- any policy threshold or escalation reason
Minimum fields to send
agent_idworkflow_idtool_name: send_emailaction_type: customer_email- recipient
- subject
body_preview or draft_bodycustomer_id or account_id- reason
reviewer_group, if knowncallback_url, if using async review
Example request
json
{
"agent_id": "support-agent-01",
"workflow_id": "ticket-reply-flow",
"tool_name": "send_email",
"action_type": "customer_email",
"recipient": "[email protected]",
"subject": "Update on your support request",
"draft_body": "Hi Jordan, we reviewed your ticket and can replace the item today.",
"customer_id": "cus_1042",
"reason": "Agent drafted a customer-facing reply for a shipping issue.",
"reviewer_group": "support-leads",
"callback_url": "https://app.example.com/stacksona/callback"
}How to branch after the decision
| Status | Behavior |
|---|---|
allowed or approved | Send the email. |
pending_review | Pause, poll, or wait for callback. |
rejected | Do not send. |
expired or error | Do not send by default. |
What to log after execution
- decision_id
- message_id or provider id
- sent_at
- final recipient
- final subject
- execution_status
Common mistakes
- sending before the decision is approved
- showing reviewers only a summary without the actual draft
- not logging the final send result
- retrying a send after rejection