Building multi-level menus with submenus

A menu node doesn't know anything about "submenus" as their own concept — each option just names its own destination node, and that destination can be another menu node exactly as easily as it can be an "ask" step or a form. Point three options at three different menus and you have a submenu structure; nothing in the underlying document distinguishes it from three options routed to three flat destinations.

Building one

Add the parent menu, with its own prompt and options.
Add a second menu node for the submenu — its own prompt, its own options.
On the parent menu's option meant to open the submenu, set its target to the submenu node instead of an end, ask, or capability call.
The submenu's own options set their targets exactly the same way — another menu, a form, a handoff, whatever the conversation needs next.

Getting back out

There's no built-in "Back" option. A menu option is just a label and a target — if a resident should be able to return to the parent menu, you add that option yourself, with its target pointed back at the parent menu's own node id. Skip it, and a resident one level deep has no way back except restarting the whole conversation.

How deep to go

Nothing in the editor limits depth — the graph will let you nest as many levels as you build. In practice, two levels reads cleanly in both the outline and the diagram; past that, the four-projection editor (outline, grid, diagram, document) gets harder to scan at a glance, and a resident on a small screen taps through more layers to reach an answer than a flatter structure would need. If a third level starts to feel necessary, it's worth checking whether a form or a capability-fed list would get there faster instead.

Give a submenu its own descriptive prompt rather than a repeat of the parent's — "Which type of pothole?" reads very differently to a resident than "More options."