Templates

A template is a pre-built workflow published by a node package. Installing one gives you a paused copy in your own workflows, with the graph, the variables and the triggers already in place. If your job is a file-shaped integration, start here rather than on an empty canvas.

Find them under Integration Studio → Templates.

What ships today

Eight templates ship with the platform's own node package, covering the file-shaped integrations that come up most.

The four Direct templates are the shortest path from a file on your desk to data in the platform, or back out again: press Run, drop the file, read the import report in the run result. No profile to set up first.

The three SFTP templates are the unattended shape: a supplier or an ERP drops files in an inbox folder, a schedule picks each one up, and processed files move to an archive folder while failures move to a failed folder — so nothing disappears silently.

Products CSV import (webhook) is the same import driven by an external system instead of a clock. The webhook address appears on the trigger after you install it; see Webhook triggers.

Reading a template before you install it

A template's page shows the steps in run order, what starts it, the variables you can tune, and a readiness check before you install anything. The check counts two things against your tenant:

• Credentials the flow's steps need, per credential type — either how many you have that would fit, or that you have to connect one first.
• Secrets the flow references by key — each one either set or missing.

Not ready means the page says what is missing rather than claiming readiness. Ready means it says so.

Installing one

Installing is deliberately not gated on the readiness check: Use template creates a paused copy in your workflows, with whatever credentials you chose pre-wired and the rest left to finish in the editor. You name the copy, and nothing runs until you activate it.

Nothing about the copy is linked back to the template. It is your workflow from that moment: editing it does not affect the template, and a new version of the template does not reach the copy.

What you adapt afterwards

Four things, in the order they usually bite:

1. Variables. This is where a template is meant to be adjusted — folders, target entity, key columns, the base URL. The BMECAT template has nine of them, and adjusting them is the entire configuration step. Give every variable a value; an empty one resolves to nothing, silently. See Variables.
2. Credentials. Any credential field the install did not pre-wire has to be bound in the editor. A credential that tests fine but lacks the scope the node needs fails at the step, not at the test — see Credentials.
3. The trigger. A schedule ships with a cron expression and a timezone that suit a generic customer, not yours. A webhook trigger's address is issued per trigger, so the copy has its own.
4. The import or export profile. Templates that provision a profile create it on the first run and then leave your edits alone: profile changes you make afterwards always win. The BMECAT profile maps products only to begin with — extend it once you know which entities of your schema the feed should reach.

Then test it: run it by hand once, read the run, and only activate it when the run says what you expected. See Runs.

One honest limit

Templates that export do a full export of the entity on every run. There is no incremental delta export in a shipped template today, so if you need one, compare against the previous export yourself with Compare Datasets — see the node catalog.

Where to go next

• Import a BMECAT product catalog — one template installed end to end, screenshot by screenshot.
• The workflow document — what you are looking at once the copy is in your editor.
• Package manifest — how a node package ships templates of its own.