> ## Documentation Index
> Fetch the complete documentation index at: https://docs.navisops.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Workflow triggers: how automations start
> Every workflow starts with a trigger. Choose from manual, scheduled, webhook, note, entity, and task triggers to control exactly when your automation runs.
Every workflow needs exactly one Trigger node as its entry point. The trigger defines the event that causes the workflow to run. To add a trigger, drag a **Trigger** node from the Automation section of the left sidebar onto the canvas, then open the node's settings panel to choose and configure the trigger type.
## Trigger types at a glance
Run on demand by clicking a button.
Run on a repeating schedule using a cron expression.
Run when an external service sends an HTTP POST to your endpoint.
Run when a note is created or updated in your workspace.
Run when a project or calendar event is created.
Run when a task's status changes or its due date arrives.
***
## Manual
The Manual trigger runs the workflow when you click the **Run** button in the workflow editor toolbar, or when an AI assistant calls the workflow as a tool via the MCP server. The workflow sits idle until you explicitly start it — nothing fires automatically.
**Best for:** On-demand automations like sprint setup, weekly reviews, bug report scaffolding, or any process you want to kick off yourself rather than have run in the background.
**Trigger data available:** A basic trigger context with the timestamp of the run. No entity data is included since no workspace event started the workflow.
***
## Scheduled (cron)
The Scheduled trigger runs the workflow automatically on a repeating interval defined by a cron expression. You can choose from six built-in presets or write a custom expression, and you set the timezone the schedule runs in.
**Best for:** Daily digests, weekly review automation, recurring maintenance tasks, or any process that should happen on a calendar cadence without manual intervention.
### Schedule presets
| Preset | Cron expression | Runs |
| --------------------- | --------------- | ---------------------------------- |
| Every 15 minutes | `*/15 * * * *` | At :00, :15, :30, :45 every hour |
| Hourly | `0 * * * *` | Top of every hour |
| Daily at 9 AM | `0 9 * * *` | Every day at 9:00 AM |
| Weekdays at 9 AM | `0 9 * * 1-5` | Monday–Friday at 9:00 AM |
| Weekly (Monday 9 AM) | `0 9 * * 1` | Every Monday at 9:00 AM |
| Monthly (1st at 9 AM) | `0 9 1 * *` | First day of each month at 9:00 AM |
### Custom cron expressions
Cron uses a five-field format: `minute hour day-of-month month day-of-week`
| Field | Allowed values | Special characters |
| ------------ | ---------------- | ------------------------------------------------- |
| Minute | 0–59 | `*` every, `*/N` every N, `N-M` range, `N,M` list |
| Hour | 0–23 | Same as above |
| Day of month | 1–31 | Same as above |
| Month | 1–12 | Same as above |
| Day of week | 0–6 (Sunday = 0) | Same as above |
**Examples:**
```text theme={null}
30 14 * * * Every day at 2:30 PM
0 */2 * * * Every 2 hours
0 9 * * 1,3,5 Monday, Wednesday, Friday at 9 AM
0 0 1,15 * * 1st and 15th of each month at midnight
```
Scheduled workflows deduplicate automatically — if a workflow's last run was within 60 seconds, the scheduler skips the duplicate execution.
***
## Webhook
The Webhook trigger fires when an external service sends an HTTP POST request to a unique endpoint URL that Navis Ops generates for your workflow. This lets you connect any external tool — GitHub, Stripe, Zapier, or a custom service — to your workflow automation.
**Best for:** Reacting to events in external systems, receiving data from third-party integrations, or triggering workflows from your own code.
### How to set up a webhook trigger
In the Trigger node's settings panel, choose **Webhook** from the trigger type dropdown.
Toggle the **Active** switch in the toolbar. Navis Ops generates a unique webhook endpoint URL and a secret key, both shown in the Trigger node's configuration panel.
Copy both values from the panel. The URL is where your external service sends POST requests. The secret authenticates requests.
Paste the URL as the webhook destination in your external tool. Set the `x-webhook-secret` HTTP header to the secret value. Send requests as JSON with `Content-Type: application/json`.
### Accessing webhook payload data
The JSON body of the incoming POST request becomes available in your workflow via the `{{trigger.entity_data.payload.*}}` variable path. For example, if the payload contains `{"event": "push", "ref": "refs/heads/main"}`, you can reference `{{trigger.entity_data.payload.event}}` and `{{trigger.entity_data.payload.ref}}` in downstream nodes.
### GitHub example
1. Go to your GitHub repository's **Settings → Webhooks**.
2. Set **Payload URL** to your Navis Ops webhook URL.
3. Set **Content type** to `application/json`.
4. Set **Secret** to match the `x-webhook-secret` value from Navis Ops.
5. Choose which events to send.
The webhook endpoint only accepts requests while the workflow is enabled. Disable the workflow and your endpoint stops accepting incoming requests.
***
## Note triggers
Note triggers fire based on activity in your notes.
### Note created
Fires when any new note is created in your workspace. Use an optional filter to limit the trigger to notes whose title contains a specific substring (case-insensitive).
**Example:** Filter by `meeting` to fire only when a note with "meeting" in the title is created — useful for automatically generating follow-up tasks from meeting notes.
**Trigger data available:** `{{trigger.entity_data.title}}`, `{{trigger.entity_data.id}}`, and other properties of the newly created note.
### Note updated
Fires when an existing note is updated. Supports the same optional title substring filter as Note Created.
**Best for:** Triggering a review process when documentation changes, tracking when key notes are modified, or keeping a changelog task up to date.
***
## Entity triggers
Entity triggers fire based on activity in your projects and calendar.
### Project created
Fires when a new project is created in your workspace. Optionally filter by project type so the workflow only runs for certain kinds of projects.
**Best for:** Automatically scaffolding new projects — generating a kickoff note, creating onboarding tasks, assigning team members, and setting a project to active.
**Trigger data available:** `{{project.id}}`, `{{project.name}}`, and other project properties.
### Calendar event created
Fires when a new calendar event is created in your workspace.
**Best for:** Creating preparation tasks automatically when meetings are scheduled, sending reminders, or linking calendar events to projects.
***
## Task triggers
Task triggers fire based on changes to your tasks.
### Task status changed
Fires when any task's status is changed. Add an optional filter to limit the trigger to a specific status value — for example, `blocked` or `done`.
**Best for:** Escalation workflows that respond when a task is blocked, completion workflows that trigger follow-up steps when a task is done, or status-driven notification flows.
**Trigger data available:** `{{trigger.entity_data.title}}`, `{{trigger.entity_data.status}}`, `{{trigger.entity_data.priority}}`, and other task properties.
### Task due date
Fires when a task's due date matches today, evaluated on a daily schedule. Optionally filter by how many days before the due date the trigger should fire.
**Best for:** Due date reminders, daily digest workflows that summarize what's due today, or pre-deadline preparation tasks.
***
## Trigger filtering
Most trigger types accept an optional **filter value**. When you set a filter, the workflow only fires when the event data matches — events that don't match are ignored silently.
| Trigger type | What the filter matches |
| ------------------- | ------------------------------------------------------- |
| Project created | Project type |
| Task status changed | The specific new status value (e.g., `blocked`, `done`) |
| Task due date | Days before the due date |
| Note created | Note title (case-insensitive substring) |
| Note updated | Note title (case-insensitive substring) |
Leave the filter empty to fire on all events of that type.
When testing a new trigger, remove any filter first. This makes it easier to confirm the trigger fires at all before narrowing it down with filter conditions.
## Next steps
Learn about the action and logic nodes that execute when your trigger fires.
Reference trigger data in downstream nodes using the variable system.