Back to the changelog

• Improvement

  Automatic task outcomes everywhere

  A completed task's outcome now shows for every task type, not only manual ones: in the task detail, in the case's task list, in the Kanban and on the Tasks page, where a label next to the status shows the outcome (shortened when long, in full on hover). For a Jev task that stayed below the confidence threshold, the detail warns that the value is the uncertainty outcome.

• Improvement

  An "AI Execution" you can read

  An AI task's detail shows model, tokens, call duration, Data Shield and data minimization; for a Jev task a table with, for each question, the answer, the confidence with the threshold that decided it and the field it was written to; for an LLM task the fields written and whether the response set the outcome. The prompt text and the raw response never show here: administrators find them in the AI call log, with a link already filtered on that task. Executions before this version show the basic data with a note.

• Design

  The same "Assigned to" everywhere

  Task detail, case list, Kanban and Tasks page use the same rule as the flowchart: the assigned person or "Unassigned" for manual tasks, "AI" for AI and Jev tasks, "System" for scripts, waits and sub-processes, "Connector" for integrations, "Event" for event tasks. No placeholder user is created: it is a label describing who does the work.

• Feature

  Jev outcomes offered to rules

  When a Jev question is marked as outcome, the task keeps its own outcome list up to date — the question's options plus the organization's uncertainty outcome — and the exit-rule selector offers them ready to pick. If the task's outcomes had been written by hand and no longer match, the Designer flags it and offers to replace them in one click; whoever saves the flow through the API or imports it gets the same alignment, with a warning when hand-written outcomes remain different.

• Design

  Generated phase code: no more internal errors

  When you leave a phase's Code field empty, FlowSharp derives it from the name. With a very long name the generated code is now always shortened to 100 characters, and if two phases end up with the same shortened code, one of them gets a trailing number — before, the save could fail with a generic error. A Code you write by hand is never touched by this rule.

• Improvement

  Data Schema: unsupported rules are rejected, not silently lost

  The Data Schema's advanced JSON mode keeps a field's type, description and structure (its format only for Document fields), but not rules like "minimum value", "maximum length" or an allowed-values list — there is no place to keep them. Writing them used to be accepted and the rules would then vanish with no warning on the next read; now the save rejects them right away, pointing out exactly which ones. The "Generate with AI" button already asks for a schema that follows these rules; if the model still proposes one outside the list, FlowSharp removes it on its own before showing you the schema, with a note explaining what was dropped — not a rejection, a schema that's already ready to save. A flow imported from a file, URL or shared link with these same rules in its Data Schema isn't blocked, though: FlowSharp removes them and flags it with a warning, so the imported flow is already ready to go.

• Integration

  Data conflict: the suggested fix now actually works

  When a data change on a case conflicts with a field already written differently, the error message used to suggest "clearing the field" before rewriting it — but that wasn't enough on its own. It now points to the step that actually works: reset the field, then write the new structure in a second step. On top of that, a change that doesn't really alter anything no longer bumps the case's revision number or leaves a false row in its history.

• Improvement

  Scripts are more honest about a wrong argument

  A script that writes to a case's data with setData() must pass two values — the field and the value to write. If an object arrives in place of the field, the task used to finish as successful without writing anything and with a misleading history row; now the task fails right away, with a clear cause, writing nothing and leaving no false trace.

• Feature

  A case's origin, always visible

  A case's detail now says how it came to be — manual creation, API, an MCP assistant, the Flow Agent, an event, another case's sub-process, a scheduled start not yet begun, or sample data — in the "Origin" card and in the quick preview. A start awaiting confirmation (for example from an MCP assistant) shows the real channel, not "Scheduled". That card used to rely on data the API stopped returning a while ago, so it almost never showed up, and any case started by an integration was shown as "manual creation".

• Improvement

  "Archive" tells you what stays

  Archiving a flow that also has an open Draft now says so in the confirmation dialog — the Draft is left untouched — and if there are cases still in progress on that version it tells you how many, explaining that they will keep working there. The message stays the simple one you already know when neither applies.

• Improvement

  Folders holding only disabled or archived flows

  A folder that only holds disabled or only archived flows no longer looks empty just to fail when you try to delete it: FlowSharp tells you how many there are and offers to show them, so you can move them — or, for archived ones, restore and then move them, or delete them for good — before deleting the folder.

• Design

  Task-type names consistent everywhere

  An Integration task's detail is now titled "Integration", no longer "Webhook". A process map's import report uses today's names (Integration, Sub-flow) instead of the old technical ones. A case's history now shows the right verb for the task's status — completed, skipped or failed, with a dedicated icon for skipped ones — instead of always saying "completed"; and the "Case created" row names the real starting channel instead of always saying "manual creation".

• Design

  A more precise map import report

  When a map's package declares a process that no node uses, the import report now says which one — not just its internal reference — and the process count shown before importing no longer counts it, matching the list you see afterwards. An unresolved dependency towards an external sub-process now also names the process that contains it, not just the phase; and exported files no longer show internal labels like "phase s1" instead of the phase's real name.