Skip to main content
A Condition node splits the flow into two paths — one for matches, one for non-matches.

​
Fields you can match on

​
Contact fields on website conversations

A branch decides what the visitor sees next, so on a website conversation a condition only sees the contact details a flow message may show:
  • contact.email (and its domain) and contact.phone count as empty on an anonymous website conversation, unless the visitor typed that address or number in that conversation (an address left in the contact form counts, also in the form of one of their own earlier conversations your team merged into it). On a signed-in user’s conversation they also see the verified email and the phone your site signed for that user.
  • contact.name and contact.company count as empty on an anonymous website conversation, unless the visitor gave that name in that conversation (in the chat or the contact form) or in the contact form of one of their own earlier conversations your team merged into it. On a signed-in user’s conversation they are the name and company your site signed for that user.
  • On an anonymous website conversation, language and every contact and company custom field, your team’s included, count as unknown; language then follows the visitor’s own messages. On a signed-in user’s conversation, language is the one your site signed, and custom fields only count when your site signed them for that user.
  • subject and tags leave out what an earlier merge brought in from another person’s conversation.
  • On a mixed conversation, one a merge made before Keloa refused such merges mixed with another person’s or another channel’s conversation, every conversation custom field counts as empty, and subject and tags leave out what any merge brought in; once data retention deleted the conversations merged into it, they count as empty. On an email or other conversation such a merge moved a website conversation into, a conversation custom field filled before that merge counts as empty too. See Website conversations merged before the rule.
Other channels, such as email and WhatsApp, see every field as usual. In the Try run the panel shows the value the condition used.

​
Operators

​
Combining conditions

One Condition node can have multiple rules. All rules in a condition are AND-ed — the branch matches only if every rule passes. For OR logic, use two Condition nodes back to back, each feeding the same next node from their yes outputs.

​
Multiple branches

Advanced: add more than two branches on a single Condition node. Each branch has its own rule set — the first matching branch wins. This is like if/else if/else instead of just if/else. Use multiple branches when you’re classifying into more than two buckets — e.g. intent = refund → returns team, intent = sales → sales team, default → AI.

​
Intent and sentiment

intent and sentiment are classified by the AI on every inbound message. They’re available as fields for conditions and as analytics dimensions. Common intents surface automatically — shipping, refund, pricing, technical, cancellation, pre-sales. If the model isn’t confident, intent is unknown.

​
Example

Match a high-value customer in distress:

​
Tips

  • Start with one rule. Add more only when the first one isn’t specific enough.
  • Prefer tags over string matching. A tag is deliberate; a keyword match fires on anything.
  • Test with the Try run. The panel shows every condition’s evaluation with real values.