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

> Triggers are the starting point of every automation — they listen for an event and fire the pipeline when it occurs.

# Triggers

# Triggers

A trigger is what starts an automation. Every automation has exactly one trigger node. When the trigger fires, it passes data downstream to your condition and action nodes.

## Trigger types

| Type                       | When it fires                                                                                                                                |
| -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
| **Collabase Event**        | When something happens inside Collabase — a task is created, a page is updated, a registry object changes, etc.                              |
| **Schedule**               | On a recurring timer defined with a cron expression — for example, every weekday at 09:00.                                                   |
| **Webhook**                | When an external system sends a request to the automation's unique URL.                                                                      |
| **Manual**                 | When a user clicks **Run** from the automation dashboard, or via the API.                                                                    |
| **External Service Event** | When a connected service pushes an event to Collabase — for example, a GitHub push or a Stripe payment. Documented on each connector's page. |

***

## Collabase Events

These triggers fire on activity inside Collabase. Select one from the **Collabase** category when adding a trigger node.

| Event                     | When it fires                                                          | Key payload fields                                                      |
| ------------------------- | ---------------------------------------------------------------------- | ----------------------------------------------------------------------- |
| `task.created`            | A new task is created in any project                                   | `taskId`, `taskTitle`, `taskKey`, `projectId`, `spaceId`, `createdBy`   |
| `task.updated`            | A task field is changed (title, description, priority, due date, etc.) | `taskId`, `taskKey`, `changedField`, `oldValue`, `newValue`             |
| `task.status_changed`     | A task moves to a different status column                              | `taskId`, `taskKey`, `taskTitle`, `oldStatus`, `newStatus`, `changedBy` |
| `task.assigned`           | A task is assigned or reassigned                                       | `taskId`, `taskKey`, `taskTitle`, `assigneeId`, `assignedBy`            |
| `task.completed`          | A task reaches a completed status                                      | `taskId`, `taskKey`, `taskTitle`, `completedBy`, `completedAt`          |
| `page.created`            | A new wiki page is created                                             | `pageId`, `pageTitle`, `spaceId`, `createdBy`                           |
| `page.updated`            | A wiki page is edited                                                  | `pageId`, `pageTitle`, `spaceId`, `updatedBy`                           |
| `page.commented`          | A comment is posted on a wiki page                                     | `pageId`, `pageTitle`, `commentId`, `commentBody`, `commentedBy`        |
| `test.run.completed`      | A test run finishes                                                    | `testRunId`, `testRunName`, `totalCases`, `passed`, `failed`, `blocked` |
| `registry.object.created` | A new object is created in a registry                                  | `objectId`, `registryId`, `registryName`, `spaceId`, `createdBy`        |
| `registry.object.updated` | An existing registry object is edited                                  | `objectId`, `registryId`, `changedField`, `oldValue`, `newValue`        |
| `comment.created`         | A comment is posted anywhere in Collabase                              | `commentId`, `commentBody`, `entityType`, `entityId`, `authorId`        |

<Note>
  All payload fields are available in downstream nodes using `{payload.fieldName}` — for example, `{payload.taskTitle}` or `{payload.oldStatus}`.
</Note>

***

## Schedule (Cron)

A schedule trigger fires on a recurring timer. Define the schedule using cron syntax or use the visual picker in the builder.

### Cron expression examples

| Expression     | When it runs                         |
| -------------- | ------------------------------------ |
| `0 9 * * 1-5`  | Every weekday at 09:00               |
| `0 9 * * 1`    | Every Monday at 09:00                |
| `0 0 1 * *`    | First day of every month at midnight |
| `*/15 * * * *` | Every 15 minutes                     |
| `0 8,17 * * *` | Every day at 08:00 and 17:00         |
| `0 0 * * 0`    | Every Sunday at midnight             |

<Note>
  Schedule triggers always run in **UTC** unless you set a timezone in the trigger configuration. Set the **Timezone** field to your local timezone (e.g. `Europe/Zurich`) to have expressions evaluated in that zone.
</Note>

Schedule triggers produce no payload fields. Use **Set Variable** or **Data Store** nodes if you need to pass context through the automation.

***

## Webhook

A webhook trigger fires when an external system sends a `POST` request to the automation's unique URL. Collabase generates one URL per automation — no additional configuration is required to receive requests.

### Getting the webhook URL

<Steps>
  <Step title="Open the trigger node">
    Open your automation and click the trigger node. The node panel opens on the right.
  </Step>

  <Step title="Copy the URL">
    Copy the **Webhook URL** shown in the configuration panel. It looks like:
    `https://your-collabase.example/api/v1/automation/auto-abc123/webhook`
  </Step>

  <Step title="Configure the sending system">
    Paste the URL into your external service's webhook settings. The service will send a `POST` request to this URL when its event occurs.
  </Step>
</Steps>

### Example request

```bash theme={"dark"}
curl -X POST "https://your-collabase.example/api/v1/automation/auto-abc123/webhook" \
  -H "Content-Type: application/json" \
  -H "X-Webhook-Secret: your-secret-here" \
  -d '{"event": "deployment.completed", "environment": "production", "version": "2.4.1"}'
```

The full request body is available in downstream nodes as `{payload.*}`:

* `{payload.event}` → `deployment.completed`
* `{payload.environment}` → `production`
* `{payload.version}` → `2.4.1`

### Webhook verification

Set a **Secret** in the trigger configuration to protect your endpoint. When set, Collabase checks the `X-Webhook-Secret` header on every incoming request and rejects requests with a missing or incorrect value.

<Warning>
  Without a secret, anyone who knows the URL can trigger your automation. Always set a secret for production automations that receive external requests.
</Warning>

***

## Manual

A manual trigger fires when a user explicitly starts the automation. This is useful for workflows you want to control — one-off tasks, testing, or on-demand processes that should not run automatically.

### Triggering manually in the UI

<Steps>
  <Step title="Open the automation">
    Navigate to **Automation** in your Space sidebar and open the automation.
  </Step>

  <Step title="Click Run">
    Click the **Run** button in the top-right of the automation builder. The automation fires immediately.
  </Step>
</Steps>

### Triggering via the API

You can also trigger a manual automation via the Collabase REST API:

```bash theme={"dark"}
POST /api/v1/automation/{automationId}/run
Authorization: Bearer <your-api-token>
Content-Type: application/json

{
  "inputs": {
    "targetSpaceId": "space-abc123"
  }
}
```

Any fields passed in `inputs` are available in downstream nodes as `{payload.fieldName}`.

***

## External service events

Several connectors support incoming events — they listen for activity in the external service and fire the automation when it occurs. These triggers are documented on each connector's individual page.

Examples include GitHub push events, Stripe payment confirmations, and Microsoft Teams messages posted to a channel.

→ [Browse connectors and their triggers](/automation/integrations)