​

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 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: Once cloned, everything you own is the second kind. The first kind stays a platform asset; the third kind is unrelated beyond the name. For the third kind, see the outbound templates guide and the template lifecycle concept page.

​

The categories the catalog uses

Every template carries one category value. Six of them back the dashboard gallery’s filter chips: 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 twelve templates, mapped to their use cases

Pick a template by its use case first, not by its category chip. Each template ships with the trigger it expects wired after cloning — see trigger types below. The catalog guide walks the cloning flow for each of these; this table is the decision aid — the model page for “which template do I want.”

​

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.
• 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; everything this page describes ends at publish, and everything that page describes begins there.