Skip to main content

​
Settings → Campaigns console

Open Settings → Campaigns. This console is the org-level control room for campaign defaults: it sits between the campaign-creation surfaces and the live send path, and it holds the three policy families that every campaign inherits unless it overrides them:
  • Defaults and allocator configuration — the cross-campaign allocator that spreads concurrent campaigns across a shared budget, plus the default quiet-hours fallback and audience-cap policy.
  • Send-gate preflight — the checklist of org-wide gates a campaign must satisfy before the Launch button enables.
  • Campaign-safety limits — the large-audience cap override and the default quiet-hours window that individual campaigns fall back to.
The page is gated to owner and admin roles. Developers can read these settings through the API, but the dashboard write surface requires owner or admin.
Every control on this page is tenant-owned: your organization decides which preflight gates are required, how large a campaign can be, and how concurrent campaigns share the send budget. This guide is not legal advice.

​
1. Where this console sits in the campaign lifecycle

Three surfaces touch campaigns, and they are easy to confuse: The create wizard and journey builder answer “what is in this campaign?” The Settings → Campaigns console answers “what must every campaign satisfy, and what budget do they share?” Keep that distinction in mind when you are deciding whether to change a value here or inside a single campaign.

​
2. Defaults and allocator configuration

​
Cross-campaign allocator

The cross-campaign send allocator spreads concurrent campaigns across a shared global hourly cap so their send peaks do not collide. The Settings → Campaigns console holds the defaults the allocator uses when a campaign does not supply its own value:
  • Default spread window — the time range the allocator uses for “spread these campaigns across…” plans when no explicit window is chosen.
  • Default global hourly cap — the maximum messages per hour across all campaigns together. This is the same cap that frequency caps enforce per contact, but applied org-wide to total send volume.
  • Default quiet-hours fallback — the recipient-local window where no allocator slot places sends, used when the campaign has no window of its own.
When you open the cross-schedule planner from the Campaigns hub, the planner pre-fills these defaults. You can override them for one plan without changing the org default. Saving a plan never mutates the defaults here. The allocator is deliberately advisory: it produces a recommended start time and per-slot volume for each selected campaign, but it does not schedule or launch anything. Apply the plan through the normal campaign scheduling flow.

​
Campaign-safety defaults

Two additional cards live on the same console and are covered in depth in Campaign limits: audience-cap override and default quiet-hours window:
  • Large-audience override — lifts the per-campaign audience cap above the platform floor.
  • Default quiet-hours window — the fallback window for drip and journey sends that do not set their own.
Both are enforced server-side on every send. They are mentioned here because they share the page; this guide does not repeat their API contracts.

​
3. The send-gate preflight

The preflight panel defines the org-wide checklist every campaign must satisfy before the Launch button is enabled. It turns the runtime send-gating model into a campaign-level gate. Each item can be set to required, advisory, or off: A gate set to required blocks launch until it passes. Advisory renders the item in the review panel but allows launch after acknowledgment. Off removes the item from the checklist entirely. The preflight is evaluated at launch time against current settings, not the settings that existed when the campaign was drafted. That means a campaign saved as a draft last week will be checked against today’s BAA status, wallet posture, and quiet-hours window when it finally launches.

​
4. When to tune these and what you see after creating a campaign

​
Tune the allocator defaults when:

  • Your marketing calendar has recurring weekly or monthly campaign clusters.
  • You want the cross-schedule planner to start from a known cap and window rather than re-entering them.
  • Your org’s total send volume is predictable enough that a global hourly cap is meaningful.

​
Tune the preflight when:

  • You operate in a regulated vertical and want launch to require BAA verification.
  • Your security policy requires 2FA confirmation before any campaign can go live.
  • You want to make quiet-hours or frequency-cap configuration a hard prerequisite for launch, so a forgotten setting cannot ship.

​
What you see once a campaign exists

After a campaign is created, the Settings → Campaigns console no longer edits that campaign directly. Instead, the campaign detail page shows which defaults it inherited and which it overrode:
  • A Defaults inherited card lists the org-level allocator window, global cap, and quiet-hours fallback.
  • A Preflight status section shows each required gate and whether the campaign passes it.
  • If a campaign overrides a default — for example, setting its own quiet-hours window — the override is displayed with a link back to the org default.
To change the policy for one campaign, edit the campaign in the create wizard or via the API. To change the policy for every campaign, change it here.

​
5. Relationship to the campaigns hub and the campaign-limits guide

Think of the three pages as layers: When you are looking for how concurrent campaigns share a budget, read the campaign allocator model. When you are looking for how the runtime gates a single send, read outbound send gating. When you are looking for the checklist to run before any campaign launches, read outbound compliance pre-flight checklist.

​
6. Worked example: require 2FA + BAA before campaign go-live

A healthcare org wants every campaign launch to prove two things: the operator launching it has recently verified with two-factor authentication, and the org’s Business Associate Agreement is executed and in term.

​
Step 1 — open the preflight panel

In Settings → Campaigns, find the Send-gate preflight card.

​
Step 2 — set BAA to required

Set BAA (HIPAA) to required. This gate checks that:
  • The org has attested HIPAA mode.
  • An executed BAA exists on file.
  • The BAA is not expired (one-year term from execution).
If any condition fails, the campaign launch returns 422 HIPAA_BAA_REQUIRED and the review panel links to the BAA execution flow.

​
Step 3 — set 2FA verification to required

Set Two-factor verification to required. The operator launching the campaign must have completed 2FA within the configured re-authentication window. If the session is too old, the launch call returns 403 REAUTH_REQUIRED and the dashboard prompts for a fresh 2FA challenge.

​
Step 4 — save and verify

Save the policy. Open an existing draft campaign and click Review. The preflight panel now lists both gates: Launch is enabled only when both show Pass. Because the preflight evaluates at launch time, a BAA that expires between draft and launch still blocks the campaign.

​
Step 5 — document the policy

Add an internal runbook note: campaigns in this org cannot launch unless the BAA is current and the launcher has re-verified 2FA. The Settings → Campaigns console is the single place where that policy is enforced for every campaign.

​
See also