# Basic concepts

Source: https://govform.com/resources/documentation/article/02-basic-concepts
Topic: Getting Started

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:

-   [Library settings](<https://govform.com/resources/documentation/article/20-library-settings>)
-   [Service settings](<https://govform.com/resources/documentation/article/21-01-service-identity-lifecycle-and-administration>)
-   [Condition settings](<https://govform.com/resources/documentation/article/26-condition-settings>)
-   [Shared action settings](<https://govform.com/resources/documentation/article/25-00-action-shared-settings>)