State Transitions
Connect states and define automation workflows with transitions
What is a Transition?
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.
Key Concept: Transitions = Navigation Logic
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.
How Transitions Work
- 1.Automation is in the source state (e.g., "Login Screen")
- 2.Transition's process executes (e.g., type username, click submit)
- 3.Destination state becomes active (e.g., "Dashboard")
- 4.Source state deactivates (unless stays_visible is true)
- 5.Additional states activate/deactivate as specified
Types of Transitions
Outgoing Transition
Defines navigation FROM one state TO another state
- •Specifies source state (from_state) and destination state (to_state)
- •Executes a process containing actions to perform
- •Controls which states become active/inactive after transition
- •Most common transition type for state navigation
Example: Login to Dashboard
from_state: 'Login Screen' → to_state: 'Dashboard'
Process: Type credentials, click submit button
Incoming Transition
Verification or setup when ENTERING a state
- •Executes after a state becomes active
- •Used for verification, waiting, or initialization
- •Doesn't change which states are active
- •Ensures state is fully ready before continuing
Example: Dashboard Load Verification
to_state: 'Dashboard'
Process: Wait for loading spinner to vanish, verify welcome message
Creating a Transition
Select Source and Destination States
In the state diagram, click and drag from the source state to the destination state to create a transition arrow.
Configure the Transition
Click the transition arrow to open its properties panel.
Assign a Process
Select or create a process that contains the actions to perform during this transition (e.g., 'login_process', 'click_submit_button').
Set State Visibility Options
Configure whether the source state stays visible and which additional states to activate/deactivate.
Transition Properties
from_state
Source state where this transition originates. Only applies to Outgoing Transitions.
to_state
Destination state where this transition leads.
process
ID of the process containing actions to execute during this transition. Can be empty for state-change-only transitions.
stays_visible
If true, the source state remains active after transition. Use this for dialogs or overlays that appear over existing screens.
Default: false
activate_states
Additional states to activate after the transition completes. Useful for parallel states that should appear alongside the destination state.
Default: []
deactivate_states
States to deactivate after the transition completes. Useful for explicitly closing parallel states.
Default: []
timeout
Maximum time to wait for transition completion.
Default: 10000
retry_count
Number of retry attempts if transition fails.
Default: 3
Managing Parallel States
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.
Scenario 1: Dialog Over Background
Opening a settings dialog while keeping the dashboard visible
Result:
Both Dashboard and Settings Dialog are active
Scenario 2: Multi-State Activation
Opening a sidebar and toolbar alongside the main content
Result:
Editor View, Sidebar, and Toolbar are all active
Scenario 3: Closing Parallel States
Closing all dialogs and returning to main screen
Result:
Only Dashboard is active, all dialogs closed
Best Practices
Name transitions descriptively
Use clear names that indicate what the transition does (e.g., 'submit_login', 'open_settings_dialog', 'close_error_popup').
Use Incoming Transitions for verification
Add Incoming Transitions to verify that a state was reached successfully, especially after long-running operations or page loads.
Keep processes focused
Each transition's process should accomplish one logical task. Split complex workflows into multiple states and transitions.
Set appropriate timeouts
Use longer timeouts for transitions that involve slow operations (e.g., page loads, API calls). Use shorter timeouts for quick UI interactions.
Use stays_visible for overlays
When opening dialogs, modals, or tooltips over existing screens, set stays_visible=true to keep the background state active.
Manage parallel states explicitly
Use activate_states and deactivate_states to precisely control which states are active. This prevents unexpected behavior with parallel states.