Automation
In short
Why did my Reply condition route contacts incorrectly?
Usually because the operator does not mean what it appears to. Which comparisons a condition offers depends on the field's type, and a yes/no field only tests whether a value is set, not whether it is true. Correcting the step does not re-route contacts who already passed it.
Quick fix
- Open the condition and note the field, the operator and the value it compares against.
- Check the field's type. A yes/no field offers only "is set"; it cannot distinguish true from false the way a text field distinguishes two values.
- Check the branch wiring: confirm which output is the yes path and which is the no path.
- Fix the step. Then deal with the contacts separately; the fix applies only to contacts who have not reached it yet.
- Watch the next few contacts through the step and confirm they go where you expect.
Didn't work? Contact Reply support; the team can check your account directly.
Symptom
Contacts took the wrong branch. Sometimes every contact went one way; sometimes the split looks random. Occasionally a whole sequence ran through a mis-wired condition before anyone noticed.
Most likely causes
| Cause | How to recognize it |
|---|---|
| The operator does not mean what it appears to | A yes/no field tested for "is set" is true whenever the field has any value, including a negative one |
| The two branch outputs are swapped | Every contact goes the wrong way – a clean inversion rather than a messy split |
| The field is empty for those contacts | Only some contacts are misrouted, and they are the ones missing the value |
| The value is compared as text and does not match exactly | Case, spacing or a trailing character differs from what is stored |
| The condition reads a field filled later in the sequence | The condition runs before the value exists, so it always sees nothing |
| The contacts already passed it | You corrected the step and nothing changed for anyone already through |
Diagnostic checklist
- Read the operator alongside the field type. The list of available comparisons changes with the type, and this is where most of these go wrong. "Is set" on a yes/no field is the classic case: it is true for a stored no.
- Trace one real contact. Open its activity and follow which branch it took and what its field value was at that moment. One contact answers this faster than reasoning about the step.
- Check the wiring. With everyone going the same wrong way, the outputs are almost certainly swapped.
- Check the timing. A condition can only read what exists when the contact reaches it.
- Accept that the past is fixed. Work out how many contacts went the wrong way, because that is a separate job from fixing the step.
Resolution
The operator is wrong for the field type
Change the field, the operator, or both. If you need a true/false distinction, a text or picklist field with two explicit values is more predictable than a yes/no field, because you can compare against the value you mean.
The branches are swapped
Reconnect the outputs. Confirm by sending one test contact through rather than by reading the diagram; a swapped pair looks correct at a glance.
The field is empty for some contacts
Fill it before the condition runs, or add a branch for the empty case so those contacts have somewhere sensible to go rather than defaulting.
The value never matches
Compare the exact stored value with the exact value in the condition, including case and spacing. Prefer a picklist over free text for anything a condition depends on.
Contacts already went the wrong way
Fixing the step does not move them. The reliable approach is to duplicate the sequence with the corrected condition and move the affected contacts into the copy at the right step, rather than trying to unpick their path in place.
Verification
Put one contact through deliberately and confirm the branch. Then check the first handful of real contacts after the change; a condition that is right for one contact can still be wrong for a value you have not seen yet.
Prevention
- Build conditions on picklist or text fields with explicit values rather than on yes/no fields.
- Test with one contact of each kind before launching, not after.
- Make sure any field a condition reads is filled before the condition runs.
- Label the branches clearly so a swapped pair is visible.
FAQ
Why does my yes/no condition treat "no" as a match?
Because the available test is whether the field is set, and a stored "no" is a value. Use a field type where you can compare against the value you actually mean.
Will fixing the condition re-route contacts who already passed?
No. They keep the path they were given. Move them deliberately if it matters.
Can I see which branch a contact took?
Yes. The contact's activity shows the step it went to next.
Still stuck? Contact Reply support
If these steps didn't solve the problem, the Reply support team can look at your account directly. Open the Reply Help Center and send the team a message.
To get an answer faster, include:
- the field, the operator and the value the condition compares
- the field's type
- one contact that went the wrong way, and what its value was
- which sequence and step number
Don't send passwords, API keys, or access tokens.
Related
- Why was a contact not enrolled?
- Why was a variable not replaced in an email? – the other place field values bite
- Why is a campaign not running?
Build with Reply
- REST API: Sequences – read a sequence's steps and conditions
- MCP: docs.reply.io/mcp – inspect a contact's path from an assistant