A network that works deserves to be kept
The first time a network produces a clean, useful result, it’s tempting to move on. The team got what they needed — onward.
But that first working version is exactly when versions and templates earn their keep. Save the version, name it well, and the next ten runs all benefit from what you just figured out. Save it as a template, and the rest of your team starts where you ended instead of starting from a blank page.
The biggest mistake teams make with networks is not saving them. A working network that lives only in one person's head will be re-invented every time someone else needs the same thing.
Versions, in plain language
A version is a snapshot of a network — its blocks, its instructions, its settings — at a point in time.
You’ll see versions whenever you open a network. Each version has:
- A number. Auto-incremented as you make changes.
- A timestamp. When the version was saved.
- A description. A short note from you about what changed.
- A “current” indicator. Which version is live and runs when the network is triggered.
When you edit a network, you’re editing the working copy. When you save, you can either update the current version or save as a new version.
When to save as a new version
A useful rule of thumb: save a new version whenever you’d want to be able to come back to the current state.
- You’re about to try a substantial change. Save first; revert if the new version is worse.
- You’re handing the network off to a teammate. A clean version with a descriptive note makes the handoff cleaner.
- The network has been stable for a while. Mark the stable state explicitly so future edits can be compared to it.
Naming a version
Version descriptions are a small thing that pays back forever. A few patterns:
"v3 — added the critique step before final draft""v5 — tightened the research instruction; output is shorter and sharper""v7 — replaced manual source list with feature list"
Future-you doesn’t need a paragraph. A sentence is enough.
Rolling back
When a new version is worse than the one before — too generic, too verbose, drifted in some way you didn’t expect — you can roll back to a previous version with one click.
The platform doesn’t delete the version you’re rolling away from. It moves it aside so you can come back and try again.
Rolling back is cheap. Use it freely.
Templates
A template is a network you save with the intent that other people will use it.
The difference from a regular saved network is mostly about presentation:
- A clear name that describes the deliverable, not the project.
- A one-paragraph description that tells someone whether to use it.
- A representative example. Inputs that produce a clear, illustrative result.
- A “who this is for” line. Who tends to find this template useful.
Templates show up in a discoverable area of your workspace. Anyone in the workspace can browse, run them, or use them as a starting point for their own work.
Templates aren't sacred. A template can be forked, modified, and saved as someone's own version. That's the point — a great template gives everyone a head start, not a finish line.
Starting from a template
When you click into the templates area, you see what your workspace has — and usually what the platform ships out of the box.
For each template you’ll see:
- What it produces. A clear example of the final deliverable.
- What it expects as input. What you’ll need to provide.
- How long a typical run takes.
- How many people have used it recently. Social proof on quality.
To run a template:
- Click Use template. You get a fresh copy.
- Fill in the inputs. Files, source references, parameters.
- Run. The template executes exactly as it was built.
To start from a template and customize:
- Click Customize. The template is copied into your own networks list.
- Edit blocks, instructions, sources. Your changes don’t affect the original template.
- Save when you’re done. Optionally save as a new template of your own.
Saving your own template
Once a network has produced reliable results across several runs — by you and ideally by someone else — it’s ready to become a template.
The screen asks for the things future users will need:
- A clear name. “Weekly customer success digest” beats “csbot.”
- A description. What this produces, for whom, when.
- Tags. Categories that help discovery —
weekly,customer-success,executive-report. - An example run. Pin one of your good runs as the example.
After saving, the template appears in your workspace’s template library.
Sharing scope
A template’s scope decides who can find it.
| Scope | Who sees it |
|---|---|
| Personal | Only you |
| Team | Members of your team |
| Workspace | Everyone in the workspace |
A common progression: build personally, share with the team once a teammate has run it successfully, promote to workspace once it has become a default for that kind of work.
Editing a network someone else built
Two patterns are common:
Forking
You make a copy of a teammate’s network. The copy is yours; you can edit freely. The original is untouched. This is the right default when you want to experiment without affecting the source.
Co-editing
The owner explicitly grants you edit access to the original. Both of you can change the same network; the platform tracks who changed what.
Most teams use forking by default and co-editing for a few high-value shared networks.
How versions and templates work together
A template is a published version of a network. When you save a network as a template, you’re effectively saying “this version is good enough to share.” Future edits to your private network don’t change the template — you’d save again to update the template.
This means:
- You can keep iterating on a network privately while a stable template serves the team.
- When you’re ready to promote a new version of the template, you do it explicitly.
- Users running the template always get the version you promoted, not your latest in-progress edits.
A few patterns that work
Save a working version before you experiment
Every time you’re about to make a meaningful change, save first. The 30 seconds of versioning prevents the 30 minutes of “wait, what did the working version look like?”
Treat templates as products
A template that lives in a workspace library is a small product. It has users. Treat it like one — clear name, clear description, example, and a way to give feedback.
Promote templates with a one-paragraph announcement
When a template is ready for the team, write a short message: what it produces, who should use it, when to use it instead of something else. The template’s value rises with awareness.
Retire stale templates
Templates that haven’t been used in a quarter and haven’t been updated in two are usually templates someone moved on from. Archive them — a clean library is a useful one.
A great template needs a great description. The number-one reason team templates go unused is unclear descriptions. If a new teammate can't tell from the description whether the template is for them, they won't try it.
Where to go next
- Building workflows — turn a real team process into a saved network.
- Runs and monitoring — what to look at when comparing versions.
- Governance and admin — workspace-level policies on sharing and publishing.
- Node types — the blocks you’re versioning.