> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Flow templates catalog: the 12 built-in starter flows
> Every pre-built starter flow the platform ships — the full catalog with triggers, channels, and node counts; cloning a template from the dashboard or the API; what to customize before you publish; and when a template is the wrong starting point.
# Flow templates catalog
The platform ships a catalog of pre-built starter flows — ready-to-clone automations for the use cases customers build most. Each template carries a complete flow graph (trigger, nodes, and edges) that you copy into a new draft, adjust to your brand and timing, and publish. The same catalog backs both surfaces: the dashboard's template gallery and the `GET /api/v1/flows/templates` API endpoint.
Templates are starting points, not locked automations. Cloning one gives you an ordinary draft flow — nothing about it stays tied to the template. The full model — clone detachment, provenance, versioning and drift — is in [Flow templates model and clone semantics](/concepts/flow-templates-model).
Twelve templates ship today. The catalog endpoint returns all of them; the dashboard gallery groups them by category.
## The catalog
| Id | Name | Category | Trigger | Channels | Nodes |
| ---------------------------- | ------------------------------- | ---------- | --------------------------------- | -------------------- | ----- |
| `tpl_welcome_sms` | Welcome SMS | welcome | Incoming SMS (`event`) | SMS | 2 |
| `tpl_otp_verification` | OTP Verification | custom | Webhook | SMS, WhatsApp | 3 |
| `tpl_abandoned_cart` | Abandoned Cart Reminder | reminder | Schedule | WhatsApp | 3 |
| `tpl_customer_survey` | Customer Satisfaction Survey | survey | Ticket resolved webhook (`event`) | Email | 3 |
| `tpl_lead_nurture` | Lead Nurture Sequence | nurture | New-lead webhook (`event`) | SMS, Email | 5 |
| `tpl_escalation` | Support Escalation | escalation | Issue-created webhook | SMS | 4 |
| `tpl_password_reset` | Password Reset | auth | Webhook | Email, SMS | 4 |
| `tpl_troubleshooting_guided` | Guided Troubleshooting | support | Issue-reported event | WhatsApp, SMS | 5 |
| `tpl_lead_qualification` | Lead Qualification (BANT) | sales | New-lead webhook (`event`) | WhatsApp, Email | 5 |
| `tpl_order_status_inquiry` | Order Status Self-Service | ecommerce | Inbound message (`event`) | WhatsApp, SMS | 4 |
| `tpl_faq_deflection` | FAQ Deflection | support | Inbound message (`event`) | WhatsApp, SMS, Email | 4 |
| `tpl_appointment_reminder` | Appointment Reminder (24h + 1h) | reminder | Webhook | SMS, WhatsApp | 5 |
What each template does:
* **Welcome SMS** — the smallest useful flow: an incoming-message trigger straight into a welcome text. Good as a skeleton for any single-send automation.
* **OTP Verification** — webhook trigger, a one-second delay, then the code over SMS. Swap the placeholder `{{otp}}` variable for whatever your Verify workflow generates.
* **Abandoned Cart Reminder** — a schedule trigger with a cart-not-empty condition and a WhatsApp nudge. The schedule form keeps batch re-checks out of your webhook plumbing.
* **Customer Satisfaction Survey** — fires when a support ticket resolves, waits 24 hours, then emails the survey. The delay is what separates a survey people answer from one they delete.
* **Lead Nurture Sequence** — welcome SMS, wait 3 days, follow-up email, wait 4 more days. A seven-day cadence you extend or trim by editing the delay nodes.
* **Support Escalation** — after 30 minutes, if the issue is still open, text the on-call team. The condition checks a flat context key, so your ticket system must post `status` in the webhook body.
* **Password Reset** — branch on whether an email is on file: email the reset link, fall back to SMS otherwise. The `yes`/`no` handles on the condition carry both paths.
* **Guided Troubleshooting** — a two-step self-serve script over WhatsApp (restart, then factory reset) that hands off to a human agent when the scripted steps report back unresolved.
* **Lead Qualification (BANT)** — an AI agent runs the Budget/Authority/Need/Timeline conversation, a condition reads the resulting `lead_score`, and hot leads hand to a sales agent while cold leads drop into an email drip.
* **Order Status Self-Service** — an agent node looks the order up, and only the "not found" branch interrupts a human.
* **FAQ Deflection** — a knowledge-base-backed agent answers; low-confidence answers hand off. `knowledgeBaseIds` on the agent node points at your KB.
* **Appointment Reminder** — negative-amount delays relative to an `appointment_at` timestamp fire 24 hours before (confirm/reschedule over WhatsApp) and 1 hour before (final SMS ping).
Categories beyond the dashboard's six filter chips (welcome, reminder, survey, nurture, escalation, custom) — such as `auth`, `sales`, `support`, and `ecommerce` — still appear in the gallery and match the **All** filter and search.
## Clone from the dashboard
1. Open **Flows → Templates**. The gallery shows each template as a card with its category, channels, and a mini node preview.
2. Filter by the category chips (All, Welcome, Reminder, Survey, Nurture, Escalation, Custom) or search by name, description, or channel — the search matches all three.
3. Click **Use Template** on a card. The builder opens at `/flows/builder?template=`, loads the template's graph, and seeds it onto a new draft canvas.
4. Rename the flow, adjust the nodes (see [Customize](#customize-a-cloned-template)), then save and publish like any other flow.
The deep-link works outside the gallery too — `/flows/builder?template=tpl_welcome_sms` opens the builder with that template pre-loaded, so a runbook or an onboarding checklist can point teammates at a specific starter.
## Clone from the API
List the catalog:
```bash theme={null}
curl https://api.orbit.devotel.io/api/v1/flows/templates \
-H "X-API-Key: dv_live_sk_..."
```
The response is the standard `{ data, meta }` envelope — `data` is the array of templates, each with `id`, `name`, `description`, `trigger_type`, `category`, `channels`, `nodeCount`, and a full `definition` holding `nodes` and `edges`:
```json theme={null}
{
"data": [
{
"id": "tpl_welcome_sms",
"name": "Welcome SMS",
"description": "Send a welcome SMS when a new contact is created.",
"trigger_type": "event",
"category": "welcome",
"channels": ["SMS"],
"nodeCount": 2,
"definition": {
"nodes": [
{
"id": "trigger-1",
"type": "trigger",
"position": { "x": 50, "y": 200 },
"data": { "label": "Trigger", "triggerType": "Incoming SMS" }
},
{
"id": "sendSms-1",
"type": "sendSms",
"position": { "x": 350, "y": 200 },
"data": {
"label": "Send Welcome SMS",
"to": "{{phone}}",
"body": "Welcome to {{company}}!"
}
}
],
"edges": [
{
"id": "e-trigger-sms",
"source": "trigger-1",
"target": "sendSms-1",
"animated": true
}
]
}
}
],
"meta": { "request_id": "req_...", "timestamp": "2026-09-02T00:00:00.000Z" }
}
```
Copy one template's `definition` into a create call — carried as the body of [`POST /flows`](/api-reference/endpoints/flows), with your own `name` and the template's `trigger_type`:
```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/flows \
-H "X-API-Key: dv_live_sk_..." \
-H "Content-Type: application/json" \
-d '{
"name": "Welcome SMS — production",
"trigger_type": "event",
"definition": {
"nodes": [ ...the nodes array from tpl_welcome_sms... ],
"edges": [ ...the edges array from tpl_welcome_sms... ]
}
}'
```
The `position` coordinates in the template definitions are optional canvas hints — keep them (the builder lays the graph out the way the gallery preview shows) or drop them (the builder repositions nodes).
## Customize a cloned template
Templates are generic by design. Before publishing you always touch the same fields:
| Node type | Fields to swap |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `trigger` | The `data.triggerType` label is display-only, but confirm the flow's top-level `trigger_type` matches how you will actually start it (event, webhook, schedule). |
| `sendSms` / `sendWhatsapp` | `data.to` (`{{phone}}` resolves from the contact or trigger payload) and `data.body` — replace `{{company}}` and any other placeholders with your merge fields or literal brand text. |
| `sendEmail` | `data.to`, `data.subject`, `data.body` — plus connect a sender identity before the flow can send. |
| `delay` | `data.amount` and `data.unit` (`seconds`, `minutes`, `hours`, `days`). The appointment template additionally uses `data.relativeTo` with negative amounts to fire *before* a timestamp in the payload. |
| `condition` | `data.expression` — comparisons against flat context keys such as `status`, `lead_score`, or `cart_items`. |
| `agent` (handoff / AI steps) | `data.agentId` — replace the placeholder with an agent id from your tenant, and `data.knowledgeBaseIds` where the template references a knowledge base. |
Variables are flat keys: `{{phone}}`, `{{first_name}}`, `{{appointment_at}}`-style placeholders resolve against the merged trigger payload and contact record, and a missing key renders as an empty string. See the [Flows overview](/flows/overview) for the full trigger-payload table.
### Worked example: extend Welcome SMS into a two-touch series
The Welcome SMS template is one trigger and one send. Turn it into the classic welcome series by appending a wait and a second touch:
1. In the builder, with the cloned draft open, add a **Delay** node — amount `24`, unit `hours`.
2. Add a **Send Email** node after it — `to: {{email}}`, subject "Getting started", body with your onboarding link.
3. Re-wire the edges: `trigger-1 → sendSms-1 → delay (new) → sendEmail (new)`.
4. Test with the canvas simulator, then publish.
The same recipe spelled out node-by-node, including the API-defined JSON for this exact shape, is in [Build your first automation flow](/guides/build-first-flow).
## Limits and edge cases
* **Templates are read-only.** There is no update or delete endpoint for the catalog — `GET /flows/templates` is the only template route. Your clone is a separate flow; edit, version, and archive it without touching the template.
* **Cloning replaces the canvas you opened it on.** The builder's `?template=` path seeds the template graph over the current draft. If you have unsaved work in the builder, save it as a flow (or a version) before opening a template link.
* **Template ids are stable.** The `tpl_*` identifiers are fixed strings, safe to deep-link (`/flows/builder?template=tpl_faq_deflection`) and safe to hard-code in internal tooling that lists the catalog.
* **Placeholder variables ship in the graph.** Bodies reference context keys (`{{phone}}`, `{{otp}}`, `{{reset_link}}`, `{{oncall_phone}}`) and agent ids (`{{cs_agent_id}}`, `{{lead_qualifier_agent_id}}`) that resolve only if your trigger payload, contact record, and provisioned agents supply them. A placeholder with no backing value sends an empty string — run the simulator or Test mode before publishing.
* **Schedule and webhook templates need wiring.** A schedule-cloned flow still needs its `cron_expr`, and a webhook-cloned flow is only as good as the system posting to its URL — the template defines the graph, not the integration.
## When not to use a template
Templates are deliberately simple — linear paths with at most one branch. Reach past them when:
* the flow needs more than one condition chain, or multi-way branching (weighted A/B variants, split/merge parallelism);
* you are building a batch or audience-driven automation — that belongs to a Schedule trigger or campaign enrollment, neither of which a single-send template models;
* the design is fundamentally conversational (per-turn routing inside an AI agent) — that is a [conversation flow](/agents/conversation-flows), not a classic flow.
For copy-ready definitions of the more complex shapes — gated welcome series, reminder cadences with confirmation handling, support triage with AI routing — see the [flow recipes](/guides/flows-recipes).
## Next steps
* [Build your first automation flow](/guides/build-first-flow) — design, simulate, publish, and debug a flow end to end
* [Flows overview](/flows/overview) — trigger catalog, node taxonomy, and edge semantics
* [Flow Builder](/flows/builder) — the visual palette and every node's settings
* [Flow recipes](/guides/flows-recipes) — copy-ready definitions for the five most-built automations
* [Flow Executions](/flows/executions) — watch and debug runs once your cloned flow is live