Trickest lets people build security-automation workflows — chains of tools and scripts that scan infrastructure. Good ones are worth sharing: a Solution is a workflow an author publishes as a template so the rest of the account can reuse it instead of rebuilding it.

The moment you let people copy a template, you inherit a hard question: what is the relationship between the copy and its source over time? A recon template that was state-of-the-art last quarter is a liability today — tools change, false positives creep in, a step gets a critical fix. So the copy can’t just be a throwaway duplicate. But it also can’t be a mirror: the whole reason someone copies a template is to point it at their target and bolt on their steps.

I framed the decision around the one relationship everything hangs on — the link between source and copy — and weighed three models against a single test: can a user both keep receiving improvements and freely customize their copy?

The feature is a lifecycle, so I designed it as one. An author publishes; a user instantiates; both sides evolve; the user reconciles on their own terms.

1 · A linked, editable instance. Copying a template creates a normal workflow that carries a Based on badge back to its source. Editing it — here, adding a slack-notify step — never severs the link. The instance simply tracks which template version it last acknowledged.

2 · A reviewable update, like a diff. When the author ships a new version, the instance surfaces an amber “Update available” state. Opening it doesn’t overwrite anything — it opens a GitHub-style review: the copy on the left, the template on the right, every changed node called out. You can Take incoming or Keep current per node (and per input), then Apply only what you chose. This is the heart of the feature.

The diff speaks the workflow’s own language: added / removed / modified nodes up top, and for a changed node, a field-level breakdown — inputs, script, connections — with removed values in red and incoming values in green. Because customization and updates coexist, the default is “take everything,” but a user who tweaked a step can pin their version and still pull in the other four changes.

A template update has two halves. Editing a Solution isn’t only about workflow steps — an author (often an admin) also edits the reporting database schema: the tables and fields that runs write into. So an update can carry schema changes too, and those get their own review, because a database migration has stakes a node swap doesn’t: adding a field is safe, but removing one deletes its data.

Same diff grammar — added fields in green, removed in red, a type change flagged in amber — but the actions respect the data. Additions apply in one click; a removal is never automatic and a key field can’t be dropped at all; and because a live table can’t change a column’s type in place, a type change seeds a new table instead of silently rewriting the old one. The template’s version bump covers both halves, so one “Update available” can mean nodes changed, schema changed, or both.

3 · Unlink is an explicit, one-way door. Staying linked is the default, but a user who has diverged for good can detach. It’s deliberately heavy — a typed confirmation, destructive styling, and copy that says plainly it can’t be undone — so it never happens by accident.

Figures below are illustrative — the mechanism and direction are real; the exact numbers are reconstructed, not measured.

• Stale copies stopped accumulating — because updates are one reviewable click instead of a manual rebuild, roughly 3 in 4 instances stayed linked to their source rather than forking off, and a critical template fix reached every linked copy in minutes instead of a per-team migration.
• Customization stopped breaking sync — teams could point a template at their own target and add steps while still receiving upstream improvements; the “I edited it so I’m now on my own” dead-end disappeared.
• Publishing became worth it — with a governed distribution path, template authors had a reason to publish, seeding a shared library instead of a sprawl of near-identical private workflows.

What I’d still improve: conflict handling when both sides changed the same node — today the user resolves it manually node-by-node; a clearer three-way merge would help. And I’d surface updates more proactively (a digest when a template you depend on ships) rather than relying on the user to open the workflow and notice.