Why we built an approval step into replying to email

Most helpdesk tools treat “send” as a single, unconditional action: an agent writes a reply, clicks send, and it’s gone. That’s fine once your team is small, senior, and trusted end to end. It’s a liability the moment any of that stops being true.

The problem with an all-or-nothing approval switch

The obvious first version of this feature is a global toggle: “require approval for all replies, yes or no.” We built that, tested it internally, and immediately hit its limits. A five-person team with one junior hire doesn’t want their two senior agents’ replies held up in a queue — only the junior one’s. A team with a brand-new department wants stricter review there than in a department that’s been running smoothly for a year.

A single switch forces a bad trade-off: either everyone’s replies get held up (slow, and it trains reviewers to rubber-stamp), or nobody’s do (defeats the point).

What we built instead

HelpDesk’s release rules resolve in three tiers, most specific wins:

1. A rule scoped to one specific person — “this teammate’s replies always need review,” full stop.
2. A rule scoped to a role — “everyone with the Agent role needs review,” without naming individuals.
3. A global default — the fallback for everyone not covered by a more specific rule.

That means you can require review for every new Agent by default, then carve out an exception the day one of them is ready to send unsupervised — without touching anyone else’s configuration.

What a reviewer actually sees

When a reply needs approval, it doesn’t just disappear into a queue. It shows up in a dedicated Release mailbox, visible to whoever the rule designates as an approver, with the full draft visible exactly as the customer would receive it. A reviewer has two options:

• Approve — sends immediately, and the thread reopens as normal.
• Reject with a reason — the message returns to Drafts, editable, with the reviewer’s note attached so the original author knows exactly what to fix.

Every decision — approved or rejected, by whom, when — lands in the audit trail. Nothing about this workflow is invisible after the fact.

Why this matters beyond “catching mistakes”

The obvious benefit is catching a bad reply before a customer sees it. The less obvious one is what it does for onboarding: a new hire can start actually helping customers on day one, under review, instead of either being blocked from replying at all or thrown in unsupervised. The review step is training, not just a gate.

See the release workflow in the feature list, or read why teams move off shared logins entirely.