A campaign ticket is the single container for a piece of marketing work, from brief to deployment. The brief, content, QA checklist, and delivery record all live on the ticket, so the team and Xperts work in the same place rather than splitting the planning across an external tool and Xtremepush.
The ticket page
Every campaign ticket has five main sections, always visible on the page. Team members at different stages have access to earlier decisions, for example: the content writer sees the plan, and the QA reviewer can see which channels were committed to. The section matching the current stage is open and highlighted; the others are collapsed but accessible at any time.
Description: a free-form text field for describing the campaign.
Planning: the campaign plan document and three dedicated planning fields.
Content: content items for each channel.
QA: the QA checklist and approval control.
Launch: approval, assembly, and deployment. Covers both the Approved and Assembly stages.
A Details panel sits alongside the main sections. It holds the ticket's metadata fields (assignee, delivery date, priority, labels, and landing URL), the stage timeline, dependency links, and the Xpert runs log.
Description
The Description section is a free-form text field for capturing the campaign brief and any context the team needs to share. Use it for background, rationale, or notes that don't belong in the structured planning fields. There are no required fields and no formatting constraints.
Details
The Details panel holds the ticket's metadata. These fields are available from the point of creation and can be updated at any stage.
Assignee: the person or Xpert currently responsible for the ticket. Assigning an Xpert and selecting "give a new instruction" lets you add an instruction for their next run.
Delivery date: the date the campaign needs to be ready by. Displayed on the board card and used to flag overdue tickets in Metrics.
Priority: High, Normal, or Low. Used to order work on the board.
Labels: free-form tags for filtering and grouping tickets on the board.
Landing URL: an optional URL field for the campaign's destination. Stored on the ticket for reference; it is not automatically injected into content.
Planning
The Planning section has two parts: a free-form markdown document for the campaign brief, and three dedicated fields that are used directly by Assembly.
Use the plan document to capture the brief, rationale, and any context the team needs. There are no required fields in the document itself: write as much or as little as the campaign warrants.
The three dedicated fields are:
Channels: the delivery channels for this campaign. The available options are Email, Push, SMS, In-app, and Web push. Every channel you add here needs a content item before Assembly can run.
Audience: a segment from your connected Xtremepush instance. The picker shows live segments from your real data. If no instance is connected, the field is read-only.
Send date and time: when the campaign should go out, with timezone.
Setting these fields in Planning means Assembly can build the campaign without re-entering anything: the plan is the single source of truth for what gets sent. Changing them after Assembly triggers drift detection in the Launch section.
You can assign an Xpert at Planning to research the brief and fill the plan document. The Xpert posts its findings as a comment when done, and you review and adjust before moving on.
Content
At Content, the team produces one content item for each channel listed in the plan. All channels must have content before Assembly can run.
Content can be written inline or linked from an existing artefact. Inline formats depend on the channel:
Email: subject line, preheader, and HTML body.
Push, In-app, Web push: title and body.
SMS: body only.
Each channel can only have one content source. Assigning an Xpert at Content will have it draft content for each channel on the plan, then post a summary comment when done.
QA
At QA, the team works through a checklist against the campaign. The default checklist covers the most commonly missed pre-send items: subject lines, links, merge fields, audience, schedule, and whether content covers all channels on the plan. Your admin can customise the checklist template to reflect your team's standards.
Mark each item as pass, fail, or not applicable. If an item fails, add a note explaining what needs fixing. N/A counts as settled: use it when an item genuinely does not apply, and say why in the note.
Once every checklist item has passed or been marked not applicable, a human team member can click Approve for deployment. Approval is always a human step: it separates the people who built the campaign from the people who approved it. Approving moves the ticket to Approved automatically (no need to drag the card). Xperts can work through the checklist but cannot approve.
Moving the ticket backward from Approved withdraws the approval and returns it to QA.
Launch
The Launch section covers the final steps before the campaign goes out: Approved and Assembly.
Approved
A ticket reaches Approved when a human clicks Approve for deployment in the Launch section. It signals that the campaign has passed review and is ready to be assembled. From here, any team member can trigger Assembly.
Assembly
Assembly builds the native Xtremepush campaign from the planning fields and linked content. It requires an active approval: if approval has been withdrawn by moving the ticket backward, it must return to QA first.
Before Assembly runs, all three planning fields (channels, audience, send date) must be set and every channel on the plan must have a content item. If anything is missing, Assembly will tell you exactly what it needs.
Once assembled, the campaign is visible in Xtremepush and linked to the ticket.
Linking to existing campaign
If a campaign already exists in Xtremepush, use Attach existing instead of running Assembly to link it to the ticket directly.
Drift detection
After Assembly, if the channels, audience, send date, or any content item changes, the Launch section shows a drift warning. You can rebuild the campaign to apply the changes, or keep the campaign as originally assembled. Rebuilding is not available once the campaign has already been deployed.
Deploy
The deploy action sends the assembled campaign to Xtremepush. After deployment, the ticket moves to Done and the delivery record appears on the ticket.
Stages at a glance
Stage | What the team is doing |
|---|---|
Backlog | Ticket queued; not yet active |
Planning | Writing the campaign brief; setting channels, audience, and send date |
Content | Producing content for each channel on the plan |
QA | Working through the QA checklist; human approval moves ticket to Approved |
Approved | Campaign cleared for Assembly |
Assembly | Campaign built from plan and content; deploy action available |
Done | Campaign deployed; delivery record visible on the ticket |
Cancelled | Ticket cancelled; removed from active pipeline |
Blocked tickets
Any ticket can be marked as blocked at any stage. A blocked ticket stays where it is and shows a red indicator on the board. Blocks can be set manually or triggered automatically by an open dependency link. Xperts will not pick up a blocked ticket.
Dependency links
Tickets can be linked to each other with two link types:
Blocks / is blocked by: a directional gate. Use it when one ticket genuinely cannot progress until another is done. CAMP-15 blocked by CAMP-14 keeps CAMP-15 in place and flags it on the board; the block clears automatically when CAMP-14 reaches Done.
Relates to: a sibling link with no gate. Use it to keep related tickets visible without creating a dependency. A multi-send brief becomes one campaign ticket per send, all linked with relates to so the full brief stays findable as one piece of work.
The activity stream
Every stage move, assignment, edit, and Xpert run is recorded in order in the ticket's activity stream. Use it to understand how a campaign progressed and who made which decisions.