Skip to main content

Reusable flows — extract, call, and see inside

Several journeys usually share the same chunk of work — a login, a form fill, an approval sequence. A flow is just a .trq session that another session calls as a single step: the ▶ call row runs every step of the referenced flow inline, with its own inputs, and reports what happened inside.

Extract a selection into a flow​

You rarely write a sub-flow from scratch — you notice a run of steps worth reusing after recording. Extract selection to flow… turns it into one:

  1. Multi-select a contiguous run of steps (Cmd/Shift-click) in the Events tab.
  2. Right-click → "Extract selection to flow… (N steps)".

Extract selection to flow — name the flow and promote typed values to inputs

  1. Name the flow — it's created beside the current session (same folder).
  2. Promote typed values to inputs (optional) — Trq lists every literal you typed in the selected steps, with an input name suggested from the field's label. Checked values become flow inputs: the new flow reads {{var.name}}, and the call row carries the actual value — so the same flow works with different data from different journeys.

Click Extract: the new .trq appears in the explorer, and the selection in your session collapses to a single ▶ call row.

before                                     after
2  input  Full name = "Ada Lovelace"       2  ▶ call fill-applicant-form.trq · 2 in
3  input  Email = "ada@example.com"
4  click  Save applicant

The extracted flow is a normal session — open it, edit it, replay it on its own, and call it from as many journeys as you like. Any conditions on the extracted steps come along unchanged.

Call a flow​

To call an existing flow, right-click a row → Insert call to flow… (or + Add step → Call flow), pick the session, and fill its inputs. Inputs accept {{templates}} — pass {{var.x}}, {{uuid}}, or literals. Outputs map values the child captured back into the caller's variables.

A guarded call is a branch​

Combine a call row with a condition and you have an if-branch without any block syntax — skipping the call skips everything inside it:

2  ▶ call premium-addons.trq   if text/Premium plan · visible
3  ▶ call basic-plan-note.trq  if NOT text/Premium plan · visible
4  click  text/Next

Exactly one of rows 2–3 runs; the other reports ⊘.

See inside the call​

A call row isn't a black box. After a run it shows an aggregate chip — the child outcome at a glance:

The call row's aggregate chip — 6/6 passed, partial skips, or failed at step N

Click the purple ▸ to expand the child steps inline — each with its own status, duration, and skip/fail reason. While the flow is replaying, children stream in live; if a child fails, the row expands itself with the culprit highlighted, and the steps after it show as not run:

Expanded child steps — statuses, durations, and a condition-skipped child with its reason

Child rows are run reports, not editable steps — double-click one to open the flow's own .trq and edit it there. Nested calls (a flow calling a flow) indent one more level. The Summary's step counts stay at the journey level, so sub-flows never double-count.

The CLI shows the same detail — trq play prints indented child lines:

2/4  …  call-flow   ▶ fill-applicant-form.trq · 2 in
  2.1/3  ✓  input       Full name = "Ada Lovelace"
  2.2/3  ✓  input       Email = "ada@example.com"
  2.3/3  ⊘  click       "Save draft"
         skipped by condition — text/Draft mode not found (2.0s)
2/4  ✓  call-flow   ▶ fill-applicant-form.trq · 2 in

Rules worth knowing​

  • Extraction requires a contiguous selection — extracting a gapped selection would silently reorder the steps left behind, so Trq refuses it.
  • Inputs are promoted only from typed values (input steps). Passwords and already-templated values are never offered.
  • A flow runs in its own variable scope, seeded from the call's inputs; only mapped outputs flow back.
  • Flows compose with everything: conditions, captures, {{calc(…)}}, api-request steps, and mid-journey insert all work inside a called flow.