ELSA Workflow Templates → Instances
A template captures the shape of an automation — say, a research workflow. The admin marks which nodes should ask a question before anyone uses it. When a user clones it, those questions become a short wizard: their data source, their output format, their schedule. The engine underneath is shared; only the edges are personal.
one template → many personalized instances
Why this, why now
The workflow editor already lets a power user build a research automation end to end. The problem is what happens next: everyone else needs the same automation, wired to their accounts, delivered their way, on their cadence.
Each person recreates the same graph, or blindly copies one and edits nodes they don't fully understand. Small mistakes break the run.
→ Template encodes the correct shape onceCopying a workflow exposes every node — prompts, bindings, ports. Users change the wrong thing and can't tell why the agent stopped returning results.
→ Only flagged nodes are editable, as guided questionsThe cadence, output, and data source are baked in. Changing them means opening the editor — a place most users shouldn't need to go.
→ A 4-question wizard, no canvas requiredThe model
The ELSA workflow definition stays the single source of truth — same as it is today. We add one layer on top: a per-node requiresUserInput flag the admin sets, and a wizard the user answers to produce their own instance.
Step 2 · The user
The user clicks Create instance on the template. Before a workflow is cloned for them, they answer only the flagged questions. Everything else is inherited from the template. Try it — the summary on the right assembles their personal instance as they go.
Tip: go back to Author & flag and toggle nodes — this wizard rebuilds from whatever the admin flags.
Grounded in what AMP already has
Almost every piece exists today. The template/instance layer reuses the current ELSA + React Flow stack rather than replacing it.
Nothing changes about how workflows persist. A template is just a workflow definition marked isTemplate: true; an instance is a clone produced by CopyAIAutomationWorkflow with the user's answers written into node inputs.
A per-activity requiresUserInput custom property (plus a prompt label). The editor already stores per-node config; this is one more field the admin sets in the inspector.
The wizard's “data source” maps to the StarterInput / ElsaServer.Activities.Accounts node (EntityType, field, filters). Output maps to the Output-binding node — custom field, PDF, or an MCP send.
“Send email” routes through an MCP server (Gmail or Outlook) at user scope, using the same OAuth Connect flow AMP already has for MCP. No new integration surface.
The cadence question writes a cron expression onto the workflow's timer trigger — 0 */3 * * * for every three hours, 0 15 * * * for daily at 3pm. Standard ELSA scheduling.
The Research Agent still calls the aimm-python orchestrator. Users never reconfigure it — it's the locked, shared core. That's the safety guarantee that makes self-serve cloning viable.
Getting there
Add requiresUserInput and a question label to the node inspector. Purely additive — existing workflows keep running.
Mark definitions as templates; surface them in a “Start from template” view on the AI Automation dashboard.
Generate the question flow from flagged nodes, write answers into a clone, and schedule it. This demo is that wizard.
Author the first real template with the Research Agent, prove the loop end to end, then open template authoring to more admins.