Connect states and define automation workflows with transitions
A Transition is a connection between two states that defines how automation moves from one state to another. Transitions are the edges in your state machine graph, while states are the nodes.
Each transition defines what actions to perform (via a process) and which states become active/inactive after the transition completes. This gives you fine-grained control over your automation workflow.
Defines navigation FROM one state TO another state
Example: Login to Dashboard
from_state: 'Login Screen' → to_state: 'Dashboard'
Process: Type credentials, click submit button
Verification or setup when ENTERING a state
Example: Dashboard Load Verification
to_state: 'Dashboard'
Process: Wait for loading spinner to vanish, verify welcome message
In the state diagram, click and drag from the source state to the destination state to create a transition arrow.
Click the transition arrow to open its properties panel.
Select or create a process that contains the actions to perform during this transition (e.g., 'login_process', 'click_submit_button').
Configure whether the source state stays visible and which additional states to activate/deactivate.
Source state where this transition originates. Only applies to Outgoing Transitions.
Destination state where this transition leads.
ID of the process containing actions to execute during this transition. Can be empty for state-change-only transitions.
If true, the source state remains active after transition. Use this for dialogs or overlays that appear over existing screens.
Default: false
Additional states to activate after the transition completes. Useful for parallel states that should appear alongside the destination state.
Default: []
States to deactivate after the transition completes. Useful for explicitly closing parallel states.
Default: []
Maximum time to wait for transition completion.
Default: 10000
Number of retry attempts if transition fails.
Default: 3
Qontinui supports multiple states being active simultaneously. This is useful for scenarios like dialog boxes appearing over background screens, or multi-panel UIs with independent sections.
Opening a settings dialog while keeping the dashboard visible
Result:
Both Dashboard and Settings Dialog are active
Opening a sidebar and toolbar alongside the main content
Result:
Editor View, Sidebar, and Toolbar are all active
Closing all dialogs and returning to main screen
Result:
Only Dashboard is active, all dialogs closed
Use clear names that indicate what the transition does (e.g., 'submit_login', 'open_settings_dialog', 'close_error_popup').
Add Incoming Transitions to verify that a state was reached successfully, especially after long-running operations or page loads.
Each transition's process should accomplish one logical task. Split complex workflows into multiple states and transitions.
Use longer timeouts for transitions that involve slow operations (e.g., page loads, API calls). Use shorter timeouts for quick UI interactions.
When opening dialogs, modals, or tooltips over existing screens, set stays_visible=true to keep the background state active.
Use activate_states and deactivate_states to precisely control which states are active. This prevents unexpected behavior with parallel states.
