> 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/what-are-processes.md).

# What are Processes?

A Process is an automated workflow that chains [Missions](/missions/what-are-missions.md) together. When one Mission is completed, the next one is triggered automatically — based on rules you define. Instead of manually coordinating who does what next, the system handles it.

## Why use Processes?

Without Processes, every step in a multi-step workflow requires someone to manually post the next Mission to the right board at the right time. That works when you have 5 employees. It breaks when you have 500 locations running the same procedures every day.

Processes solve three problems at once:

**Automation** — define the workflow once, and it runs itself. A room checkout triggers cleaning, which triggers inspection, which triggers check-in readiness — all without a manager touching anything.

**Conditional logic** — the next step depends on the result of the previous one. If the fridge temperature is above 8°C, trigger a maintenance alert. If the employee passes the test, move on. If they fail, assign training. The system decides, not a person.

**Cross-team coordination** — one Process can route work to different teams automatically. The receptionist closes checkout → the cleaning team gets a task → the maintenance team gets an alert if something is broken → the receptionist gets the all-clear. Each team sees only their piece.

## Real-world examples

**Hotel room turnover**\
Guest checks out (trigger) → cleaning checklist goes to housekeeping → if the room passes inspection, it's marked available → the receptionist gets a check-in task for the next guest.

**Employee break management**\
Employee clocks in for an 8-hour shift → after 2 hours, a 10-minute break Mission appears on their personal board → after 4 hours, a 30-minute lunch break → after 6 hours, another 10-minute break. All breaks must be completed before the employee can clock out.

**Inventory restocking**\
Employee completes a storage checklist → enters that there are only 3 kg of tomatoes (minimum is 15 kg) and 8 kg of onions (minimum is 10 kg) → Tasks to purchase tomatoes and onions are automatically triggered to the Purchasing Team board.

**Health screening before shift**\
Every employee answers a health survey before starting work → if they report a high temperature, a Ticket alerts their manager → a separate Task to find a replacement is triggered to the scheduling team.

**Multi-step inspection with escalation**\
Hotel maid cleans a room and completes an inspection checklist → reports a broken window → a repair task goes to the Repair Department → reports a shower leak → a separate task goes to the Plumbing Department. All from one Process, automatically routed.

## Key concepts

<table><thead><tr><th width="167.3333740234375">Term</th><th>What it means</th></tr></thead><tbody><tr><td><strong>Trigger</strong></td><td>What starts the Process — a <a href="/missions/how-to-guides/schedule-a-mission.md">schedule</a>, a Mission being closed, or a manual <a href="/missions/how-to-guides/configure-mission-settings/controlling-mission-execution.md#on-demand">on-demand</a> launch</td></tr><tr><td><strong>Activity</strong></td><td>One step in the Process — a Mission, a Ticket, or a Delay (wait time)</td></tr><tr><td><strong>Condition</strong></td><td>A rule that decides what happens next — "if the answer is X, trigger Activity Y"</td></tr><tr><td><strong>Connection</strong></td><td>The visual link between Activities showing the workflow path</td></tr><tr><td><strong>Destination</strong></td><td>Where an Activity lands — a specific team board, personal board, or ticket board</td></tr><tr><td><strong>Level</strong></td><td>Activities are arranged in levels — level 1 runs first, level 2 runs after conditions on level 1 are met, and so on</td></tr></tbody></table>

## How Processes work

1. A **Trigger** starts the Process (schedule, mission closure, or manual start)
2. **First-level Activities** are posted to the relevant boards
3. When employees complete an Activity, **Conditions** are evaluated
4. **Next-level Activities** are triggered based on the results
5. The Process continues until all required Activities are completed

On mobile, employees see Process Activities as regular Missions on their boards. They can view a **Process Trail** showing where the current Mission fits in the overall workflow.

## What employees see

Employees don't need to learn anything about Processes. They see regular Missions on their [mobile boards](/mobile-app/your-mobile-boards.md) — the same way they always do. The only additions:

* **Trigger Details** — shows why the Mission appeared (which Process, which previous Activity triggered it, what condition was met)
* **Process Trail** — shows the full workflow chain: what's been completed, what's in progress, and what's planned next

## Good to know

* Only [**Published** Missions](/missions/how-to-guides/publish-a-mission.md) and Tickets can be used as Activities
* A Process can have up to **500 Activity instances** (you'll see a warning at 100)
* Process lifecycle: **Draft → Published → On Hold → Archived** (or **Broken** if dependencies change)
* Processes can be **duplicated** to use as templates for similar workflows
* Only [System Admins](/your-organization/people.md#roles) can create and manage Processes


---

# 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/what-are-processes.md?ask=<question>&goal=<endgoal>
```

`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.