Add and configure components
Components are the building blocks on a page. Use them to collect information, show guidance, structure complex content and help people complete a service accurately.
Add a component to a page
Open the page in the Builder and select Add component. The component library is grouped into categories, including text content, text input, selection, date and time, files and media, buttons, address and location, structure, and search. You can also search the library by name.
Choose the component that best matches the information you need to collect or display. The Builder then adds it to the page, where you can open its settings from the component itself. Use the page preview as a working view of the participant-facing screen, but always verify it in User view as well.
Choose the simplest suitable component
| Component type | Use it for |
|---|---|
| Text input and textarea | Short, free-text answers and longer explanations. Choose a textarea only when people genuinely need more than a brief answer. |
| Radios, checkboxes and select | Radios for one choice from a short visible list; checkboxes when several answers may apply; select when a longer list would make the page difficult to scan. |
| Date and time | An answer that needs predictable structure, validation or later reuse in a template or action. |
| File, signature and document | A service that needs a file, signed acknowledgement or document-based task. Explain format, content and timing requirements before the component. |
| Content and structure | Standard content, alerts, inset text, warnings, accordions, tables, tabs and layout components that make complex information easier to understand. |
Prefer a recognisable answer format over a clever layout. A component should make it obvious what the person is being asked to provide and how their answer will be used in the journey.
Configure the content people see
Select a component on the page to open its settings pane. The exact options vary by component type, but data-capturing components commonly have Content settings, Format validation, Conditional validation, Visibility, Pre-population and Flow simulation tabs.
Start with the content settings. Write a Field label that tells people what to enter. Add hint text when it prevents a likely mistake, explains an unfamiliar term or gives a useful example. If the review page needs a shorter or clearer description, set a dedicated Check your answers label rather than changing a useful question label just to fit the review page.
Some text areas support Liquid content and Markdown or HTML. Keep ordinary labels and hints plain unless dynamic content is necessary; dynamic content should be tested with missing, long and unexpected values.
Treat the Field ID as a stable data name
Every component that captures data needs a unique Field ID. The Builder describes it as a short, unique identifier using alphanumeric characters with no spaces. Use a concise, meaningful name such as contactEmail or preferredContactMethod, rather than a label copied word-for-word.
Field IDs connect answers to conditions, actions, templates, analytics and integrations. Set them deliberately before building those connections. Renaming an established Field ID can break references elsewhere in the service, so search and test dependent behaviour before making a change.
Component configuration lifecycle
flowchart LR
A["Choose the answer or content need"] --> B["Add the simplest component"]
B --> C["Set label, hint and Field ID"]
C --> D["Add proportionate validation"]
D --> E["Check review-page display"]
E --> F["Test in User view and QA"]Make validation helpful
Choose a content type and format rules that fit the real answer. For example, text-input settings can apply an input type, word limit, text modifications and an input width. These are not substitutes for clear wording: explain the required answer first, then use validation to prevent errors that the service cannot accept.
- Make an answer required only when the service cannot proceed without it.
- Use format validation for a known format, not merely to make an answer look tidy.
- Use conditional validation when an answer is required only on a particular route.
- Set a word limit only when it reflects a genuine limit on what can be processed.
- Check error messages tell people what needs fixing and how to fix it.
Control review-page presentation
For a component shown on Check your answers, you can keep the default label-and-answer layout, display the answer across the full width, or omit the component from that review page. Use the full-width format for content that needs more reading space. Omit only when the value should not be reviewed there; do not hide an answer simply because its label is difficult to write.
Important: Do not rely on the Builder canvas alone for validation and visibility checks. Test the component in User view with realistic answers, including blank, pasted, very long and unexpected values.
Check each new component
- Read the label and hint without looking at the settings: is the requested answer unambiguous?
- Enter a valid answer and confirm it appears correctly on Check your answers.
- Try the likely errors, including missing answers where the component is required.
- Follow any conditional route that shows, hides or depends on the component.
- Repeat the test in QA before deploying the change.