> ## Documentation Index
> Fetch the complete documentation index at: https://agents.concierca.ch/llms.txt
> Use this file to discover all available pages before exploring further.

# Triggers & Drafts

> Schedule and webhook triggers, the duplicate-subject policy, and the safe draft to publish editing flow.

This page covers two things that happen *around* a mission's steps: how a mission **starts on its own** (triggers), and how you **change a live mission safely** (drafts).

## Triggers — starting a mission automatically

A mission can fire without anyone clicking **Run**. Triggers are configured in **Settings › Triggers**, and a mission can use a schedule, a webhook, or both.

<Warning>
  **Mission triggers are separate from agent schedules.** An agent can have its own schedule for its own runs — that has nothing to do with a mission trigger. A mission trigger starts *the whole mission*. Don't expect one to drive the other.
</Warning>

### Schedule trigger

Run the mission on a **cron schedule** — a standard **5-field cron expression**, evaluated in the **mission owner's timezone**. Use it for anything recurring: a weekday morning report, an hourly check, a monthly summary.

<Note>
  Pair a schedule with a **no-work token** on the first agent step (see [Flow & Steps](/guide/mission-flow)) so a scheduled mission stays quiet on days when there's nothing to do, instead of sending an empty digest.
</Note>

### Webhook trigger

Let an outside system start the mission by calling a **webhook URL that contains a secret**. When it fires, the **incoming payload lands in the run context**, so the mission's **first step can read it** — for example, a new order or form submission that kicks off the flow.

* **Secret in the URL** — the secret is what authorizes the call. Keep the URL private; rotate the secret if it leaks.
* **Payload in context** — step 1 can reference the incoming data through the mission's variables and templating.

### Duplicate policy

Because a webhook can fire more than once for the same thing, a mission has a **duplicate-subject policy** to avoid processing the same business subject twice:

| Policy     | Behavior                                                                         |
| ---------- | -------------------------------------------------------------------------------- |
| **Reject** | Ignore a trigger for a subject that's already been processed — safe idempotency. |
| **Allow**  | Process every trigger, even repeats.                                             |

<Note>
  Use **reject** when re-processing the same order, ticket, or record would cause harm (a double charge, a duplicate email). Use **allow** when repeats are legitimately independent events.
</Note>

## Drafts — changing a live mission safely

You don't edit a running mission in place. Bigger changes go through a **draft**: a private working copy you shape, preview, and validate before it goes live — with a version captured so you can always roll back.

<Steps>
  <Step title="Create a draft">
    Cut a draft from the live configuration. The live mission keeps running untouched while you work on the copy.
  </Step>

  <Step title="Update the draft">
    Make your changes — steps, contracts, variables, triggers — on the draft.
  </Step>

  <Step title="Preview the change">
    A **change-proposal preview** shows exactly what will differ between live and the draft before anything is committed.
  </Step>

  <Step title="Validate">
    Run **pre-flight validation** on the draft (agents assigned, approvers set, webhook secret present, enough credits, ordering proven) — read-only, no runs. See [Build › Test](/guide/mission-build).
  </Step>

  <Step title="Publish or discard">
    **Publish** to make the draft live — this **captures a version first** so you can compare or roll back — or **discard** to throw the draft away and leave live as it was.
  </Step>
</Steps>

<Warning>
  **Publishing is refused while a run is active.** Finish, pause, or cancel the current run first. This guarantees a run always executes one consistent version of the mission from start to finish — the flow can't change under a run that's already going.
</Warning>

Every publish snapshots the previous configuration, so **Versions** (in [Build](/guide/mission-build)) always has a clean history to **diff** and **restore** from.

<Note>
  From an AI client, the draft flow is `mission_draft_create` → `mission_draft_update` → `mission_change_proposal_preview` → `mission_validate` → `mission_draft_publish` (or `mission_draft_discard`). See the [Missions API reference](/for-agents/missions) and [Mission Recipes](/for-agents/ai/mission-recipes).
</Note>