Forms: collect data inside a conversation

A form in Arino One is a short set of questions asked inside a conversation, with each answer written back to the contact record as an attribute or tag. You build one in Forms → New form, map every field to a contact attribute, attach it to the chat widget or to an automation step, and test a submission end to end before real traffic sees it. The point of a form is not the questions — it's that the answers become structured data you can segment, route and report on.

What forms are for

Most teams reach for forms in four situations: qualifying an inbound lead before an agent picks it up, triaging a support request so it lands with the right team, collecting a booking or callback request, and capturing consent alongside a first-party detail like a phone number or postcode. In each case, the value is that the answer stops being free text in a transcript and becomes a field on the contact.

That distinction matters for everything downstream. A "budget" answer stored as a contact attribute can drive segment membership, automation branching and campaign targeting. The same answer typed into a chat and read by an agent can't.

Where a form can run

On the widget the whole form appears at once. On messaging channels it becomes a sequence: the automation asks a question, waits for the reply, validates it, and moves on. Keep messaging-channel forms shorter than widget forms — every question is a separate message the contact has to answer, and drop-off climbs quickly after four or five.

Building the form

1. Create it in Forms → New form and name it after the job it does. You'll be picking it from a list inside the flow builder later, so "Lead qualification — inbound" beats "Form 3".
2. Add fields, one per answer you need. Field types (text, number, email, phone, date, single choice, multiple choice) drive validation, so pick the specific type rather than defaulting everything to text — a phone field catches a malformed number at entry instead of at send time.
3. Mark required fields sparingly. Every required field is a place a contact can abandon. If you can infer it, derive it or ask later, don't require it now.
4. Map each field to a contact attribute or tag. This is the step people skip, and skipping it is what turns a form into a transcript. Create the attribute first in the contact schema if it doesn't exist yet.
5. Set the completion behaviour: send a confirmation message, assign the conversation to a team, hand off to an automation, or any combination.

Wiring the submission into an automation

"Form submitted" is a trigger in the flow builder, and the submitted answers are available as conditions. A standard pattern looks like this: form submitted → condition on the qualifying answer → assign high-intent contacts to the sales team and send an approved template, or tag everyone else for a nurture campaign. See build your first automation for how triggers, conditions and actions fit together.

Because answers are on the contact record, you can also use them in segments with no extra work — a segment of "contacts whose form answer said 'this quarter'" is just an attribute filter.

Consent inside a form

Forms are a good place to capture marketing opt-in because the wording and the timestamp are recorded together. Use an explicit, unticked opt-in field, phrase it in plain language naming the channel ("Yes, send me offers on WhatsApp"), and map it to the contact's marketing consent attribute. Keep transactional and marketing consent as separate fields so an opt-out from one never silently breaks the other. Consent and opt-in covers what your evidence needs to contain.

Deployment tips

• Test with a real contact record open. Submit the form yourself, then check the contact and confirm each answer landed on the intended attribute with the expected format. Field-to-attribute mapping errors are silent and only surface weeks later as an empty segment.
• Keep messaging-channel forms to four questions or fewer. Anything longer belongs on the widget or a linked page.
• Handle abandonment deliberately. Partial answers are saved, so add a follow-up automation that resumes from the first unanswered field rather than restarting the form.
• Validate before you branch. If an automation branches on a form answer, add a fallback branch for unexpected or empty values so contacts can't get stuck mid-flow.
• Watch the first day of live submissions in the run log the way you would a new automation, and check the completion rate — a sharp drop at one question usually means that question is unclear or shouldn't be required.
• Version by copying. When you want to change a live form materially, duplicate it and switch the automation over, so historical answers stay attached to the form that produced them.

Billing

Forms are part of the flat $50/month instance connection and management fee. Any message a form sends on a metered channel — a WhatsApp question, an SMS confirmation — is billed as a normal message on that channel. See billing and plans for rates.

Steps at a glance

1. Create the formGo to Forms → New form, name it after the job it does (for example 'Lead qualification' or 'Support triage') so it's recognisable in automations later.
2. Add your fieldsAdd one field per answer you need, choosing the right type — text, number, email, phone, date, single choice or multiple choice — and mark only the truly required ones as required.
3. Map each field to the contact recordPoint every field at a contact attribute or tag so the answer is stored on the contact, not just in the conversation transcript.
4. Set the completion behaviourChoose what happens on submit: a confirmation message, assignment to a team, or handing off to an automation.
5. Attach the form to a surfacePublish it on the chat widget, as an automation step in a WhatsApp or SMS conversation, or behind a QR opt-in link.
6. Test end to endSubmit the form yourself, then open the contact record and confirm every answer landed on the right attribute before you point real traffic at it.

Frequently asked