Checking the answers you collect

Asking for the right details covers what to collect and what shape it comes in — a string, an integer, an enum. This page is about the step after that: what counts as a good answer, once you know the shape.

A patient’s age is an integer. That alone accepts -4 and 9000 just as happily as 34. A vehicle number is a string. That alone accepts anything at all, including a customer typing the wrong thing entirely. The settings on this page close that gap — a number can have a sensible range, text can have a sensible length, and a handful of common shapes (an email, a phone number, a government ID) can be checked properly instead of just collected and hoped for.

You will find all of these in the same Fields to collect JSON box you already used to set name, type and required — they are just more keys on the same object.

required versus optional — what each one actually costs you

You already know required makes your assistant keep asking. What is worth saying plainly: required is a promise you’re making that this answer always exists. Tick it, and your assistant will not submit without it — it keeps trying, for as long as the conversation goes on. That is correct for a diagnostic clinic’s patient age: you cannot book a test without knowing who it is for.

Leave a field optional, and your assistant asks once, accepts silence, and moves on. This matters for everything else on this page too: a field left empty is never a violation of min, max, format or pattern. Those only ever look at an answer that was actually given. An optional email address that the customer never provides is not a “bad email” — it is simply not there. Only required decides whether that is allowed.

Numbers that have to make sense — min and max

On an integer or number field, add min, max, or both:

{"name": "patient_age", "type": "integer", "required": true,
 "min": 0, "max": 100,
 "description": "The patient's age in years."}

A diagnostic clinic asked for exactly this: patient age is required, and nobody who walks in is over 100. Without the bound, a mistyped "age": 1000 or an assistant that mis-hears “fourteen” as “forty” would sail straight into your records. With it, your assistant is told the range up front and will ask again rather than accept a number outside it.

You can set just min (a package weight that must be positive), just max (a discount percentage that cannot pass 100), or both. Both must be whole numbers on an integer field, and min cannot be greater than max — the Studio editor will refuse to save a range that cannot be satisfied.

Limits on text — max_length

Every answer on the platform is already cut off at 2000 characters — that is the ceiling, and nothing you set can raise it. What max_length lets you do is set a lower ceiling for a field where a shorter answer is what you actually want:

{"name": "delivery_note", "type": "string", "required": false, "max_length": 120,
 "description": "A short note for the delivery driver."}

Most free-text fields don’t need this at all — the platform’s 2000-character cap is already generous for a note or a description. Reach for max_length when a field is meant to be short and a long answer would be a sign something went wrong (a courier note that should be one line, not a paragraph), not as a default habit on every field.

Checking a shape you already know — format

Two shapes come built in, because they are common enough to be worth getting right once rather than leaving to a pattern you’d have to write yourself:

• format: "email" — refuses an answer with no @, a domain with no dot in it, or a phone number pasted where an email was asked for.
• format: "phone" — accepts a number written the way people actually write numbers: 9876543210, +919876543210, +1 (415) 555-2671. It refuses anything that isn’t phone-shaped end to end — "Order-1234567890", a bare "12345" too short to be a real number, or a sentence like "call me on 9876543210" with the digits buried inside prose.

{"name": "contact_email", "type": "string", "required": false, "format": "email",
 "description": "For sending the report, if they'd like one."}

There is no format for anything else — no PIN code, no vehicle number, no government ID. For those, you write your own rule with pattern.

Your own rule — pattern and message

pattern lets you describe a shape nothing built-in covers — a PAN number, a vehicle registration, a 6-digit pincode — using letters and digits placed in groups. You are not expected to already know how to write one of these; ask whoever is helping you set up the assistant, or describe the shape in plain words and let them turn it into the pattern. What you should know, because it changes how you write the field, are the two rules below.

A pattern is checked against the whole answer, not a piece of it. If you ask for a PAN number shaped like 5 letters, 4 digits, then a letter, your assistant will accept an answer that is exactly that shape and refuse everything else — including an answer that has the right shape somewhere inside a longer sentence, like “my PAN is ABCDE1234F I think”. You do not need to add anything to your pattern to get this — it is how every pattern on the platform behaves, always.

message is mandatory the moment you set a pattern, and it is the only part of this the customer ever sees or hears. Your assistant never reads the pattern itself out loud, and never shows it to the customer — a string like [A-Z]{5}[0-9]{4}[A-Z] would mean nothing to anyone who isn’t a developer, so it never leaves the field you typed it into. message is the plain sentence your assistant says instead, when an answer doesn’t match:

{"name": "pan_number", "type": "string", "required": true,
 "pattern": "[A-Z]{5}[0-9]{4}[A-Z]",
 "message": "That doesn't look like a PAN number — 5 letters, 4 digits, then a letter.",
 "description": "The customer's PAN, for the policy paperwork."}

Get a mismatched answer, and your assistant says something close to:

“That doesn’t look quite right — a PAN is 5 letters, 4 digits, then a letter, like ABCDE1234F. Could you check and send it again?”

That is the whole reason message exists. Write it as a sentence that helps the customer fix their answer, not as a description of what went wrong — “invalid format” tells nobody anything. A message that names the shape and gives an example does the actual work of getting a good answer on the second try instead of the fifth.

pattern can run to 200 characters and message to 300 — plenty for anything you will realistically write. message also cannot contain the characters ; (a semicolon and a space) — the platform uses exactly that to separate several problems in one refusal, and a message containing it would be read as two.

Where the check actually bites — enforced or advisory

These same constraints — min, max, max_length, format, pattern, message — show up in two different places in the Studio, and only one of them stops a bad answer from being recorded.

On an Action — the questionnaires this page and Asking for the right details are about — a constraint is enforced. Your assistant cannot submit until every answer satisfies it. This is a real gate.

Under Show advanced → Add your own fields, on the end-of-call summary tool (see Editing your assistant’s wording and outcomes), the same kind of field is advice only. A call must always be able to end — even one where the customer never gave a clean answer — so a constraint there guides what your assistant asks for and how, but nothing checks the value before it is written into the summary. Set max: 2026 on a car’s year there, and your assistant will try to get a sensible year; it will not refuse to end the call over a bad one.

⚠️ If you need a hard stop — an answer your assistant genuinely cannot proceed without, or cannot proceed with if it’s wrong — put that field on an Action. A constraint on the call-summary tool will never give you that; it was never built to.

Worked examples

A diagnostic clinic

[
  {"name": "patient_age", "type": "integer", "required": true,
   "min": 0, "max": 100,
   "description": "The patient's age in years."},
  {"name": "fasting_done", "type": "boolean", "required": false,
   "description": "Whether the patient has fasted, if the test needs it."},
  {"name": "patient_phone", "type": "string", "required": true, "format": "phone",
   "description": "A number we can call back on to confirm the booking."},
  {"name": "contact_email", "type": "string", "required": false, "format": "email",
   "description": "For sending the report, if they'd like one by email."}
]

Age is required and bounded because a booking cannot happen without it, and nobody walking in is over 100. Phone is required and format-checked because a confirmation call that can’t be made is a booking that silently fails later. Email is optional but still format-checked if given — a customer who skips it is fine; a customer who gives you a typo isn’t.

A car detailing studio

[
  {"name": "vehicle_reg_number", "type": "string", "required": true,
   "pattern": "[A-Z]{2}[0-9]{1,2}[A-Z]{1,3}[0-9]{4}",
   "message": "That doesn't look like a number plate — two letters, one or two digits, up to three letters, then four digits, like KL07AB1234.",
   "description": "The vehicle's registration/number plate."},
  {"name": "car_year", "type": "integer", "required": false,
   "min": 1980, "max": 2026,
   "description": "The year the car was made."}
]

The registration number is the pattern example on this page for a reason: there genuinely is no built-in format for it, and a wrong plate number means the wrong car gets scheduled. The year gets min/max instead of a pattern — it’s a plain number with a sensible range, and a pattern would be overkill.

An insurance or finance office

[
  {"name": "policy_number", "type": "string", "required": true, "max_length": 30,
   "description": "The existing policy this enquiry is about, if any."},
  {"name": "pan_number", "type": "string", "required": true,
   "pattern": "[A-Z]{5}[0-9]{4}[A-Z]",
   "message": "That doesn't look like a PAN number — 5 letters, 4 digits, then a letter.",
   "description": "Needed for the policy paperwork."}
]

A policy number is genuinely open-ended across insurers, so it stays free text with just a length cap. A PAN has one fixed national shape, so it earns a pattern — and the refusal message is what makes that pattern usable instead of just correct: a customer who fat-fingers a digit hears exactly what to fix, not a rejected form.

A courier or logistics service

[
  {"name": "delivery_pincode", "type": "string", "required": true,
   "pattern": "[0-9]{6}",
   "message": "Pincodes are 6 digits — could you send just the numbers?",
   "description": "The delivery address's pincode."},
  {"name": "package_weight_kg", "type": "number", "required": true,
   "min": 0.1, "max": 50,
   "description": "The package's weight in kilograms."}
]

A pincode has a fixed digit count everywhere in the country, so pattern earns its place again. Weight needs no pattern at all — it’s a plain number with real-world bounds, and min/max says everything that’s needed: nothing weighs zero or less, and nothing this business carries weighs more than 50kg.

A salon or a restaurant

[
  {"name": "party_size", "type": "integer", "required": true,
   "min": 1, "max": 20,
   "description": "How many people, including the person booking."},
  {"name": "preferred_time", "type": "string", "required": false,
   "enum": ["morning", "afternoon", "evening", "no_preference"],
   "description": "Roughly when they'd like to come in."}
]

Neither field here needs a pattern, format, or even max_length — this is the common case. A party size just needs a sane range, and a time preference is better handled with the enum you already know from Asking for the right details than with any kind of text validation at all.

When not to use a pattern

Most fields on most questionnaires need no pattern. Reach for one only when there’s a genuinely fixed shape a customer could otherwise get wrong in a way that matters — a government ID, a vehicle number, a pincode. If you’re not sure the shape is truly fixed, leave it off. An over-tight pattern that refuses a real customer’s real answer, and makes them retype it two or three times before your assistant accepts it, is worse for your business than having no pattern at all — a slightly messy but readable answer a human can make sense of later beats an irritated customer who gives up mid-booking.

A footnote for whoever writes the pattern for you

Patterns are checked with a fast, safe pattern-matching engine that deliberately refuses two advanced constructs: matching text against something matched earlier in the same pattern, and matching based on what comes immediately before or after a position without including it. You will never need either to describe a PAN number or a pincode. If a developer helping you writes a pattern using one and the Studio refuses to save it, that refusal is deliberate, not a bug to work around — those constructs can, on the wrong input, make a pattern match slower and slower without limit, and disallowing them keeps every pattern on the platform fast no matter what a customer types.

The limits, in one place

• min / max — numbers only; min cannot exceed max; both must be whole numbers on an integer field.
• max_length — text only; up to the platform’s 2000-character ceiling, never past it.
• format — text only; email or phone, nothing else.
• pattern — text only; up to 200 characters; must always come with a message.
• message — up to 300 characters; cannot contain ; .

Troubleshooting

My assistant accepted an answer I was sure the pattern should have refused

Check whether the field is required: false and the customer’s answer was genuinely absent, not just short — an empty or missing optional field never triggers pattern, format, min or max at all. If the field did have a value, check the pattern itself covers every valid form of a real answer, not just the one example you tested with.

I get invalid_fields when testing a constrained field

The message names the field and tells you which rule it broke — a number outside min/max, text past max_length, or an answer that didn’t match format/pattern. That is the same check your live customers will hit, so it’s the right place to notice a rule that’s stricter than you meant it to be.