v0.93.7
October 3, 2026
Transitions protected while a phase is still being entered, safe retries for integrations, a warning on overly generic AI prompts, scheduled items re-checked against a new version — plus more robust inbound webhooks, more reliable email sending, and more resilient map import on repeated attempts: an item that is still completing entry into a phase can no longer be moved by a second attempt that lands at the same instant (REST, extension and MCP all get a retryable error, with how long to wait); REST and MCP assistants can now declare which phase they think they're starting from, so a retry after an uncertain network outcome never risks moving the same item twice; an AI task with an empty prompt or no placeholder at all now gets a warning — in the task panel and at flow publish — that calls attention to what gets sent to the model; a scheduled item that rebinds to a newly published version is now re-checked against the creation gates (work-in-progress limit, uniqueness, data, title): if the new version doesn't pass them, the item stays on its original version instead of starting under a configuration that wouldn't have passed those checks. The inbound webhook bandwidth budget now follows the bytes actually received, not the sender's declared header, and an early rejection closes the connection right away; SMTP sending now retries the other addresses of a dual-stack server when the first one refuses the connection; importing a Process Map with a requestId now holds up better when an attempt gets stuck for too long or hits an error right at the end.
-
Security
Inbound webhook budget now follows real bytes, not the declared header
The per-organization bandwidth cap on inbound webhooks used to count the sender's declared Content-Length, even when the body never actually arrived: anyone who knew the address of an active webhook could exhaust the whole organization's budget with a few dozen header-only requests, without ever sending a real payload. The count now always follows the bytes actually received. Early rejection responses for webhooks (unrecognized address or exhausted budget) also close the connection right away instead of leaving it open.
-
Security
SMTP sending now also tries the other addresses of a dual-stack server
When the configured SMTP server (the tenant's own, or the installation's) resolves to more than one IP address, sending used to try connecting only to the first one: if that address refused the connection, the email failed to go out even when another address for the same server would have worked. Now, with the same security validation of the destination address, a connection refusal makes it retry the other available addresses before reporting the send as failed; a later error (for example, wrong credentials) does not retry, since that isn't an address problem.
-
Improvement
Process Map import more robust to repeated attempts
Importing a Process Map with a request key (requestId) already protected against creating the same map twice on a duplicate submission — but if an attempt got stuck for too long (for example a slow disk, not an AI call: none is made here) after already creating the map, or the very last step hit an error, a later retry could, in rare cases, end up creating a second map without anything flagging it. Now an attempt that got stuck for too long after creating the map is recognized as such: a retry with the same key gets a dedicated error with the id of the already-created map, not a repeat of the work. An error right on the last step instead permanently closes that request (it must be retried with a new key) instead of leaving it in limbo that a retry would have picked up incorrectly.
-
Improvement
Transitions protected while a phase is still being entered
The instant an item enters a new phase, the engine prepares the entry tasks and evaluates the automatic rules: if a manual transition (from the interface, the browser extension, or an MCP integration) arrived in exactly that window, it could find the item mid-setup. A manual transition that arrives while entry is still in progress now gets a retryable error — retrying once entry into the phase has finished (normally a matter of a few seconds) resolves it — instead of risking acting on a phase that isn't ready yet. (The Admin force transition remains a deliberate exception: it bypasses this check too, the same way it already bypasses blocking tasks and required fields.)
-
Improvement
Safe transition retries for integrations
An integration that doesn't get a clear response to a transition request (for example due to a network hiccup) can now retry it while declaring which phase it thought it was starting from: if the item has already moved on — because the first attempt actually succeeded, or because someone else moved it in the meantime — the retry stops with no effect, instead of risking an unwanted second transition.
-
Security
Warning for AI tasks with an empty prompt or no data fields
An AI task (LLM mode) configured with an empty prompt or no reference at all to the item's data doesn't define what the model actually needs, so it ends up receiving more data than necessary (within whatever limits are already in place — minimization and the Data Shield, where active). Now, at flow publish time and already in the task panel, a warning calls attention to this and points to the Data Shield settings — without blocking anything.
-
Improvement
Scheduled items rebinding to a new version get re-checked
When a scheduled item is due to start on a flow version that is no longer active and automatically rebinds to the latest published version, FlowSharp now checks that version against the same gates a normally created item would face (work-in-progress limit, uniqueness, data consistency, title formula). If a check fails, the scheduled item stays on its original version instead of starting anyway under a configuration that would have rejected it.