> For the complete documentation index, see [llms.txt](https://documentation.taskmaverick.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://documentation.taskmaverick.com/processes/how-to-guides/set-up-process-triggers.md). # Set up Process Triggers A Trigger defines what starts your Process. Without a Trigger, your Process exists but never runs (unless launched [manually on demand](/processes/how-to-guides/launch-a-process-on-demand.md)). ## Why set up Triggers? Triggers are what make Processes automatic. A well-configured Trigger means your workflow runs itself — daily at 9 AM, every time a room checkout Mission is closed, or whenever a manager needs it on demand. No manual intervention required. ## Trigger types

Trigger	When the Process starts	Best for
Schedule	At a set time and recurrence pattern	Daily routines, weekly inspections, monthly audits
Mission Closed	When a specific Mission is completed	Event-driven workflows (checkout → cleaning → inspection)
No Trigger	Only when someone launches it manually	On-demand workflows like onboarding or incident response

A Process can have **multiple Triggers**. For example, a scheduled Trigger for routine daily runs plus a Mission Closed Trigger for event-driven starts. ## How to set up a Trigger 1. Open a Process in the Builder 2. Open the **Trigger panel** (left sidebar) 3. Select the Trigger type ### Schedule Trigger 1. Enter a **name** for the schedule (unique per Process, 3–36 characters) 2. Define the **destination**: unit, team, person, ticket board, or reference 3. Set the **repeat pattern** and **timing** — same options as [scheduling a Mission](/missions/how-to-guides/schedule-a-mission.md) 4. Save You can add **multiple schedules** to one Process (e.g. different times for different locations). ### Mission Closed Trigger 1. Enter a **name** for the Trigger 2. Select the **Mission** that should start the Process when closed 3. Define the **board** it runs on ([Team, Personal, or Ticket Board](/mobile-app/your-mobile-boards.md)) 4. Optionally select **References** 5. Save ### No Trigger No configuration needed — the Process can only be started [on demand](/processes/how-to-guides/launch-a-process-on-demand.md) from mobile. {% embed url="" %} ## Trigger statuses Each Trigger has its own status:

Status	What it means
Active	Fully configured, Process is published, schedule is current
Idle	Configured but not active yet (schedule date hasn't arrived)
Paused	Manually paused by an admin
Broken	Missing required parameters

You can **pause and resume** individual Triggers without affecting the rest of the Process. ## How Triggers pass data to Activities Triggers provide destination parameters (unit, team, person) that Activities can **reuse**. When an Activity's destination is set to "From Trigger," it automatically inherits whatever location or team the Trigger specifies. This is what makes one Process work across many locations — the Trigger determines *where*, and all Activities follow. ## Good to know * Multiple Triggers can coexist in one Process, each with its own destinations * Selecting "Unit from Trigger" automatically selects "Team from Trigger" * For repeating schedules, the next instance waits until the previous one completes or is canceled * Shared destinations across Triggers prevent duplicate Activity instances --- # 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 dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://documentation.taskmaverick.com/processes/how-to-guides/set-up-process-triggers.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. 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.