GitHub user yangzhang75 created a discussion: Proposal: Workflow Templates — save a workflow as a reusable, parameterized template
### What it does In current Texera main, sharing a workflow means sharing the whole editable graph. If someone wants to reuse a colleague's pipeline with their own input file or a different threshold, they have to open the full canvas, find the right operator, and edit it by hand — easy to get wrong, and it exposes the whole pipeline to accidental edits. This proposal adds **Workflow Templates**. An author turns a workflow into a template and marks a few operator properties as *configurable*. Anyone with access then instantiates their own workflow by filling in a short form for just those properties — without touching, or even seeing, the rest of the graph. The result is a normal, runnable workflow they own. The case that motivated it: a lab publishes an analysis pipeline (e.g. a scGPT single-cell workflow), and end users just point it at their own dataset and hit run. <img width="1506" height="774" alt="Screenshot 2026-07-02 at 2 10 00 PM" src="https://github.com/user-attachments/assets/5f482445-5600-4aba-8987-fe1e17229518"; /> ```mermaid flowchart TD A["Author's workflow"] -->|"Make Template"| B["Opens in template mode"] B -->|"tick the configurable properties,<br/>then save"| C["Template<br/>(stored and shared like a workflow)"] C -->|"open → POST /build<br/>(idempotent: created once)"| D["Instantiated workflow<br/>(the user owns it)"] D --> E["Build page<br/>form on top, runnable preview below"] E -->|"Submit → POST /update<br/>(whitelisted keys only, new version)"| D E -->|"Run the preview"| F["Results"] ``` ### How it works **Authoring.** From any workflow, the author clicks **Make Template** and checks which operator properties should stay editable. The workflow is saved as a template in which everything is locked except those checked properties (stored per operator as a `configurableProperties` whitelist). It's stored and shared like a workflow — owner plus per-user access. **Instantiating.** Anyone with access builds their own workflow from the template. They can change only the checked properties; the rest of the graph is fixed and not editable. Values are applied server-side into the workflow content, restricted to the whitelist, and stored as raw JSON so typed values (like file references) round-trip losslessly. A new `Parameter` source operator lets a template expose typed inputs (key/value pairs, file references) as first-class graph inputs. ### The build page The "Build workflow from template" page shows the configurable-property form on top, and a live, **read-only but runnable** preview of the workflow below it — so a user can build, run, and see results on one page, without being able to edit the graph. <img width="1510" height="764" alt="Screenshot 2026-07-02 at 2 30 42 PM" src="https://github.com/user-attachments/assets/f91ba29d-c810-411c-b7a8-89633a3e9678"; /> <img width="1501" height="781" alt="Screenshot 2026-07-02 at 2 31 06 PM" src="https://github.com/user-attachments/assets/84135a50-904c-4898-b007-03f609de4bba"; /> ### Open questions 1. **One template → one workflow, or one → many?** Today a template maps to a single instantiated workflow (1-to-1), so any template change naturally flows to that workflow. Should we instead allow one template to produce multiple named instances — e.g. the same template run against different datasets, each saved separately? 2. **Should a template-built workflow be distinguished from a normal one?** It's meant to be run and re-parameterized, not freely edited. Is that distinction worth surfacing (a label, a separate section), or should it just look like any other workflow? 3. **Should template-built workflows appear on the main Workflows page at all**, or live only under Templates? 4. **When an admin disables the feature, what happens to workflows already built from templates?** The feature can be turned off at runtime from the admin settings (it hides the Templates tab and the "create template" button). Should the workflows those templates already produced be hidden too, or stay visible as normal, runnable workflows the user owns? Feedback welcome on the overall approach and on these four. GitHub link: https://github.com/apache/texera/discussions/6070 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
