# 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](https://botsailor.com/help/en/blog/setting-validation-rules-for-input-fields-in-botsailor?utm_source=chatgpt.com))

## Why validation matters

Without validation:

```text
Customer
   ↓
Bad data
   ↓
CRM / API
   ↓
Problem later
```

With validation:

```text
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:

> [rahul@example.com](mailto:rahul@example.com)

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](mailto: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:

```text
Question
   ↓
Customer answer
   ↓
Valid?
 ↙      ↘
Yes      No
 ↓        ↓
Save   Explain + retry
```

## Example: Email

```text
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:

```text
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:

```text
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.