Basic concepts
Understanding the Builder hierarchy makes it easier to choose the right setting and predict the effect of a change. A small change to a field can affect a condition, action, template and document later in the journey.
The hierarchy
| Level | What it contains | Why it matters |
|---|---|---|
| Library | services, users, shared settings and integrations | controls access and reusable organisational configuration |
| Service | the deployable digital journey | holds pages, service settings and deployment history |
| Page | one step in the journey | controls content, navigation, validation and page actions |
| Component | a question, content block, result or layout element | collects or presents information on a page |
| Selection item | one option in a choice component | has a stable stored value used by conditions |
| Condition | reusable true-or-false rule | controls visibility, validation, navigation or action execution |
| Action | work performed at a trigger point | looks up data, assigns values, sends messages or changes the route |
flowchart TD
L[Library] --> S[Service]
S --> P[Page]
P --> C[Component]
S --> K[Condition]
P --> A[Action]
C --> I[Selection item]Environments
Use each environment for a different purpose:
- Prototype / User view — quickly test content, validation and route logic. External dependencies can use safe mock or suppressed behaviour.
- QA — test the full service with test configuration, permissions and real integration behaviour.
- Production — the live service. Deploy only reviewed, approved and tested changes.
Do not treat a successful User view journey as proof that an external integration works. Test the real end-to-end operation in QA first.
Stable identifiers and data
Every data-capturing component has a Field ID. Conditions, Liquid templates, actions and integrations can rely on it, so it is a dependency rather than a display label. The same principle applies to selection item IDs, condition IDs and action IDs.
Choose short, meaningful IDs early and keep them stable. You can improve user-facing labels without changing an ID. If an ID must change, find every dependent condition, template, action and external mapping before deploying.
Conditions and actions have different roles
A condition evaluates whether a rule is true. An action performs work. Attach a condition to a page to control flow, a component to control relevance, validation to apply a requirement conditionally, or an action to decide whether it runs.
Use a condition for the decision; use an action only when the service must do something as a result. This keeps journeys easier to test and maintain.
Shared configuration and secrets
Library and service settings can provide shared access, branding, authentication and integrations. Keep credentials and environment-specific connection details in approved secure settings, not in page content, Liquid expressions, action names or source files.
Use the detailed guides when you need to configure a specific area: