# Campaign approvals (/security/campaign-approvals) Campaign approvals add an opt-in **four-eyes** control on campaign sends: nobody sends a campaign alone. It's there to catch an accidental send or stop a rogue one before it reaches recipients. ## How it works With approval required, sending a campaign doesn't send it. Instead: 1. A member without approval rights sends the campaign — this creates a **pending approval request** and moves the campaign to **Pending approval**, a read-only state, instead of sending it. 2. An approver — a member whose role has the `campaigns:approve` permission — reviews the request. 3. **Approve** executes the send. **Reject** or **cancel** returns the campaign to Draft. Owner and Admin have `campaigns:approve` by default; Editor does not. Like any permission, it can also be granted through a [custom role](/security/roles-and-permissions#custom-roles). ## Guardrails * **Self-approval is blocked** — the person who requested the send can never approve their own request. Someone else with `campaigns:approve` has to make the call. * **Approvers need a verified email** — an approval decision can't be made from an account whose email hasn't been confirmed. ## Recipients at send time For a campaign targeting a dynamic segment, the recipient list isn't frozen when the request is created — it's recomputed when the send actually executes, after approval. A segment's membership can shift between the request and the approval. ## Turning it on Enable the approval toggle in **Settings → SSO**, gated by `settings:manage`. Once on, it applies to every campaign send in the project. Pending requests awaiting a decision are listed in the **Approvals** queue. ## What's next See every approval decision recorded, with who and when. Control who holds the `campaigns:approve` permission. Back to the overview of the access-control surface.