Importing and exporting your automation

A bundle is a single file holding a site's automation — its datastore tables, forms, saved views, charts, and workflows — along with the connections between them.

Use one to back up your work, copy a setup into another site, share it with someone, or start from a ready-made template.

Find it in a site dashboard under Import / Export.

Starting from a template

The top of the page lists the built-in templates. Pick one and its bundle is loaded into the editor below, ready to check and import. Nothing is created until you press Import.

Trading starter brings a complete share-trading setup — see Market data & brokerage for how to finish setting it up, and read that article before enabling anything from it.

Importing

You can either paste a bundle into the editor or pick a .json file. Pasting is usually easier — a bundle often arrives as text in a message or a document.

Always press Check first. It runs the entire import without creating anything and shows you exactly what would happen: what would be created, what already exists and would be reused, and anything that would fail. If something is wrong, you find out before your site changes rather than after.

Then press Import.

What happens to things that already exist

• A table with the same name is reused if its fields match what the bundle expects. Your existing rows are left alone, and no starter data is added to it.
• A view or chart with the same name is reused as-is.
• A form or workflow with the same name makes the import stop. These carry behavior that other parts of the bundle depend on, so quietly using the existing one could connect the bundle's workflow to something that behaves differently. Rename either one and import again.
• A page at the same address makes the import stop too. A page is something you wrote; the import will neither replace it nor quietly skip it and leave you with a bundle whose screens aren't there.

If anything fails partway through, everything the import had already created is removed again. Things that were reused are left exactly as they were — they were yours before the import ran.

After importing

Imported workflows are always turned off, even if they were on in the bundle. Importing something is not the same as agreeing to run it, and a scheduled workflow could otherwise start working the moment it lands.

So the last step is always yours. The Next steps checklist on this page lists exactly what a particular bundle needs, in order, each item a single click — then open each imported workflow, read what it does, and turn it on.

Accounts a bundle needs

A bundle never contains passwords or API keys — nobody should be sharing those, and yours wouldn't work in someone else's site anyway.

A well-made bundle handles this with a variable. Instead of every workflow step naming a brokerage account directly, all of them read one setting — say tradingAccount — and you fill that setting in once. The checklist walks you through it:

1. Save the account under Account → Connectors, if you don't already have one.
2. Set the variable under Automation → Variables, picking the account you just saved.
3. Enable the workflows.

Changing which account everything uses later is then a single edit in one place, rather than opening every workflow and every step.

If a bundle you were given doesn't do this, its workflow steps arrive with no account selected and will refuse to run. You'll see a needs an account badge next to those workflows in the Workflows list; open each one and pick an account on the steps that need it. (If you're writing a bundle yourself, use a variable — the Export tab warns you if you don't.)

Replacing what's already here

Importing a template into a site that already has content usually means "replace what's here". Tick Start fresh and the import deletes this site's existing content first.

This deletes your variables, datastore tables (and everything in them), forms and their submissions, views, charts, pages and workflows. It leaves your members, who can access what, your domain and certificates, and any apps you've bought.

Because it can't be undone, it asks a lot of you before it does it:

• Press Check first — it tells you exactly how much of each thing would be deleted.
• You have to type the site's name to turn the button on.
• A backup file downloads to your computer before anything is deleted. Keep it.
• Afterwards there's a Restore it button that puts everything back.

It isn't offered on the cluster's front-door site, and it won't run while any workflow is still running — wait for those to finish first.

Pages in a bundle

A bundle can also carry pages — screens for the data and workflows it installs. Unlike workflows, a page can arrive already published: a page does nothing until someone visits it.

A page in a bundle can be public or signed-in-only. It can't be limited to one particular person or team, because those name someone in your site and mean nothing in anyone else's; a bundle exported from a page like that becomes signed-in-only.

If your site has no pages at all yet, importing one creates a blank home page to hold it, left unpublished. Publishing that home page is what switches your domain over to showing your pages, so that stays your decision.

Exporting

Give the bundle a name and press Download bundle. You get a .json file.

Two things are deliberately left out:

• Your data. Table rows are not included unless you tick "Include table rows as starter data". Sharing your automation should not quietly hand over your records.
• Your credentials. Connector references are always removed. Nobody importing your bundle gets access to your accounts, and you will need to reconnect yours if you import it somewhere else.

Everything else — table structures, form definitions, view queries, chart settings, and complete workflows — travels with it.

A note on names

The connections inside a bundle are stored by name rather than by internal id, which is what lets the same bundle work in any site. If you rename a table in a bundle by hand, rename it everywhere it is mentioned, or the import will tell you a reference points at something that does not exist.

Writing a bundle yourself

A bundle is plain JSON, so you can write one by hand or have someone write one for you rather than building everything through the interface. This is worth doing when you want the same setup in several sites, or when it is easier to describe what you want than to click it together.

Two things make that practical:

• The repository contains a full authoring reference at docs/BUNDLE-AUTHORING.md, along with a generated catalogue of every workflow node and its exact settings. Anyone writing a bundle should start there rather than guessing.
• A checker script, scripts/validate-bundle.py, catches structural mistakes before you ever paste anything in.

Whatever you are handed, treat the Check button as the real gate. It runs the whole import against your actual site — including the things a file cannot know, like whether a table of that name already exists — and tells you precisely what would happen before anything is created.