Logical Comparisons: Testing Conditions (Equal, Greater Than, Less Than)
Logical comparisons are expressions that evaluate to TRUE or FALSE. In RapidPro.app, you’ll use them to route contacts in Split by Expression, validate responses (like age checks or thresholds), and apply conditional logic in updates and messages.
Quick setup checklist
Use this checklist to apply logical comparisons safely in flows.
Step 1
Understand what logical comparisons do
A logical comparison returns TRUE or FALSE. You’ll most commonly use comparisons to:
- Route contacts using Split by Expression
- Validate user responses (age limits, minimum scores, attempt counts)
- Apply simple conditional logic before an update or next step
Tip: If your goal is routing, write the comparison so it produces a clean TRUE/FALSE outcome, then keep an Other fallback branch for anything unexpected.
Step 2
Use comparison operators
You can compare values using these operators:
- Equals: =
- Not equals: !=
- Greater than: >
- Greater than or equal: >=
- Less than: <
- Less than or equal: <=
Technical detail: Comparisons are typically used inside an expression wrapper like
@(...) when you need evaluation. If you’re only inserting a value into a message, you can use the variable directly (for example: @contact.first_name).Step 3
Apply comparisons with practical examples
Numeric comparisons
@(contact.age > 18)@(results.score >= 80)@(results.attempts <= 3)
Text comparisons
@(results.answer = "yes")@(results.status != "cancelled")
Note: For text comparisons,
= and != are commonly treated as case-insensitive in RapidPro-style environments (for example, “YES” matches “yes”). If you need consistent matching, normalize the value (for example, compare lowercase-to-lowercase).Tip: In Split by Expression, always include a safe fallback path (like Other) to handle empty values or unexpected inputs.
Common issues
Problem: Everyone goes to “Other” in a Split by Expression
Fixes:
- Check variable names (for example,
contact.agevsresults.age). - Confirm the value exists (it isn’t empty at runtime).
- Make sure numbers are stored as numbers (not as text).
- Test the run in the Simulator and inspect variables using the context explorer.
Problem: Text matching doesn’t behave as expected
Fixes:
- Remember that many setups treat
=/!=as case-insensitive for text. - Normalize input before comparing (for example, convert to lowercase) and compare consistently.
- Trim extra spaces in your expected values and test with realistic user inputs.
Problem: My comparison fails because the value is empty
Fixes:
- Ensure the contact reaches the node that creates the value before you compare it (e.g., a Wait for Response result).
- Add a fallback branch to handle empty values gracefully.
- If needed, validate input earlier using response rules.