Skip to main content

​
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:
  • 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 and, for approval states, the 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: 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.

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