Templates

Templates provide preview starting points for common app relationships and workflow shapes. They can accelerate drafting by supplying a sample description and ordered steps, but they do not activate an automation. Use a template when its intended outcome closely matches your own, then review every app, input, route, and gate before running a simulation.

Template library

The template library is derived from app-pair data, sample prompts, and available capability information. Its inventory can change when the production source, fixture fallback, or capability data changes. Do not rely on a fixed template count or assume that every visible template is available in every environment.

Template cards can carry states such as Draft, Preview, or Activation locked. Those labels describe the current product boundary. A template may be complete enough to open in the builder even when its app route is only suggested, its connection is missing, or its execution path is disabled.

Browse by the outcome you want rather than by a promise of live integration. The template should identify the participating apps and the basic sequence. If its description requires features that the current product does not verify—such as general branching, schedules, live webhooks, or MCP calls—treat those parts as design intent only.

Choose a template

Select a template whose trigger and destination action match your goal. Small differences in app role matter: a template that reads from an app and writes to another is not interchangeable with the reverse direction.

Before opening it, check:

• whether the source and destination apps are the ones you intend to use;
• whether the route status is suggested, bridge-based, API/MCP possible, native, or coming soon;
• whether the card is explicitly preview-only or activation locked;
• whether a required credential or approval is already identified.

“Draft from template” opens the builder. The resulting workflow is a new draft derived from the template; it is not a running instance and does not inherit a live connection merely because the template names one.

Customize steps

Edit the workflow description or supported builder inputs so the draft reflects your data and action. Remove steps that do not serve the intended outcome, and make required mappings explicit. Keep the sequence linear when the source does not verify a condition editor or general branching model.

Review each app action as though it were newly detected. Template content can be useful as a prompt, but current route and connection states must govern the result. Replace illustrative account names, sample fields, and seeded values with non-secret configuration relevant to your environment.

If customization introduces a new app, the builder may need to redetect the relationship and choose another route. If no route is represented, keep the action as an unresolved design note rather than inventing a connector.

Validate

Validation checks whether the customized definition is coherent enough to simulate. Confirm that the step order, input sources, route readiness, connection requirements, and approval gates all agree.

A validation result can expose:

• an app that is absent from the loaded directory;
• a route that remains suggested_only or coming_soon;
• a missing or expired credential;
• a generated connector that cannot execute;
• an approval packet that would be needed for the proposed action;
• a definition error introduced during customization.

Correct the named problem and validate again. Do not remove a gate simply to obtain a passed state. The validation result applies to the draft and current environment; it is not a certification that a future external request will succeed.

Simulation

Run a simulation after the customized draft passes its available checks. The simulation produces a preview of step evaluation and route behavior without contacting external apps or writing data.

Compare the simulation result with the template’s original intent. If the new inputs changed the route or introduced a connection requirement, the result should make that difference visible. Bridge dry-run information can explain how a candidate route would behave, but it remains a dry run.

The strongest supported outcome is a draft with a coherent definition, an understandable route, resolved preview prerequisites, and a simulation record. Activation remains locked. Approval packets remain previews, and Workflow Agent history remains local-safe or fixture-backed.

Limitations

Templates cannot establish live support for an app pair. They do not guarantee provider availability, credential acceptance, schedule execution, webhook delivery, MCP calls, or durable history. A template may outlast the route data that originally informed it, which is why current readiness must be checked again in the builder.

Avoid using templates as policy. Sensitive actions still require the appropriate gate, and a sample approval or connection should not be copied as though it were valid in another environment. When the template relies on an unsupported feature, shorten the workflow to the supported draft path and record the unavailable portion separately.

Templates are best used as editable design aids: they reduce initial drafting effort while leaving every operational decision visible for review.

Template provenance

A template can be derived from app-pair data, a sample prompt, or capability information. That provenance affects how much confidence to place in it. A template built from a fixture is suitable for demonstrating the builder but should not be described as a production integration recipe. A template based on a represented app pair still needs current route and connection review.

Do not preserve seeded account names, example identifiers, or sample payloads as if they belonged to the user. Replace illustrative values with safe placeholders that reflect the current draft.

When not to use a template

Start from a blank description when the template’s trigger, action direction, or app pair differs materially from the desired workflow. Forcing a template to fit can leave hidden steps or mappings that are difficult to detect. It is also safer to avoid a template that depends on schedules, webhook ingress, MCP calls, or branching that the current product does not verify.

Comparing template revisions

After customization, compare the app list, step order, and route status with the original. A changed destination can select a different bridge or create a new setup requirement. Keep the resulting draft’s status rather than the template card’s status. The template is only the starting point; the builder and current loader determine the preview outcome.

Template status and route status

The template’s visible status describes the starting point, while each generated step receives current route and connection analysis. A Preview template can produce a draft with a coming-soon route. A Draft template can still simulate when the required path is available in dry-run form. Read the resulting builder state instead of carrying the card label forward as the final result.

Input placeholders

Sample prompts often contain placeholders for records, messages, or destinations. Replace them with descriptive non-secret values. If a template assumes a field that the current source app does not expose in the draft, mark the mapping unresolved rather than inventing a field name.

Template maintenance

Dynamic source data can make a template stale. A renamed app, changed pairing, or connector state can affect the route. Revalidation is therefore required every time the template is used, even when an earlier simulation passed.

Useful completion criteria

A template-based workflow is ready for handoff when the customized description matches the intended outcome, all steps have identifiable inputs, route and connection gaps are explicit, approval needs are visible, and the simulation result is understandable. It is not ready for live activation because that path remains locked.

Template handoff note

When sharing a template-derived draft, state which parts came from the template and which were customized. This makes it easier to identify stale assumptions and prevents a reviewer from treating sample values as environment configuration. Include the current route and simulation status, not only the template title.

Avoid template chaining

Do not combine several templates and assume their routes, inputs, and gates compose automatically. Build one coherent draft and review each added app relationship through the directory and integrations surfaces.

Template ownership

The source does not verify private templates, shared-template permissions, publishing, or version history. Treat the library as a current preview catalog. Avoid stating that a customized draft can be saved back as a reusable organizational template.

Archive assumptions outside the template

Keep unsupported schedule, webhook, or branching requirements in review notes so the template itself remains an honest preview definition.