#Outbound Campaigns

6 min read

Outbound Campaigns is a partner operational surface for creating, validating, launching, pausing, resuming, cancelling, and reporting on AiDial outbound campaigns. It is a selected-project surface: campaigns are listed and changed one project at a time, and the project is rechecked server-side against your partner assignments.

#Who Can Use It

RoleAccess
partner_adminCreate campaigns, import contacts, attach DNCR/registry wash evidence, run validation, control campaign state, and view reports.
partner_userView assigned-client campaign status, contacts, validation findings, and reports in read-only mode.

Customer roles do not manage outbound campaigns in the current portal. Navigation visibility is not the security boundary: /outbound-campaigns is restricted to partner roles, and any other role receives a generic not-found that does not reveal whether the surface exists. The read-only view for partner_user simply omits the controls; the write requests behind them are refused server-side regardless of what the page renders.

#Selecting A Project

Campaigns belong to a project, so the page needs one confirmed project before it loads anything. Choose one from the Project selector on the page. The list is limited to projects you are authorised for, and archived, deleted, and validation-fixture projects are left out.

Until a project is chosen the page shows a "Select a project" state. If the requested project is not in your authorised set, it shows "Campaigns unavailable for this scope" — the same body you would get for a project belonging to another partner, so the state does not confirm whether that project exists. If the campaign source cannot be reached, the page shows "Campaigns temporarily unavailable" with a Retry control. Once a project is selected and it has no campaigns yet, the page shows "No campaigns found".

/campaigns redirects to /outbound-campaigns and keeps any query parameters.

#What The List Shows

Four tiles summarise the loaded page of campaigns — Campaigns, Contacts, Pending, and DNC — above a table with one row per campaign: name and project, status and call type, readiness, registry wash, imported and pending contact counts, next run, failures, report availability, and last updated. Search filters by campaign name.

Status is one of draft, scheduled, running, paused, cancelled, completed, or failed. The Registry wash column reads "Not required" for service campaigns and for campaigns with wash disabled, "Registry wash not recorded" when no evidence is attached, and the wash timestamp otherwise.

Readiness in the list is a quick check based on whether contacts have been imported and whether unexpired wash evidence is attached. It can read Ready while the full launch validation on the campaign page is still Blocked — for example when CLI disclosure fields or outbound capacity are missing. Treat the campaign page as the authoritative readiness view.

#Campaign Workflow

  1. Select a project, then create a campaign. New campaigns start in draft.
  2. Import contacts by CSV.
  3. Attach DNCR/registry wash evidence when required.
  4. Run validation and resolve blockers.
  5. Launch the campaign when validation is ready.
  6. Pause, resume, or cancel the campaign as operational needs change.
  7. Review reporting for contact outcomes and retry state.

The create form captures name, call type (telemarketing, research, or service), timezone, priority (1-100, default 80), and an optional description. Retry policy, voicemail and IVR handling, approved personalisation keys, and campaign compliance settings are applied from portal defaults at creation: registry wash and consent are required for telemarketing and research campaigns and not for service campaigns.

There is no campaign edit screen in the portal. Campaign metadata updates and schedule windows are available on the campaign API rather than the portal UI, so campaigns created in the portal show "Not scheduled" for next run.

There is no hard delete action. Cancelling preserves campaign, audit, and reporting history.

#CSV Import Rules

Import is a paste-in flow on the campaign page and is partner_admin only: paste CSV text into the CSV Import box, which is pre-filled with a starter header row, then choose Import. There is no file picker. The page reports accepted and rejected row counts when the import returns.

CSV must be UTF-8 and requires a to_number column in E.164 form. Optional columns include contact reference, recipient timezone and location, registry status and evidence, consent evidence, exemption information, call type, priority override, max attempts, and campaign-approved personalisation keys. Unrecognised columns are rejected before any row is processed. Contacts can only be imported into draft or paused campaigns. The portal refuses a payload over 1 MB before it leaves the portal server, and the API caps a single import at 5000 contact rows.

The portal sends CSV content through its server-side upload path to the AiDial API. The API validates rows, accepts valid rows, returns row-level errors for invalid rows, and encrypts phone numbers and personalisation before persistence. Portal responses display masked phone placeholders and safe metadata only.

#Registry Wash Evidence

The Registry Wash Evidence form on the campaign page records a manual Australian DNCR wash and is partner_admin only. It captures a transaction reference, numbers submitted, numbers on register, invalid numbers, and a free-text reference. Numbers not on register are derived from those counts, and the evidence is recorded as valid for 30 days from the moment you attach it.

#Launch Validation

Validation runs against every campaign, not only telemarketing and research. Run and Resume recompute validation first and leave the campaign in its current state while validation is blocked; Pause and Cancel do not recompute.

Every campaign is blocked from launching until:

  • at least one contact has been imported
  • the project's published runtime configuration is available and free of blocking outbound compliance findings
  • outbound calling capacity is configured above zero

Telemarketing and research campaigns add:

  • DNCR/registry wash evidence that is present, unexpired, within the campaign's maximum age, and covering every imported contact
  • contacts that are not on the registry and that carry registry status, check timestamps, and unexpired registry validity
  • calling-window checks — recipient timezone, recipient location, after-hours, and public-holiday rules from the project's outbound compliance policy
  • the CLI disclosure fields: return number, employer, authoriser, and call purpose

Campaigns configured to require consent are additionally blocked by contacts with missing, expired, or withdrawn consent, or with unverified exemptions.

The campaign page shows the current validation result and lists the blocking findings under Launch Findings. Alongside it, Report Summary shows contact counts by status and the header tiles show campaign status, validation state, total contacts, and contacts due for retry. Disposition, registry-status, and linked-call aggregates are returned by the campaign report API but are not rendered on the page.

#Data Safety

The portal and API do not expose raw phone numbers, imported CSV payloads, ciphertext, raw configuration files, provider secrets, secret-management references, bearer tokens, API keys, or transcripts. The contact table shows masked phone placeholders, contact status, registry status, attempt counts, and linked call identifiers only. Partner users receive read-only operational summaries.