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

  1. Explain when you’d add an approval step to a flow and why.
  2. Describe what a “resource” is in Windmill and why scripts shouldn’t hardcode credentials instead.
  3. Write a sentence justifying building a Windmill app rather than a standalone internal tool for a simple request-approval process.