Actions and Dialog Flows
What this domain tests
This domain tests implementation of flows: steps, conditions, variables, slot collection, response variation and routing. You should know when to use an action step versus classic dialog constructs.
Core rules
- An action is a sequence of steps. Each step has a type: ask a question, say something, set a variable, call an extension, use a prompt, or search a knowledge base.
- Set the next step explicitly. Conditions are evaluated in order; the first true branch wins, so order matters.
- Use action variables for values needed inside the flow and session variables for values reused across actions. Initialize defaults before reading them.
- For slot filling, mark required slots and let the assistant re-ask only the missing one; validate each answer before moving on.
- Response variations reduce repetition but must preserve meaning. Do not vary a legal disclaimer.
- In classic dialog, handlers and digressions can interrupt a node; in actions, use explicit conditions and routing to avoid surprise jumps.
- Always define a fallback, an error branch and a handoff branch for external calls.
Worked example
An order-status action asks for an order number. A condition checks a regex; invalid input re-asks with an example. A custom extension returns status. A condition on status: “shipped” says the carrier and tracking link; “processing” says to check later; anything else routes to an agent. The action sets a session variable last_status for a later follow-up. Reasoning: validation happens before the API call, branches are ordered from specific to general, and the session variable supports continuity without re-asking.
Traps
Reading a variable before it is set; using a condition that is always true; creating loops by returning to the same step without a counter; forgetting the default next step; and using a prompt step for a value that must be exact.