Overview
Conditionals let you run steps only when a condition is true. Use Start Condition to define the rule, add the steps that should run when it’s true, then End Condition to close the block.
At a glance
- Two subjects: Page Element or Expression
- Operations: Visibility checks for elements; equality/inequality or truthiness for expressions
- Scoped execution: Only steps within the block run when the condition is true
- Automatic pairing: Adding Start Condition auto-adds End Condition
How it works

Generated code (conceptual)
Configure in the UI
Subject
- Element: Pick or enter a locator. Operations include: “Is Visible”, “Is Not Visible”, “Has Text”, “Does Not Have Text”.
- Expression: Enter a
{{ ... }}
expression (e.g.,{{vars.userRole}}
,{{vars.count}}
). Compare using “Equals”, “Not Equals”, or evaluate truthiness.
Expected value
- Shown only when required by the selected operation
- Enter the comparison value directly (e.g.,
admin
,Pending
)
Expression tips
- Use
{{ ... }}
syntax; reference variables viavars
, e.g.,{{vars.count}}
,{{vars.userRole}}
- Normalize types before comparing:
{{String(vars.count)}}
,{{(vars.flag) ? 'yes' : 'no'}}
- Truthiness checks: omit expected value and evaluate the expression directly when appropriate
Examples
Element visibility
Show a retry flow only when an error banner appears:- Check if: Element →
.error-banner
- Operation: Is Visible
- Click “Retry”
- Refill fields
- Submit
Expression value
Run admin-only steps:- Check if: Expression →
{{vars.userRole}}
- Operation: Equals
- Expected value:
admin
- Open Admin Panel
- Verify dashboard
- Manage users
Best practices
- Clear rules: Keep conditions specific and meaningful
- Stable selectors: Prefer
data-testid
for element conditions - Consistent outputs: Ensure expressions return the expected type/format (e.g., string vs number), and match case when comparing
- Minimal scope: Keep conditional blocks focused and short
- Avoid deep nesting: Prefer simple, readable logic
Troubleshooting
- Always false: Selector/value mismatch; verify expected value and timing
- Always true: Re-check logic or use the opposite operation to validate
- Missing End Condition: Ensure every Start has a matching End
Performance considerations
- Prefer simple expressions and stable selectors; avoid expensive DOM queries inside conditions
- Keep conditional blocks short to minimize skipped work when false
- If a condition is costly to compute, consider evaluating once and reusing its result