Start
Where every run begins.
Purpose
Marks the flow's entry point. The runtime sets its current node to the Start node and begins the execution loop from there.
Every flow has exactly one Start.
When to use it
Always — it is created with the flow. You do not add or remove it.
When not to use it
There is no situation where you delete a Start node. A flow without one cannot run.
Requirements
None. Start runs without a device and takes no configuration.
How it runs
The runtime initialises the execution context — every declared variable set to null, then defaults applied, then initial values, then type-checked — and sets the current node to the Start node's id.
Start then routes Success immediately.
It counts as an executed node against the flow's maxNodeExecutions guardrail.
Settings
Start has no settings. Its params object is empty by design.
Everything you might expect to configure here lives in flow settings instead:
| What you want | Where it lives |
|---|---|
| Default timeouts and thresholds | Flow settings → Defaults |
Guardrails (maxNodeExecutions, etc.) | Flow settings → Runtime |
| Which instance the flow expects | Flow settings → Target |
| OCR and input feature gates | Flow settings → Features |
| Variable declarations and defaults | The Variables dialog |
| Values supplied per run | Flow Input Parameters |
Ports
| Port | Taken when | Required |
|---|---|---|
| Success | Always, immediately | Yes |
| Fatal | System error | No — never followed |
Basic example
Realistic example — a preflight check
The most valuable thing to put immediately after Start is a check that you are where you think you are:
Flows that assume their starting state are the most common source of unexplained failures. One detection node after Start removes that entire class of problem.
Advanced example — seeding run state
Where a flow needs counters or flags initialised beyond their declared defaults, do it once immediately after Start:
Prefer declaration defaults where you can — they are applied automatically at run start and cannot be skipped by a branch.
Best practices
- Put a preflight check straight after Start. Verify the screen state before acting.
- Use declaration defaults rather than a Variable node for initial values, so a branch cannot bypass them.
- Keep Start wired to exactly one node. Multiple edges from Start make the entry path ambiguous to read.
- Do not treat Start as a configuration node — it has none.
Performance notes
- Start costs nothing at run time.
- It does consume one execution against
maxNodeExecutions, which matters only for flows near their cap. - All the real startup cost — schema validation, normalisation, graph validation, expression checks, asset verification, compilation, session creation — happens in preflight before Start runs.
Memory notes
- The execution context (variables,
nodeResults,lastResult) is created before Start runs. Each session gets its own. - Start itself allocates nothing.
Common mistakes
| Mistake | What happens | Fix |
|---|---|---|
| Assuming the starting screen | Flow acts on the wrong screen | Add a preflight detection |
| Looking for settings on Start | There are none | Use flow settings |
| Multiple edges out of Start | Confusing entry path | Wire one |
| Initialising variables in a branch | Skipped if that branch is not taken | Use declaration defaults |
Troubleshooting
The run does not start at all.
Preflight failed before Start — schema, graph validation, expressions, assets, feature gates, or the instance session. The error is reported by runtime.start, and no runtime.started event is emitted.
The run starts but immediately does the wrong thing. The starting screen was not what the flow assumed. Add a preflight check.
The run rejects with TYPE_MISMATCH.
A declared variable's default or initial value violates its type. Fix the declaration.
FAQ
Can a flow have more than one Start? No — exactly one entry point.
Can I delete the Start node? No. A flow without one cannot run.
Does Start count toward maxNodeExecutions?
Yes. So does Stop.
Where do I set the flow's timeouts? Flow settings → Defaults, not on Start.
Related nodes
- Stop — the terminal counterpart
- Return — end the flow from anywhere
- Sub Flow — a called flow has its own Start
Related pages
- Execution Model — the startup sequence and loop
- Flow Anatomy — where settings actually live