# 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](http://app.zazzyagent.com) to evaluate information and choose a different path depending on the result. ## What is a condition? A condition is a rule. For example: ```text Customer Type = VIP ``` If the rule is true, one path runs. If false, another path runs. A basic structure looks like: ```text 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: ```text 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: ```text 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: ```text 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: ```text 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: ```text Order ID starts with ORD- ``` This can help validate or route structured values. ## Numeric comparisons Conditions can also be useful for numbers. Example: ```text 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: ```text City = Mumbai AND Customer Type = VIP ``` Only Mumbai VIP customers match. ### Match Any At least one condition must be true. Example: ```text 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: ```text Budget >= ₹100,000 ↓ High-value lead ↓ Sales team ``` Otherwise: ```text 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: ```text 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: ```text 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: ```text 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: 1. Field being checked 2. Actual stored value 3. Operator 4. Capitalization/format where relevant 5. Match mode 6. 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.