Triggering Flows
Flows can be triggered in 7 ways.
On-demand triggers:
- Auto-generated UIs
- Customized UIs with the App Editor
- Schedule the Execution of a Flow
- Trigger Flows from CLI (Command Line Interface)
- Trigger a Flow from another Flow
Triggers from external events:
- Scheduling + Trigger Scripts
- Trigger Flows from Webhooks, including from Slack or Emails
On-demand Triggers
Auto-generated UIs
Windmill automatically generates user interfaces (UIs) for scripts and flows based on their parameters.
By analyzing the main function parameters, it creates an input specification in the JSON Schema format, which is then used to render the UI. Users do not need to interact with the JSON Schema directly, as Windmill simplifies the process and allows for optional UI customization.
This feature is also usable directly in the script editor to test a flow in the making:
More details on our page dedicated to Auto-generated UIs.
Customized UIs with the App Editor
Windmill embeds a WYSIWYG app editor. It allows you to build your own UI with drag-and-drop components and to connect your data to scripts and flows in minutes.
More details on our page dedicated to Windmill App Editor.
Schedule the Execution of a Flow
Windmill allows you to schedule scripts using a user-friendly interface and control panels, similar to cron but with more features.
You can create schedules by specifying a script or flow, its arguments, and a CRON expression to control the execution frequency, ensuring that your tasks run automatically at the desired intervals.
More details on our page dedicated to Scheduling jobs.
Trigger Flows from CLI (Command Line Interface)
The wmill cli allows you to interact with Windmill instances right from your terminal.
More details on our pages dedicated to CLI.
Trigger a Flow from another Flow
Windmill supports inner flows. This allows you to call a flow from another workflow.
Triggers from External Events
Scheduling + Trigger Scripts
A particular use case of schedules are Trigger Scripts. Their purpose is to pull data from an external source and return all of the new items since the last run.
This type of Flow is meant to be scheduled regularly to reduce latency when reacting to new events. It will trigger the rest of the Flow once per new item that is returned. If there are no new items, the flow will be skipped.
More details on our page dedicated to Trigger Scripts and examples on the Hub.
Trigger Flows from Webhooks
In Windmill, webhooks are autogenerated for each Script and Flow, providing either asynchronous or synchronous execution modes.
These webhooks accept incoming HTTP requests, allowing users to easily trigger their Windmill scripts/flows from external services by simply sending a POST request to the appropriate authentified webhook URL (requires passing a token as Bearer or query arg). Their purpose is to have the flow run when it receives an input from its associated webhook.
Each script and flow have their own webhooks on Windmill ...
... which you can trigger from service providers, like Github here:
More details on our page dedicated to Webhooks.
Webhooks: Trigger Flows from Slack
One use case of webhooks is building a Slackbot with Windmill.
Windmill uses Slack to trigger scripts and flows by establishing Slackbots and creating specific commands. By connecting Slack with Windmill, parsing incoming Slack commands, and leveraging Windmill workflows, operational teams can trigger complex automations directly from Slack.
Webhooks: Trigger Flows from Emails
One use case of webhooks is triggering scripts via inbound emails using Mailchimp.
Windmill leverages Mailchimp Mandrill's capabilities to initiate scripts and flows via email-triggered events. By parsing inbound emails and routing the content to Windmill through webhooks, scripts or flows are activated, enabling automation based on email content or just their arrival.