Designing a conversation menu with no code
A menu node is a question and its branches, edited as a real diagram, a real grid, or a document — four views of the exact same flow, never four copies of it.
A conversation flow in Kav is a diagram your team edits directly — a menu node, a form node, a capability call, a handoff — never a paragraph of code standing in for one. The Flow Studio gives you four ways to look at the same document, and they stay in sync because they are the same document, not four things that happen to agree.
Four views, one graph
- Outline — a tree, good for seeing the whole structure at a glance.
- Grid — a real, editable
<table>and a full peer of the diagram, not a fallback for it: the canvas view is unusable with a screen reader, so the grid is where the same editing happens in a form every assistive technology can navigate. - Diagram — the canvas, loaded only when you switch to it, so a console that never opens it never downloads the graph library for nothing.
- Document — plain text, useful for reviewing a flow the way you'd read a script.
Drag an edge in the diagram, and the grid shows the new branch on its next render. There's one undo stack across all four, because there's one document underneath.
Building a menu node
A menu asks a resident one question and branches on their answer. On the node:
- Set the prompt — the question, as a translation key rather than a literal sentence, exactly like every other piece of user-facing copy in this platform.
- Add an option for each branch. Each one gets its own stable key (used internally, never shown to a resident) and a label key (what the resident actually reads).
- Order matters: it's the order a resident hears the options in, and you can reorder from either the node's own panel or the outline — both go through the identical move operation, so neither path can produce a different order than the other.
Give an option a key you'd still recognize in a report six months from now. It's what shows up in analytics and audit trails long after the label text has been reworded twice.
Draft, published, and what happens when you save
A published flow is frozen — ReplaceGraph refuses any edit to it, because a resident might be mid-conversation through it right now. Saving without naming a specific version clones your changes forward into a new draft of the same flow automatically; naming an exact version tries to write onto that row directly, which a published version will always refuse.
The publish button computes every reason it's blocked before you can click it — the same discipline as the rules engine's publish gate. Those are affordances for you as an author; the server enforces the identical rules again independently, so the same protections hold even against a request that bypassed the Studio entirely.