How to Use Conditions in ZazzyAgent Flow Builder
A basic chatbot says the same thing to everyone.
A smart automation checks information before deciding what to do next.
For example:
Is this customer already a customer?
If yes:
Welcome back.
If no:
Let's get you started.
That's what a Condition does.
It allows ZazzyAgent to evaluate information and choose a different path depending on the result.
What is a condition?
A condition is a rule.
For example:
Customer Type = VIP
If the rule is true, one path runs.
If false, another path runs.
A basic structure looks like:
Condition
↓
TRUE ─────→ Path A
↓
FALSE ────→ Path B
What can a condition check?
Depending on the available data, conditions can evaluate:
System/customer fields
Custom fields
User-provided information
Other available subscriber data
The current Flow Builder condition system supports matching system fields and custom fields, with operators such as equals, contains, starts with and numeric/date comparisons where appropriate.
Simple example
Suppose you've collected the customer's name.
Your condition could check:
Name = Rahul
If true:
Welcome back, Rahul.
If false:
Welcome! Let's get your details.
This is only an example. In a real automation, you'll usually check useful business data rather than a particular name.
Check a custom field
Custom fields are especially useful.
Suppose you store:
Customer Type
Possible values:
New
Existing
VIP
You can create branches:
Customer Type = VIP
↓
VIP Path
Customer Type = Existing
↓
Existing Customer Path
Customer Type = New
↓
New Customer Path
Use Equals
Use Equals when you need an exact comparison.
Example:
Customer Type = VIP
This works well for controlled values such as:
Status
Customer Type
Product Category
Lead Stage
Use Contains
Use Contains when the value may contain additional text.
Example:
Message contains "refund"
This can help when identifying whether a message includes a particular term.
Use it carefully because broad text matching can produce unexpected matches.
Use Starts With
Starts With is useful when values follow a predictable pattern.
For example:
Order ID starts with ORD-
This can help validate or route structured values.
Numeric comparisons
Conditions can also be useful for numbers.
Example:
Budget > 50000
Then:
Route high-budget leads to your sales team.
Otherwise:
Send them to the standard sales path.
Date comparisons
Date-based conditions can be used when your stored data contains dates.
For example:
Appointment Date is before today.
or:
Subscription Expiry is within a certain period.
The available operators depend on the field type.
Match All vs Match Any
When using multiple conditions, you need to understand how they are combined.
Match All
Every condition must be true.
Example:
City = Mumbai
AND
Customer Type = VIP
Only Mumbai VIP customers match.
Match Any
At least one condition must be true.
Example:
City = Mumbai
OR
City = Delhi
Customers from either city match.
The current condition builder supports multiple conditions and a match mode for evaluating them together.
Example: VIP customer routing
Suppose:
Label = VIP
Your condition checks the available customer data.
If true:
You've reached our priority support team.
If false:
Please select your support category.
This creates different experiences for different customers.
Example: Lead qualification
Suppose your flow collected:
Budget = ₹100,000
Then:
Budget >= ₹100,000
↓
High-value lead
↓
Sales team
Otherwise:
Standard lead
Conditions and labels
Labels can help classify users.
Custom fields can store values.
Conditions can evaluate the stored values and determine what happens next.
That makes these three features work particularly well together:
Collect
→ Store
→ Check
→ Route
Conditions and User Input
A common pattern is:
Ask question
↓
User Input
↓
Save to custom field
↓
Condition
↓
Different path
For example:
What is your budget?
Customer:
75000
Save:
Budget = 75000
Then:
Budget > 50000
→ High-value lead path.
Conditions and sequences
Conditions can also be used to determine whether a customer should receive a particular follow-up path.
Example:
Already in Sales Sequence?
↓
Yes → Don't start again
No → Start Sales Sequence
This helps prevent duplicate automation.
Conditions and human support
Conditions can also help determine when a conversation needs human intervention.
Example:
Customer Type = Enterprise
→ Enterprise support
Otherwise:
→ Standard support
Don't make conditions too complicated
A flow with twenty nested conditions can become difficult to maintain.
Instead of:
Condition
↓
Condition
↓
Condition
↓
Condition
↓
Condition
consider simplifying the data model or splitting the process into smaller flows.
Test both branches
This is extremely important.
If you create:
True
and:
False
paths, test both.
Test with:
A customer who should match
A customer who should not match
Missing data
Unexpected values
What if the condition always returns false?
Check:
Field being checked
Actual stored value
Operator
Capitalization/format where relevant
Match mode
Whether the field contains a value at all
What if the condition always returns true?
Check whether your rule is too broad.
A Contains comparison can match more values than you expect.
Use conditions to make automation useful
The purpose of conditions isn't to make flows complicated.
It is to make them relevant.
Instead of:
Every customer gets the same experience.
you can build:
Customers get the experience that matches their situation.
That is where structured chatbot automation becomes much more powerful.