English for Windmill Workflow Developers
Learn the English vocabulary for Windmill: flows, scripts as building blocks, approval steps, and turning internal scripts into shareable apps.
Windmill discussions borrow terms from workflow orchestration but apply them to a lighter, script-first tool, so a developer used to heavier platforms like Airflow needs to recalibrate what words like “flow” and “step” mean in this context.
Key Vocabulary
Flow — a Windmill workflow composed of ordered steps, each of which can be a script, another flow, or a branching condition, defined visually or as YAML. “Wrap the ingestion and the notification script into a single flow so retries apply to the whole sequence, not just one step.”
Script as a building block — Windmill’s model where any script in a supported language becomes a reusable, independently callable unit that flows can chain together. “Don’t duplicate the Slack-notification logic — it’s already a script; just reference it as a building block in the new flow.”
Approval step — a flow step that pauses execution and waits for a human to approve or reject before continuing, often used for anything touching production data. “Add an approval step before the delete-records action — nobody should be able to run that unattended.”
Resource — a stored, reusable connection configuration (database credentials, API tokens) that scripts and flows reference by name instead of hardcoding secrets.
“Reference the prod-db resource in the script instead of pasting the connection string — it’s rotated centrally and audited.”
Windmill app — a lightweight internal UI, built from Windmill components, that triggers scripts or flows and displays their output without a separate frontend deployment. “We don’t need a whole internal tool for this — a Windmill app with a form and a button covers the whole request.”
Common Phrases
- “Should this be one flow with an approval step, or two separate flows with a manual handoff?”
- “Is this script already a building block somewhere, or are we duplicating logic?”
- “Which resource is this script pulling credentials from, and who has access to rotate it?”
- “Do we need a full app for this, or is a scheduled flow enough?”
- “Where does this flow retry from if step three fails — the whole flow, or just that step?”
Example Sentences
Debugging a failed run: “The flow failed on the approval step because the resource token had expired — the script itself never even ran.”
Explaining an architecture choice: “We built this as a Windmill flow instead of a cron job on a server because we get retries, an approval step, and a run history for free.”
Reviewing a pull request: “Extract this into its own script — it’s useful outside this flow, and treating it as a separate building block means we can test it in isolation.”
Professional Tips
- Say flow, not “pipeline” or “workflow,” when discussing Windmill specifically — it maps directly to a concept in the tool’s UI and API.
- Call out resources by name in reviews to make credential provenance explicit rather than assuming reviewers know where a token comes from.
- Recommend an approval step proactively for anything destructive — it signals you’re thinking about production safety, not just automation speed.
- Distinguish a Windmill app from “the frontend” — it’s a specific lightweight construct, not a general web application.
Practice Exercise
- Explain when you’d add an approval step to a flow and why.
- Describe what a “resource” is in Windmill and why scripts shouldn’t hardcode credentials instead.
- Write a sentence justifying building a Windmill app rather than a standalone internal tool for a simple request-approval process.