> For the complete documentation index, see [llms.txt](https://kbase.whitelabel-loyalty.com/product/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kbase.whitelabel-loyalty.com/product/loyalty-engine/campaigns/goal-based-campaigns/missions.md).
# Missions
Detailed reference for configuring missions within Goal Based campaigns — mission structures, nesting, sequencing, completion conditions, progress tracking, opt-in, time windows, and cooldown.
#### Adding a mission
From the Goal Based campaign detail screen, click **Add Mission**. The campaign's own setup (status, availability, title, description, artwork) is configured first, exactly as for any campaign.
**Choosing a mission structure**
When you add a mission, you first choose its structure:
* **Individual** — a single-action mission: one trigger, one goal.
* **Multiple** — a parent mission containing nested child missions, completed together.
***
#### Individual missions
An Individual mission tracks one goal. You configure:
1. **Name & description** — may be displayed to end-users depending on your interface.
2. **Event trigger** — the event type that counts toward progress. Each mission listens for one event type.
3. **Completion condition** — how progress is measured: Count, Value, or Boolean (see below).
4. **Conditions** *(optional)* — criteria an event must meet to count (e.g. only purchases over £20).
5. **Reaction** — what the user earns on completion.
6. **Display type, duration (time window), and cooldown** *(optional)* — see the sections below.
***
#### Completion conditions
Every Individual mission — and every nested child mission — has a completion condition:
* **Count** — completes when the user reaches a target number of qualifying events (e.g. make 10 purchases).
* **Value** — accumulates a value from each event's payload and completes at a target total (e.g. spend £200).
* **Boolean** — completes on the first qualifying event (e.g. leave a review).
{% hint style="info" %}
A Boolean mission is equivalent to a Count mission with a target of 1 — the difference is presentational (tick-box vs progress bar).
{% endhint %}
***
#### Multiple (nested) missions
A **Multiple** mission is a **parent** that holds two or more **nested** child missions. The user completes the parent by completing its children. This gives up to three levels of reward in one campaign:
* **Each nested mission** can have its own reaction — or none. Leave it blank and the child gives nothing on its own.
* **The parent mission** has a **completion reaction** that fires when all its nested missions are complete.
* **The campaign** has an overall completion reaction that fires when all its parent missions are complete.
A parent mission doesn't track events itself — it completes when its children do, and shows aggregate progress. Its completion condition is set automatically and isn't edited by hand.
{% hint style="success" %}
**Worked example — "2026 Tasks":**
* The campaign is **2026 Tasks**, containing four parent missions: **Spring, Summer, Autumn, Winter**.
* Each season contains four nested missions.
* Completing a season's four nested missions completes that season and pays out a season reward.
* Completing all four seasons completes the campaign and pays out a bigger year-end reward.
**How to build one:**
1. Add a mission and choose **Multiple**.
2. Give the parent its metadata (name, description, artwork, display type, duration, cooldown, opt-in).
3. Inside the parent, **add nested missions** — each is a full mission with its own trigger, conditions, metadata, and optional reaction.
4. Set the parent's **completion reaction**.
5. Save. As long as the overall campaign is still in Draft status you can edit the parent later to add more nested missions.
{% endhint %}
{% hint style="info" %}
Rewards can sit at any or all three levels — the individual step, the parent, and the whole campaign — so you can reward each task, each season, and the full year independently.
{% endhint %}
***
#### Sequential and parallel missions
Whenever a mission has more than one sub-mission — nested missions inside a parent, or parent missions inside a campaign — you choose how they're completed:
* **Parallel** *(default)* — the missions can be completed in any order, at any time.
* **Sequential** — the missions unlock one at a time, in a set order. A mission only becomes available once the one before it is complete.
When you choose **Sequential**, you **drag the missions into the order** you want them completed. That order is the order users must follow.
You can set this independently at each level — a campaign's seasons can run in sequence while the tasks inside each season run in parallel, or any mix.
**How gating behaves:** in a sequential set, an event for a later mission has no effect until the earlier mission is complete for that user. If "Part 1" must complete before "Part 2", reporting a Part 2 event while Part 1 is unfinished does nothing — no progress, no reward. Once Part 1 completes, Part 2 unlocks and starts accepting events.
***
#### Progress tracking
The Loyalty Engine tracks each user's progress on every mission, updating automatically as qualifying events arrive. When a mission completes it emits a completion event that fires its reaction and advances its parent — completion flows up from nested missions to the parent, and from parent missions to the campaign.
To view progress, open the campaign, select a mission, and choose **Track users**. You can drill into each user to see their status on the parent mission and each nested mission beneath it. The list supports search and CSV export.
***
#### User opt-in
By default, missions track from the first qualifying event. You can require users to **opt in** first — no progress is recorded until they do. For missions with a time window defined (see below), the time window still starts from the user’s first qualifying event after opting in (not from the opt-in itself).
Opt-in is only available on Goal Based campaigns, and only while the campaign is live.
Use opt-in for challenges where participation should be a conscious choice, or to measure sign-up interest separately from completion.
***
#### **Time windows**
A mission can have a **duration** — a per-user window that starts on the user’s first qualifying event (or, for opt-in missions, their first qualifying event after opting in) and ends at window start + duration.
* Complete within the window and the reaction fires.
* If the window passes before the mission is completed, the progress so far is cleared and the next qualifying event starts a fresh window. There’s no background timer closing the window — expiry is checked the moment the next event arrives. If that event lands after the window has passed, it doesn’t count toward the old attempt; it becomes the first event of a new window, and the clock restarts from it. In practice, each user’s window re-anchors to their first action after any lapse.
Each user has their own window; the start and end are in the API response so you can show countdowns.
{% hint style="info" %}
The window starts from the user’s first qualifying event — not the campaign start date, and for opt-in missions not the moment of opt-in. It’s measured as elapsed time from that event, not calendar days: a 1-day window opened at 21:00 runs until 21:00 the next day, with no midnight boundary. Each user’s window runs from their own first event.
{% endhint %}
***
#### Cooldown
By default a completed mission stays completed. Setting a **cooldown** makes a mission **re-completable** — after the cooldown passes, the user can earn it again, and its reward fires again on each completion.
Cooldown is set in days:
* **No cooldown (shown as “–”)** — the mission is one-shot: it completes once and doesn’t reset.
* **0 days** — the mission becomes re-completable instantly. Useful for stamp cards that should reset the moment they’re filled, so a customer can start a new card on the same visit.
* **1 or more days** — the mission resets once that many days have passed since completion; the next qualifying event then starts a new cycle.
Cooldown can be set on both parent and nested missions.
{% hint style="info" %}
The cooldown is elapsed time measured from the moment of completion, not calendar days. A mission with a 1-day cooldown completed at 21:00 becomes available again at 21:00 the next day — not at midnight. Each user’s cooldown runs from their own completion time.
{% endhint %}
***
#### FAQs
**What's the difference between an Individual and a Multiple mission?**
An Individual mission is a single goal. A Multiple mission is a parent containing nested missions completed together — letting you reward individual steps, the parent, and the whole campaign separately.
**Do nested missions have to give a reward?**
No. Leave a nested mission's reaction blank and it contributes to its parent's completion without paying out on its own; the reward then comes at parent or campaign completion.
**Can missions be completed in a set order?**
Yes. Set a group of missions to **Sequential** and they unlock one at a time in the order you arrange them. Leave them **Parallel** (the default) to allow completion in any order. This applies to nested missions and to parent missions at the campaign level.
**What happens after a mission is completed?**
With no cooldown it stays completed and further events don't re-trigger it. With a cooldown it resets and becomes re-completable once the cooldown elapses.
**How do I display mission progress to end-users?**
Progress data — value, target, status, lock state, time-window and cooldown timing — is available via the API for you to render in your own interface.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://kbase.whitelabel-loyalty.com/product/loyalty-engine/campaigns/goal-based-campaigns/missions.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
