> ## Documentation Index
> Fetch the complete documentation index at: https://knowledge.flowella.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Form design best practices for WhatsApp Flows

> Design HubSpot forms that render cleanly as WhatsApp Flows: field label limits, choosing the right question type, and how to stop long questions being clipped on iPhone.

Every field in your HubSpot form becomes a component in a WhatsApp Flow, and Meta caps how much label text each component can display. Labels longer than the cap get clipped on the customer's phone, most noticeably on iPhone.

The Flow still publishes, and the answers still reach HubSpot correctly. The only consequence is visual, which is why this is easy to miss until a real customer opens the form.

This page covers how to build HubSpot forms that read well on every device.

## The short version

<CardGroup cols={2}>
  <Card title="Keep labels short" icon="type">
    Aim for 20 characters or fewer on dropdown and text fields. That is roughly three short words.
  </Card>

  <Card title="Use radio buttons for short lists" icon="circle-dot">
    Under eight options reads better as radio buttons than a dropdown, and gives you a longer label.
  </Card>

  <Card title="Put long questions above the field" icon="layers">
    Use a rich text element for the question and keep the field label itself short.
  </Card>

  <Card title="Test on an iPhone" icon="smartphone">
    Android is more forgiving. If it reads correctly on iPhone, it reads correctly everywhere.
  </Card>
</CardGroup>

## What happens to your field labels

Each HubSpot field type maps to a WhatsApp Flow component, and each component has its own label allowance. The fields people use most are the tightest.

| HubSpot field       | Renders as     | Label allowance    |
| ------------------- | -------------- | ------------------ |
| Dropdown select     | Dropdown       | 20 characters      |
| Single-line text    | Text input     | 20 characters      |
| Multi-line text     | Text area      | 20 characters      |
| Radio select        | Radio buttons  | 30 characters      |
| Multiple checkboxes | Checkbox group | 30 characters      |
| Date picker         | Date picker    | 40 characters      |
| Single checkbox     | Opt-in         | 120 characters     |
| Rich text           | Rich text      | No practical limit |

Option labels within a dropdown, radio group or checkbox group get 30 characters each, with 300 characters available for an optional description underneath.

<Note>
  These are guidance rather than hard limits. Meta's own Flow builder shows a warning, not an error, and a Flow with long labels validates and publishes normally. Nothing is broken, and no data is lost. The label is simply shortened on screen.
</Note>

## Why it looks fine on one phone and wrong on another

The character counts above are a guide, not a precise threshold. What actually decides whether a label is clipped is how much room the text has once the device has taken its share for padding, the chevron on a dropdown, and the customer's own font size setting.

That varies a lot. The same 33 character question can render in full on one Android handset, lose its last word on another, and be cut mid-word across two lines on an iPhone.

The practical consequences:

* **iPhone is the strictest surface.** Design for it and the rest follow.
* **Testing on one device is not enough.** A form that looks correct on your own phone can still be clipped for a large share of your audience.
* **Non-Latin scripts and wide characters run out of room sooner.** If you are collecting in Arabic, Hindi, Thai or Turkish, treat the character counts above as generous and aim shorter.

## Choosing the right question type

Most clipping problems come from using a dropdown where a dropdown was never the right control.

<AccordionGroup>
  <Accordion title="Two to seven options: use radio buttons">
    Set the field to **Radio select** in HubSpot. You get a 30 character label instead of 20, the label sits above the options as a block of text that wraps rather than being squeezed inside the control, and the customer answers with one tap instead of open, scroll, select, close.

    This is Meta's own recommendation, and it resolves the majority of clipped labels on its own.
  </Accordion>

  <Accordion title="Eight or more options: use a dropdown">
    Long lists belong in a dropdown. A country list or a product catalogue as twenty radio buttons is a wall of text.

    A dropdown holds up to 200 options. Radio and checkbox groups are capped at 20, so anything longer has to be a dropdown regardless of how the label reads.
  </Accordion>

  <Accordion title="Multiple answers: use checkboxes">
    **Multiple checkboxes** in HubSpot becomes a checkbox group, with the same 30 character label allowance as radio buttons and the same 20 option ceiling.
  </Accordion>

  <Accordion title="Yes or no: use radio buttons, not a dropdown">
    A two option dropdown is the worst case: the tightest label allowance on the shortest possible list, and two taps to answer a question that deserves one.
  </Accordion>
</AccordionGroup>

## Writing labels that fit

A WhatsApp Flow is a conversation, not a paper form. Short labels read better here even where there is room for more.

| Instead of                                    | Try            |
| --------------------------------------------- | -------------- |
| What is your preferred contact method?        | Contact method |
| Which of our services are you interested in?  | Service        |
| What is your approximate annual budget?       | Annual budget  |
| Please select your preferred appointment date | Preferred date |

A few rules that keep labels tight without losing meaning:

* Drop the polite scaffolding. "Please select your" and "What is your" add nothing on a phone.
* Use a noun, not a question, wherever the answer is obvious from the options.
* Move detail into the field's help text or an option description rather than the label.
* Put shared context in the screen heading instead of repeating it in every label.

## When the question genuinely needs to be long

Some questions cannot be shortened without changing what you are asking. A qualification question, a consent question or anything with a legal wording requirement needs its full text.

For these, put the question above the field and keep the field label minimal:

<Steps>
  <Step title="Add a rich text element">
    In the HubSpot form editor, drag a rich text element into position and enter the full question.
  </Step>

  <Step title="Add the field underneath">
    Place the dropdown, radio group or text field directly below it.
  </Step>

  <Step title="Give the field a minimal label">
    A single full stop works. The question is already above it, so the label is doing no work.
  </Step>

  <Step title="Repeat for each long question">
    Alternate rich text and field down the form so the pattern stays consistent.
  </Step>
</Steps>

The result reads as a question with an answer control underneath, which is what customers expect, and it renders identically on every device because the rich text has no length constraint.

<Warning>
  Use this pattern only where you need it. Every rich text element is an extra component, and a screen holds a maximum of 50. Mixing the pattern into a form where most labels are already short also makes the layout look uneven.
</Warning>

## How many questions to ask

Completion drops sharply as forms get longer, and WhatsApp is a more impatient surface than a web page.

* **Three or four questions per form** is a good target for a first touch. Ask the rest later in the conversation.
* **One task per screen.** If you are collecting an address and a delivery preference, use two screens.
* **Ten options per screen at most.** More than that and customers stop reading and start guessing.
* **Split long forms in two.** A short qualifying form followed by a conditional second form usually beats one long one, and it lets you branch on the first answer.

See [Lead capture and qualification](/hubspot/workflows/lead-capture-qualify) for a worked example of the two-form pattern.

## Before you sync

<Steps>
  <Step title="Read every label as it will appear">
    Count the characters on your dropdown and text field labels. Anything over 20 is at risk.
  </Step>

  <Step title="Check your field types">
    Any dropdown with fewer than eight options is a candidate for radio buttons.
  </Step>

  <Step title="Sync the form and open it in Meta">
    From the [Forms](/app/forms) detail page, sync the Flow and open it in Meta Business Suite. The Flow builder preview flags labels that are likely to be shortened.
  </Step>

  <Step title="Send it to a real iPhone">
    The builder preview is a guide. A handset is the only true test, and iPhone is the strictest one.
  </Step>

  <Step title="Check WhatsApp Web if your audience uses it">
    Controls render differently on a laptop. See [WhatsApp Web and Desktop](/app/whatsapp-web-desktop).
  </Step>
</Steps>

## Related

<CardGroup cols={2}>
  <Card title="Forms" icon="file-text" href="/app/forms">
    Sync your HubSpot forms to WhatsApp Flows and check their status.
  </Card>

  <Card title="WhatsApp Web and Desktop" icon="monitor" href="/app/whatsapp-web-desktop">
    How Flows render when customers reply from a laptop.
  </Card>

  <Card title="Workflow guides" icon="book-open" href="/hubspot/workflow-guides">
    End-to-end recipes that put these patterns to work.
  </Card>

  <Card title="HubSpot sync failures" icon="bug" href="/troubleshooting/hubspot-sync-failures">
    Diagnose forms that will not sync or submissions that never arrive.
  </Card>
</CardGroup>

Meta publishes the underlying constraints in its own documentation. For the full component reference, see [WhatsApp Flows components](https://developers.facebook.com/documentation/business-messaging/whatsapp/flows/guides/components), and for Meta's design guidance see [Flows best practices](https://developers.facebook.com/documentation/business-messaging/whatsapp/flows/guides/bestpractices).