How to design an email approval workflow

What an approval is for#

An approval puts a second person between "ready" and "sent" for the messages where a mistake is expensive. The usual failures it catches are:

• The wrong people: a campaign sent to the full list instead of a segment, an internal note sent to a customer.
• The wrong content: an outdated price, a missing attachment, a figure copied from the wrong invoice.
• Commitments nobody signed off: an offer letter, a contract change, a refund.
• Volume mistakes: a workflow that runs against every contact, not just the new ones.
• Text nobody wrote: a reply drafted by an AI assistant and sent unread. See AI email governance for the rules around assistants.

Approval is not a substitute for permissions. People who should never send from the finance mailbox should not be able to, approval or not. Approvals are one layer of outbound email security, alongside access control, content checks and a record.

Decide what needs approval#

Approvals that depend on someone remembering to ask are skipped on the busiest days. Write the triggers down, and let the system apply them. Common triggers:

Keep the list short. If every email needs approval, approvers stop reading, and the approval becomes a click.

Make the approval mean something#

Bind it to the exact version#

The most common flaw in informal approval ("looks good, send it") is that the message can change afterwards. Approve a draft, fix a typo, change a figure, and the approval still stands. A sound workflow ties each approval to one version of the message: if anything changes, the pending request is cancelled and a decision on the old version is refused.

Separate the duties#

The person who prepared, owns or started the work should not approve it. This is the separation-of-duties principle used across finance and security: one person cannot both initiate and authorize. Allow exceptions only as an organization-wide setting that someone has chosen deliberately.

Use more than one approver sparingly#

For the highest-risk mail (a send to every customer, a legal notice) require two or three approvers. For everything else, one is enough. More approvers on routine mail slows everyone and teaches people to approve without reading.

Let requests expire#

A request nobody decides should not sit forever and then release a message that is no longer right. Set an expiry that fits your working week, and let the requester withdraw a request or void it to cancel what it was holding.

Make deciding easy#

• Tell approvers where they already are. Announce waiting requests in the team's chat or by email, with a link straight to the decision.
• Show the reasons. An approver should see why the message was held: outside recipients, an attachment, a contact group, links that hide where they go.
• Allow decisions on a phone. Many approvals wait only because the approver is away from a desk.
• Show the message as recipients will see it, with the details fixed when the request was made.

What to record#

For every approval keep: who requested it, what it held (the message or the campaign), which version, who decided and how, when, and what happened next. That record answers the question "who let this go out?" months later. See what an email audit trail should record for the full list.

A starting policy#

Adapt this to your organization; it is a starting point, not a standard.

Common mistakes#

• Approving a screenshot or a forwarded draft instead of the message that will actually go.
• Sharing one mailbox password so "anyone can send", which makes approval impossible to enforce.
• Approvals that notify but do not hold, so the email goes whether or not anyone agreed.
• No expiry, so an approval from last month releases this month's mistake.

How SecureThread does it#

SecureThread's approvals hold scheduled sends, campaigns, workflow runs and AI-assistant sends. Each approval is tied to one version of its item; a change cancels the pending request. Nobody can approve their own work by default, an organization can require one to three approvals, requests expire after 72 hours by default (up to 720), and waiting requests can be announced in Slack, Microsoft Teams and by email. Approving from inside Slack or Teams is not available yet, so the decision is made in SecureThread, on a computer or a phone.