Every change, and what it asks of you

Every entry names what changed and, where a change affects how a workflow behaves, what you need to do about it. Breaking changes are called out in their own line rather than buried in a summary, and a security change is never filed as a fix.

A capability history, not a shipping log. Entries below map the order these controls were designed in; the dates and version numbers are indicative rather than a record of tagged releases.

Releases

  1. 2.14.0Latest

    Per-field redaction for AI steps, and approval batches that survive a reviewer leaving mid-review.

    • Added

      AI steps can now redact per field rather than per payload. A step may send an order amount while withholding the customer name, with the redaction map held in your tenancy so the response can be rehydrated without the model ever receiving the original value.

    • Changed

      An approval batch left open by a reviewer who loses access is reassigned to the next named approver in the policy rather than expiring silently. Previously the batch sat until it timed out, which read as an automation failure when it was an access change.

    • Added

      Editing a workflow now shows a scope diff before you save: exactly which new permissions the change requests, and which steps call them. Adding a step that widens scope requires fresh consent naming the added scope.

    • Fixed

      Audit exports covering more than 90 days no longer truncate at the 10,000th row. The export now streams and states its row count in the manifest so a short file is detectable rather than assumed complete.

  2. 2.13.2

    Idempotency fix on replayed runs that touched a payment connector.

    • Security

      A run replayed within 60 seconds of a gateway timeout could issue a second refund for the same order line. Payout steps now key idempotency on the external reference rather than the run id, so a replay resolves to the original settlement. Any workflow using a payment connector should be reviewed against its settlement log for the affected window.

    • Changed

      Automatic retries on payment steps are disabled by default. Failed payout runs park with their full input payload for an operator to replay deliberately, which is the behaviour every finance team we asked expected already.

  3. 2.13.0

    Hash-chained audit log, and model-region pinning as part of the workflow definition.

    • Added

      Audit entries are hash-chained: each entry includes a digest of its predecessor, so a deleted or edited row breaks verification instead of vanishing quietly. The verification command is available in the console and returns the first broken link rather than a pass or fail.

    • Changed

      Processing region moved from an account-level default to a per-workflow field. A workflow pinned to an India region cannot be relocated by a settings change made elsewhere in the account. Existing workflows inherit their account default on upgrade and should be reviewed.

    • Added

      Admins can restrict which models a team may call, and the console lists every model referenced across all workflows with the steps that call it.

    • Changed

      Denying an approval now requires a reason from a fixed list rather than free text. Free-text reasons were unsearchable in practice, which made denial patterns invisible.

  4. 2.12.1

    Connector scope descriptions, and a reflow fix in the run inspector.

    • Changed

      Connector consent screens describe each requested scope in plain language beside its technical name, so the person authorising can tell what the workflow will actually be able to read.

    • Fixed

      The run inspector's step table no longer forces horizontal scrolling at 320px. Long payload values wrap rather than widening the page.

    • Fixed

      The workflow canvas can be operated entirely from the keyboard: steps are reachable in document order, reordering has explicit key bindings, and every drag interaction has a non-drag equivalent.

  5. 2.12.0

    Approval gates became per-step rather than per-workflow.

    • Added

      Any step can carry its own approval gate with its own threshold and approver policy, instead of one gate guarding an entire workflow. This is the change that made value-banded refunds and dual sign-off on material adjustments expressible at all.

    • Changed

      Breaking change: workflow-level `requiresApproval` is replaced by per-step gates. Workflows using the old field are migrated automatically to a gate on their final step, which is the closest equivalent but may be stricter than you intended. Review migrated workflows before relying on them.

    • Added

      Dual approval can require that the two approvers be different named users, so segregation of duties is enforced by the workflow rather than by the org chart.