What we shipped in March (and what we cut)

March was a month of consolidation after a busy February. We shipped four changes that had been in progress for longer than we wanted, cleared two items that had sat on the roadmap since Q4, and sent two more back for a rethink. This is a plain-English account of what landed, what did not, and why. We write these monthly because product decisions are easier to trust when you can see the reasoning, not just the result.

01 · ShippedShipped

• Step-level evidence capture. Each step in a flow can now accept an evidence attachment: a file, a link, or a free-text note. When the step is completed, the attachment becomes part of the run record automatically, without any separate action from the person running the flow. The driver here was audit prep: teams told us they were exporting run data and manually annotating it before each audit. That work now happens as a side effect of running the process, not as a separate effort at quarter-end.

• Bulk owner reassignment. Owners can now be reassigned across multiple flows and steps in a single operation, rather than one at a time. A single reassignment on a twenty-flow library previously meant twenty separate edits. This was the most upvoted item in the product feedback queue as of February.

• Flow-level read access. Flows can now be shared in read-only mode with people outside the workspace, via a link. No account required on the viewer’s side. This came from a specific pattern we saw repeatedly: an ops team wanting to share a process map with a client or auditor without granting edit access or requiring a login.

• Run duration visibility. The run view now shows elapsed time per step and total elapsed time for the run, compared to the median for that flow. This is the first of several planned additions to the run analytics panel; the intention is to surface where processes slow down in practice rather than in theory.

02 · CutCut

AI-assisted step drafting. We had a working version of this in internal testing through February: a prompt in the step editor that would draft step text based on a short description. It worked well enough technically, but the output it produced was generically written, tended toward passive voice, and lacked the specificity that makes a step actually useful. “Confirm the document has been reviewed” is not a step; “open the review checklist, tick each item, and add your name in the reviewer field” is. The AI drafts consistently produced the former. Sending generic drafts into production-quality flows would make the underlying content worse, not better. We have taken this back to rethink the scope: the goal is not to draft steps, but to flag where existing steps are too vague to be actionable. That is a different problem, and probably a more useful one.

Notification digests. The idea was a daily or weekly digest of flow activity for workspace owners: who ran what, what completed, what stalled. We built a prototype, tested it with eight teams over six weeks, and found that three of them turned it off within a week, four used it sporadically, and one found it genuinely useful. The pattern for the teams that turned it off was consistent: the digest arrived and they had no clear action to take from it. Information without a decision attached to it is noise. We are not abandoning the idea of surfacing flow activity, but we want to redesign it as actionable alerts rather than periodic summaries. A notification that says “this flow has been stalled at step three for four days” is worth receiving. A weekly summary of all activity is not.

· · ·

April’s focus is the run analytics panel, the evidence capture improvements that came out of March feedback, and an internal project we are not announcing yet. The March feedback queue closed with 214 items; the top twelve are on the board for Q2 prioritisation. If you submitted something and have not heard back, the product team reads every submission and the response time is currently running at under five working days.