How to Validate User Input in ZazzyAgent
Collecting information is only useful when the information is correct.
Suppose your flow asks:
What's your email address?
A customer accidentally types:
rahul@
If your automation accepts it without validation, the bad value can later be sent to your CRM, API or sales team.
Validation helps prevent that.
What is input validation?
Validation checks whether the customer's response matches the rules you've defined.
For example:
Email must be a valid email address.
or:
Age must be a number.
The current User Input functionality provides validation rules for supported input types. (botsailor.com)
Why validation matters
Without validation:
Customer
↓
Bad data
↓
CRM / API
↓
Problem later
With validation:
Customer
↓
Validate
↓
Valid → Save
Invalid → Ask again
Required vs optional
These are different concepts.
Required
Customer must provide an answer.
Example:
Name
Optional
Customer can continue without answering.
Example:
Additional comments
Only make fields required when your workflow actually needs them.
Validate email addresses
If the field is intended to collect email, use the appropriate email input type or validation.
A valid example:
An invalid example:
rahul@
This prevents obvious formatting problems.
Validate phone numbers
Phone numbers need careful handling.
Decide what format your business expects.
For WhatsApp-related workflows, international formatting is often important.
For example:
+919XXXXXXXXX
Rather than an ambiguous local format.
Validate numbers
Suppose you ask:
What is your budget?
You probably want a number.
A response such as:
Maybe around fifty thousand
is different from:
50000
Consider whether your workflow needs strict numeric input or whether free text is more appropriate.
Set minimum and maximum values
For fields that represent numbers or lengths, use sensible limits where supported.
Example:
Company size must be greater than 0.
or:
PIN must contain exactly 6 digits.
The exact available validation controls depend on the input type.
Validate text length
Some information shouldn't be extremely short.
For example:
Describe your requirement.
A one-character answer may not be useful.
You can use appropriate length rules where supported.
Invalid response message
A customer should understand what went wrong.
Bad:
Invalid input.
Better:
Please enter a valid email address, such as name@example.com.
The message should explain what the customer needs to correct.
Let customers try again
A validation failure shouldn't end the conversation.
The usual structure is:
Question
↓
Customer answer
↓
Valid?
↙ ↘
Yes No
↓ ↓
Save Explain + retry
Example: Email
Enter your email address.
↓
User Input
↓
Valid?
↙ ↘
Yes No
↓ ↓
Save "Please enter a valid email."
Example: OTP/PIN
If you're asking for a fixed-length value:
Enter your 6-digit PIN.
You can validate the expected number and length where the input configuration supports it.
Example: Age
If your process requires an age:
Enter your age.
Your validation rules can prevent obviously invalid values.
Validation before an API
This is especially important.
Imagine:
Customer enters Order ID
↓
Validation
↓
HTTP API
The API only receives a value that meets your input requirements.
This reduces unnecessary API calls and bad requests.
Validation before CRM submission
The same principle applies when sending leads to a CRM.
Don't send:
invalid-email@
to your external system and discover the problem later.
Validate first.
Validation and User Input
Validation is part of the data-collection process.
A useful architecture is:
Ask
↓
Collect
↓
Validate
↓
Save
↓
Use
Don't over-validate
Validation should prevent bad data, not make the form impossible to complete.
For example, if a customer says:
My budget is around ₹50,000.
and your workflow doesn't require a strict number, don't force them through a rigid numeric field unnecessarily.
Use the least restrictive format that still gives you usable information.
Test invalid answers
Don't test only the correct answer.
For every important field, test:
Correct
Empty
Too short
Too long
Wrong format
Unexpected value
Common validation problems
Correct input is rejected
Your validation rule may be too restrictive.
Invalid input is accepted
The validation may not match the actual data requirement.
Customer gets stuck
Check that the invalid path lets them try again.
Data is saved incorrectly
Check the input type and destination field.
Good validation design
The customer should know:
What information do you need?
What format should I use?
What happens if I make a mistake?
That is much better than silently rejecting input.
The rule to remember
Validate data at the point where you collect it.
Fixing bad customer data later is usually harder than preventing it in the first place.