Answered 1 Sep 2026 · originally a pre-read

Automations Open Decisions

All five are answered — Josh replied 1 September. Each decision below now opens with what was settled and where it landed on the board; the reasoning is kept underneath so the why survives, not just the verdict. One answer created new work, and one is not a decision at all any more.

For Joshua Moore From engineering 4 settled · 1 to research Target: MVP, end of September

Where things stand

The work is now 32 issues in Linear, organised by how the system is layered rather than by feature area — each layer has to be settled before the next one can be built against it:

Every question below sits at layer 1, 2 or 3 — which is why they're worth ten minutes now rather than being discovered later. Answering them late doesn't just delay work, it means rebuilding things that were already finished.

Decisions

four settled, one to research
01

Can one workflow have more than one trigger?

Not decided — going to customer research

I’d like to consider the “several triggers on one workflow” option in more detail in addition to a nested workflow approach. We can run some UX testing with Ashley to see which approach customers will naturally embrace more effectively — Josh, 1 Sep

Both options stay on the table and the answer comes from customers rather than from us. Worth knowing: this is the one that gates the largest remaining build — branch authoring and the diagram both render whatever a workflow can contain. So IO-14 has been unblocked deliberately and starts now: branches, nesting and the Else arm are identical either way, and the answer lands as an addition — a trigger control, or one more step kind — rather than a rework.

Lands as IO-3 · retitled, still open

Why now

It's the open TBD in Configurable Workflow Steps — "if a request being created or edited triggers the same auto-assignment flow." A saved workflow currently has exactly one trigger. The builder and the diagram both render whatever a workflow can contain, so answering this after they exist means rebuilding both and migrating every workflow already saved.

TODAY — TWO WORKFLOWS When created When edited Routing tree module → type → assign Routing tree module → type → assign same tree, kept in sync by hand WITH SUB-WORKFLOWS When created When edited calls calls Triage routing module → type → assign one flow — change the carpenter once
The difference is the number of copies, not the number of triggers. Today, wanting the same routing on create and edit means maintaining two identical trees — and remembering both when a request type or an assignee changes.

Options

  • Composable sub-workflows. A workflow can reference another as a step, as drawn above. This is also the "nested workflows" idea from the design review.
  • Several triggers on one workflow. Closest to the literal ask, but it changes the stored shape of every workflow.
  • Neither for MVP. Guidance becomes "build two workflows"; revisit if customers hit it.

What composability buys

  • One place to change a shared rule — add a request type once, not once per trigger
  • Workflows small enough for a person to read; the routing tree stops being copied into every rule that needs it
  • A natural unit to test: dry-run the shared flow once, not per copy
  • Answers the trigger TBD without migrating stored workflows

What it costs

  • We must make loops impossible to author — A calls B calls A
  • Indirection has a comprehension cost. "What happens when a request is created?" now needs two things read instead of one
  • A versioning question: does a caller follow the shared flow's edits, or pin the version it was built against?

We'd recommend

Composable sub-workflows. No migration, and it turns a duplication problem into a reuse feature customers asked about independently.

The comprehension cost is real and worth designing against — the diagram in decision 04 is most of the answer, since a shared flow drawn inline reads as one picture again.

Blocks: branch authoring and the workflow diagram — together the largest remaining build.

02

Is custom JavaScript in the MVP?

Agreed — out of MVP

I’m fine leaving custom javascript out of the MVP. I’ll push it to the end and treat it as a stretch goal or a fast follow if we get through the rest of the build with extra time — Josh, 1 Sep

Out of MVP but not dropped — it stays on the board at low priority, so if the rest of the build lands early this is where the time goes. The isolated-runtime shape stays recorded.

Lands as IO-5 · low priority, kept as a stretch goal

Why now

It's a named topic for this session, and it points the opposite direction from how the engine is built. Today every action is a named block, the engine can describe exactly what a workflow would do before it does anything, and there is exactly one place in the code where a change to FMX happens. That's what makes "preview it safely against live data" true. Arbitrary JavaScript trades all of that for expressiveness.

Option What it can express Preview stays safe What it costs to build
Not in MVP Named blocks only — plus whatever the LLM-with-a-schema step covers Yes, unchanged Nothing. We learn what's actually missing from real workflows
Isolated runtime Anything a customer can code Yes — the boundary holds, since the block still takes structured input and returns structured output A new service, sandboxing, secrets, and its own failure modes
JavaScript inside the engine Anything No. We can no longer say what a workflow will do before it runs, and the single-write-site guarantee goes Least code, most risk

We'd recommend

Not in MVP, with the isolated runtime as the shape if and when we do it.

Worth testing something first: the criterion itself expects these blocks to be mostly LLM-written. If that's true, the LLM-with-a-schema approach we agreed on may already cover most of what anyone would reach for JavaScript to do — and we'd rather learn that from real workflows than guess now.

03

Is workflow load ordering still shelved?

Shelved — but with a workaround that is new work

I’m also fine with keeping load ordering shelved in the same way. However, as a workaround, I’d like to add some in-app warnings to alert users when two workflows might contradict each other — Josh, 1 Sep

The warning does not resolve a contradiction — it makes “last write wins, in an order nobody chose” visible rather than discovered. Two things shape it: detecting a clash needs the tenant’s other enabled workflows, so it cannot live in the per-plan validator; and the real risk is false positives, since two rules on one trigger writing one field are often deliberate.

Lands as IO-36 · new

Why now

It was shelved at the design review and that's probably still right — but if composable sub-workflows land (decision 01), workflow-calls-workflow becomes literally the "one or more workflows triggering one or more others" case the criterion describes. Worth re-confirming with that on the table.

What shelving actually means, precisely

We can prevent runaway loops — a workflow can't trigger itself indefinitely, and the engine recognises its own changes so it doesn't react to them. We cannot say which of two workflows wins when both fire on the same request and set the same field. Both run, the last change sticks, and the order is not something anyone chose.

We'd recommend

Stay shelved for MVP — and say it plainly to pilot customers rather than letting them discover it. "Don't build two workflows that set the same field on the same trigger" is a livable instruction for a small pilot and an unacceptable one at GA.

04

Is the workflow diagram September scope?

Agreed — read-only in MVP

we can move forward with a read-only diagram for the MVP then come back to visual diagrams — Josh, 1 Sep

Matches the recommendation. Authoring through the diagram, and reading a customer’s diagram as input, both come later.

Lands as IO-15 · confirmed as scoped

Why now

It arrived in Configurable Workflow Steps during the review pass — "easy to visualize and communicate the overall workflow from FMX" — and hasn't been sized or scheduled since. It's a real build, not a finishing touch.

AS A LIST OF STEPS If Module is Maintenance If Request type is Carpentry Assign to Carpenter Otherwise Assign to Supervisor every step at the same level — which action sits under which condition is nowhere on the screen AS A DIAGRAM Module is Maintenance Type is Carpentry Assign to Carpenter Assign to Supervisor else the same five steps — the nesting is the thing you can now see
Both sides are the same workflow. This is the PRD's own carpentry example at two levels deep; real ones go deeper. The diagram isn't decoration on top of branch authoring — past one level it's the only way an author can check they built what they meant.

And a second reason it may be more central than it reads

LLM-Built Workflows wants to accept a customer's diagram as input. Same visual vocabulary, opposite direction — worth designing once rather than twice.

We'd recommend

A read-only diagram in MVP, built alongside branch authoring rather than after it. Reading a customer's diagram to generate a workflow is a GA feature.

05

Does usage pricing need Iris counts at launch?

Answered — reporting is not a launch requirement

I’m good with the recommendation on tracking Iris usage. We can roll this out with unlimited usage or silent limits for now. My biggest priority is ensuring that historical runs are accessible so customers can see exactly when an automation ran and what the result was for troubleshooting purposes — Josh, 1 Sep

So we record from the first LLM block — nearly free then, a retrofit later — and surface counts after MVP. The priority named in the second half mostly already exists: a run is recorded on every wake including the ones that matched nothing, with the full step trace. Worth checking against what a customer expects rather than declaring it met.

Lands as IO-28 · dropped to low

Why now

Run History notes that usage-based pricing is being explored around how often Iris is used successfully per run. Whether that's a launch requirement changes when we build the counting, and the difference in cost is large.

The shape of it

Recording each LLM step — which workflow, which run, succeeded or not — is nearly free at the moment we build the first LLM block, because that's when the code is open anyway. Adding it afterwards means going back through shipped code and backfilling history we never captured.

We'd recommend

We record it regardless, starting with the first LLM block — that part isn't worth debating at its price.

What we need from you is narrower: whether the reporting — counts visible to customers, or to us for billing — has to exist at launch or can be a fast-follow.

Confirmations

one answered, one outstanding

06 · There's a blank acceptance criterion — answered

Just a heads-up on how Notion's API works — soft-deleted records will still show up, so you'll need to adjust your sync logic to ignore any records that have that deleted status — Josh, 1 Sep.

Nothing was lost, then: it was deleted, and we read it anyway. Our reconcile now skips pages carrying that marker, which matters more than this one row — without it the board would grow a phantom line every time a criterion is retired.

07 · Linear is where engineering tracks this

The board's been shared. You'd mentioned possibly using the office site for formal tickets — just confirming so we don't end up maintaining two half-records. Notion stays the requirements source of truth either way; Linear is only the work.

Still outstanding

Marking the reviewed criteria as Reviewed in Notion. The answers above settle the substance; the status field is a separate act, and it is the signal we use to move an issue from "requirements not settled" to "ready to pick up". Seven are still held back by it:

And one thing worth knowing about how we read your edits: changes to a criterion's Details are as useful to us as status changes, sometimes more. The last pass added Status as a branch property, added the diagram requirement, and renamed Iris to "an LLM" — all three reshaped actual work, not just its readiness. So edit freely; we diff the details, not just the checkboxes.