Back to the changelog

v0.78.0

August 2, 2026

What the flow declares now genuinely holds. Waiting for data, work-in-progress limits, response times, required fields on completion, priority: all of these could be configured, and then nobody — wholly or partly — enforced them. Waiting now genuinely suspends the phase's work and clears the moment the data arrives, a queued item no longer moves as if it were active, escalation creates the work in the destination phase, and required fields apply identically on every channel.

  • Improvement

    Waiting for data is a real wait

    The work items of a phase waiting for required data were created immediately and stayed completable by hand: you could close the work of a phase the flow had not admitted yet. Completion is now refused with an explanation, identically from the interface, the browser extension, integrations and agents. And the wait clears no matter where the data comes from: previously the check was repeated from only one of six entry points, so an item could sit still while already having everything it needed. Items generated by another activity now go through the same checks too, instead of being created bypassing the whole entry chain.

  • Improvement

    The work-in-progress limit is a limit

    The limit was declared but avoidable: an item queued because the phase was full could move forward as if it were active, and the phase ended up working more items than it admitted. The transition is now refused until the item is admitted, while the system's automatic routes — deadlines, response times, release from the queue, emergency unblock — remain free to move it. The message now states which exits genuinely exist, instead of promising one that does not in certain setups, and the release-order setting appears only where a queue genuinely exists, describing the real order: priority first, then arrival.

  • Improvement

    Response times produce effects

    The automatic move on elapsed time relocated the item but left the destination phase empty: its work items were never created, nobody received the work and the escalation produced no practical effect. The destination phase is now opened in full. On top of that, items already at their destination no longer clog the periodic check, where they stayed candidates forever, taking the turn of those that genuinely needed evaluating.

  • Improvement

    Required fields: the same rules on every channel

    The browser extension skipped every check on fields required to complete a work item — simply omitting the field was enough — and the three copies of that check scattered across the product had already drifted apart. There is now a single check: outcome, rationale and time spent are required wherever a work item is completed, whitespace does not count as an answer, and the error returned is the same on every channel. A requirement declared at flow or organisation level now applies to agents too, which previously read only the one on the individual work item. Finally, no new work can be added to an already-closed item, while the wrap-up work of a closed item becomes completable again.

  • Improvement

    Priority orders the views

    A flow declared as prioritised ordered nothing: the setting existed and had no effect. The views of that flow now open sorted by priority, and missing or non-numeric values go to the end — in both directions — without ever breaking the list.

  • Improvement

    Entity reference and uniqueness are two separate choices

    "An entity reference is required" and "that reference must be unique" were a single switch: anyone who wanted only the reference requirement also got the ban on opening a second item for the same entity. They are now two separate settings, and existing flows keep exactly the behaviour they had. The wording also distinguishes the two cases: with single start you can begin again once the previous one is closed; with one-off start the refusal is permanent.

  • Improvement

    Settings that no longer mislead

    An email alert with no recipient was accepted without objection and then never sent. It is now refused when saved, the system log states explicitly when a delivery is skipped for this reason, and the same applies to in-app notifications. The alerts panel points out which step is incomplete and no longer presents an unchosen recipient as "assignee": the error used to be unresolvable without leaving the interface. Publishing now also flags a rule waiting on an event nobody subscribes to, since it could never fire — a warning, not a block. And custom roles now reach the interface, which therefore no longer hides an action from someone entitled to it.