FlowDrop 2.2 Moves Execution Confirmation Into Site Governance
Version 2.2.0 of the FlowDrop module changes how Drupal sites govern operator confirmation before workflow nodes execute. According to the release notes, the update reworks the confirmation policy model introduced in version 2.1.0 earlier on 9 August 2026. Drupal.org records 2.1.0 at 15:52 UTC and 2.2.0 at 20:12 UTC, placing the releases four hours and 20 minutes apart.
The central change separates approval policy from processor behaviour. Version 2.1.0 could derive whether confirmation was required from an executor plugin's declaration of side effects, with node types offering Always, Never, or Default settings. Version 2.2.0 replaces that tri-state with a confirmation governance map that defines the site's policy and what controls workflow authors or runtime inputs are allowed to exercise. The release notes explain that a site may require operator approval for organisational or business reasons even when processor code does not declare side effects.
FlowDrop 2.1.0 introduced the confirmation gate for nodes scheduled through a workflow graph as well as nodes invoked as tools by an agent. An execution can pause for operator approval, proceed after approval, or send a declined request through the node's normal error handling. Version 2.2.0 retains that mechanism but moves control over the default policy and permitted overrides to site administrators. Runtime input, including model-filled tool arguments, can be allowed to require approval, but it cannot waive an approval requirement.
The release also hardens how confirmation requests are stored and consumed. The notes describe a race condition in which one approval could authorise two concurrent executions; consent consumption now runs atomically under a lock. Confirmation derivation now fails closed when an executor plugin cannot be resolved, while secrets substituted into parameters are redacted from persisted approval prompts. Pending gate questions also expire after 72 hours by default, background executions receive approval ownership based on the run initiator when available, and confirmation policy has a dedicated administrative permission.
For sites upgrading from earlier 2.x releases, the notes describe the 2.2.0 update as non-breaking. Running drush updatedb migrates stored requires_confirmation values into the new governance map while preserving previously unattended workflows and existing waivers. Sites that track configuration in code are advised to re-export it afterwards because the legacy confirmation key is replaced by the new map. The release does not change FlowDrop's public @api surface, with the classes added in 2.2.0 marked internal.


