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

# What a flow template is, and how cloning detaches it

> The flow-template artifact — a frozen, read-only starter graph versus a saved flow — the categories the catalog uses, what cloning copies into a draft, trigger-type semantics in a template, platform versioning versus clone drift, and where templates sit in the flow execution model.

# Flow templates model and clone semantics

A **flow template** is a frozen, read-only starter graph the platform ships: an `id` in the `tpl_*` namespace, a `name`, a `description`, a `category`, a `trigger_type`, the channels it touches, a `nodeCount`, and a full React-Flow `definition` — `nodes` with positions plus `edges`. The dashboard's **Flows → Templates** gallery and the flow builder's **New Flow** dialog both read from the same catalog. This page models that artifact and the clone semantics a cloned copy inherits. The field-by-field clone steps belong to the [Flow templates catalog](/guides/flow-templates-catalog) guide; this is the model page that guide links to for "how clones relate to templates."

## A template versus a saved flow

Three artifacts share the word "template" — keep them apart:

* **A flow template** (this page) is a platform-shipped, read-only **graph**: nodes, edges, and one declared `trigger_type`. It is a starting shape for an automation, not an automation itself.
* **A saved flow** is mutable and tenant-owned: your row, your draft `definition`, your `draft / published / archived` lifecycle, your version snapshots. Cloning a template produces one of these.
* **An outbound message template** is copy, not a graph — a reusable message body with variables and (for WhatsApp) provider-side approval. Different artifact, different surface: see the [outbound templates guide](/guides/outbound-templates) and, for approval states, the [template lifecycle](/concepts/template-lifecycle) concept page.

Once cloned, everything you own is the second kind. The first kind stays a platform asset; the third kind is unrelated beyond the name.

## The categories the catalog uses

Every template carries one `category` value. Six of them back the dashboard gallery's filter chips:

| Category     | What it groups                                         |
| ------------ | ------------------------------------------------------ |
| `welcome`    | First-touch and onboarding starters                    |
| `reminder`   | Appointment, cart, and follow-up nudges                |
| `survey`     | Post-interaction feedback flows                        |
| `nurture`    | Multi-day drip sequences                               |
| `escalation` | Timeout-and-alert support paths                        |
| `custom`     | Everything else — the catalog's OTP starter lives here |

The catalog's twelve templates also carry richer values — `auth`, `sales`, `support`, `ecommerce`. The dashboard's six chips plus **All** are the filter surface; templates outside the six match the **All** filter and the name/description/channel search. The per-template categorization table is in the [catalog guide](/guides/flow-templates-catalog).

## What cloning copies

Cloning copies exactly one thing: the template's React-Flow `definition` — the `nodes` array (ids, types, canvas `position` hints, and `data` including `{{...}}` variable placeholders) and the `edges` array (source, target, handle routing, `animated` display flags). The copy lands as a new draft flow under your tenant. The mechanics:

* **The template is never mutated.** Every tenant clones the same frozen graph; there is no write surface against the catalog.
* **No provenance link is kept.** After the clone, the draft has no `template_id` back-reference. It is an ordinary flow: edit it, snapshot it, publish it, archive it — nothing reports back to the `tpl_*` it started from.
* **The canvas positions come along.** Keep the `position` hints to get the gallery's layout, or override them — they are display hints, not routing data.

The implication: there is no "update this clone to the latest template" operation, because there is no link to update through. If a template improves in a later platform version, a fresh clone gets the improvement; existing clones are unchanged and stay fully yours.

## Trigger types in templates

Templates ship with event, webhook, and schedule `trigger_type` values — a subset of the full platform trigger catalog. The declared type is a header value and a canvas hint, not a wired integration. After cloning, the trigger still has to be attached to live traffic the same way any hand-built flow is:

* An `event`-triggered template needs inbound routing rules or a platform event to fire on — the "Where Flows Fire" entry points in the [Flows overview](/flows/overview#where-flows-fire).
* A `webhook`-triggered template needs the external system posting to the flow's webhook URL.
* A `schedule`-triggered template needs its `cron_expr` (and optional `cron_tz`) set.

Until that wiring exists, a cloned template is a shape that never fires — run the simulator or Test mode against it before publishing.

## Versioning and drift

Templates ship with the platform version — they are part of the product, not of your tenant graph. The only read surface is `GET /api/v1/flows/templates` (under the flow read rate limit of 60 requests per minute). There is no create, update, or delete on the catalog, and no per-template versioning exposed: when the platform upgrades the catalog, the next clone picks up the new definitions.

Your cloned flows version independently through the usual draft/publish machinery — immutable snapshots on publish, `GET /flows/:id/versions` history, and snapshot restore. Since cloning severs provenance, clone-side drift is total: your copy and the template each evolve on their own schedule, and neither affects the other.

## Where templates sit in the execution model

A template is a definition with a delivery mechanism. Once cloned and published, it is indistinguishable from a hand-built graph: the same executor walks the same nodes, parks the same `waiting` rows on long delays, and finalizes the same terminal statuses. Clone-time simplification is about authoring, and it has no runtime cost or benefit. The lifecycle a cloned definition enters is the [flow execution model](/concepts/flow-execution-model); everything this page describes ends at publish, and everything that page describes begins there.