> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Configure campaign defaults and send-gate preflight in Settings → Campaigns

> Operate the /settings/campaigns console end to end — set org-wide campaign defaults, configure the cross-campaign allocator, and define the send-gate preflight checklist that every campaign must pass before it goes live.

# 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.

<Note>
  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.
</Note>

***

## 1. Where this console sits in the campaign lifecycle

Three surfaces touch campaigns, and they are easy to confuse:

| Surface | Route | What it does |
| - | - | - |
| **Campaigns hub overview** | `/campaigns` | The operational dashboard: list running/draft/past campaigns, pause or resume, view analytics, and open the cross-schedule planner. |
| **Create wizard / journey builder** | `/campaigns/create`, `/campaigns/journey` | Build one campaign: audience, message, schedule, channel fallback chain, and journey graph. These set per-campaign values. |
| **Settings → Campaigns** | `/settings/campaigns` | Org-wide defaults and the preflight policy that every campaign inherits. Changes here apply to campaigns launched after the save. |

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](/concepts/campaign-allocator-model) 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](/guides/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](/guides/campaign-limits-quiet-hours):

* **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](/concepts/send-gating-and-quiet-hours) into a campaign-level gate. Each item can be set to **required**, **advisory**, or **off**:

| Gate | What it checks | Common setting |
| - | - | - |
| **Wallet posture** | Org is not paused and has usable balance | Required |
| **Compliance profile** | Required compliance posture is active for the campaign's destinations | Required for regulated traffic |
| **Quiet-hours window** | Sends fall inside the configured window | Required |
| **Frequency caps** | Per-contact caps are configured and not exceeded | Required |
| **Opt-out / suppression** | Audience is not on a suppression list | Required |
| **BAA (HIPAA)** | Executed Business Associate Agreement is in term when PHI is in scope | Required for HIPAA-mode orgs |
| **Two-factor verification** | The launching user has completed 2FA recently | Required for sensitive launches |

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:

* **[Campaigns hub overview](/campaigns/overview)** — the operational list and analytics surface.
* **[Campaign limits: audience-cap override and default quiet-hours window](/guides/campaign-limits-quiet-hours)** — the deep guide for the two limit cards on this console.
* **This guide** — the full console, including allocator defaults and the send-gate preflight.

When you are looking for how concurrent campaigns share a budget, read the [campaign allocator model](/concepts/campaign-allocator-model). When you are looking for how the runtime gates a single send, read [outbound send gating](/concepts/send-gating-and-quiet-hours). When you are looking for the checklist to run before any campaign launches, read [outbound compliance pre-flight checklist](/guides/send-gates-preflight-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](/compliance/baa-gate-guide).

### 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:

| Gate | Status |
| - | - |
| BAA executed and in term | Pass / Fail |
| Launching user 2FA verified | Pass / Fail |

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

* [Campaign limits: audience-cap override and default quiet-hours window](/guides/campaign-limits-quiet-hours) — the two limit cards on this console in depth.
* [The cross-campaign send allocator](/concepts/campaign-allocator-model) — how the allocator spreads campaigns across a shared budget.
* [Outbound send gating](/concepts/send-gating-and-quiet-hours) — the runtime gate chain every send walks.
* [Send Gates](/compliance/send-gates) — the BAA, quiet-hours, DNC, RND, and other compliance gates.
* [Outbound compliance pre-flight checklist](/guides/send-gates-preflight-checklist) — the pre-launch checklist for operators.
* [Campaigns hub overview](/campaigns/overview) — the operational campaign list and analytics surface.
* [Build a blast or drip campaign with the create wizard](/guides/campaign-create-wizard) — per-campaign creation walkthrough.
* [Build, simulate, and launch a campaign journey](/guides/campaign-journey-builder) — the journey builder surface.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.