Glossary and troubleshooting
Use this guide to orient yourself in Builder terminology and make a first, structured check when a service does not behave as expected. For configuration changes, test in a safe service or QA before deploying.
Glossary
| Term | Meaning |
|---|---|
| Action | an operation that runs at a defined point in a journey, such as a lookup, email or redirect |
| Acknowledgement page | the page that confirms completion and explains what happens next |
| Check answers | a review page showing answers before a person submits or completes work |
| Component | a question, content, result or layout element placed on a page |
| Condition | a reusable true-or-false decision used for visibility, validation, flow or action execution |
| Data feed | a managed tabular source used for a feed lookup or dynamic choice |
| Environment | a runtime context such as Prototype, QA or Production, with its own configuration and deployment |
| Field ID | the stable case-sensitive identifier for a component’s answer |
| Library | a collection of services with shared access, settings, branding and integrations |
| Liquid | the template language used to insert or transform runtime values |
| Markdown | lightweight formatting used in supported content settings |
| Page | one screen or workflow step in a service journey |
| Pattern | one or more reusable library pages that are copied into a service and can then be customised independently |
| Property | a named, non-sensitive environment value available to services through the library Liquid context |
| Secret | a named environment credential stored separately and never displayed back after entry |
| Selection item | one option inside a radio, checkbox or select component |
| Service | a deployable digital application made from pages, rules and integrations |
| Task list | a progress page that organises a larger service into tasks or sections |
| User view | the Builder preview used to try the service journey before deployment |
| Version | a saved state of the service that can be inspected, restored or selected for deployment |
Start every investigation with evidence
Before changing anything, record the service, page, environment, expected behaviour, actual behaviour, relevant answer values and time of the test. Reproduce the issue in QA where possible. This makes it easier to distinguish a content issue from a configuration or external dependency issue.
flowchart LR
A[Reproduce safely] --> B[Check visible configuration]
B --> C[Check conditions and action results]
C --> D[Test the affected route in QA]
D --> E[Make a focused change and retest]Do not fix a symptom by broadly disabling a condition or action. Identify the rule or dependency that should change, then test both the corrected route and the routes that should remain unaffected.
A page or component does not appear
Check the page or component’s visibility condition, the condition’s AND/OR logic, any inverse option and the current answer values. Confirm that the condition is attached in the intended place: an action condition does not control page visibility.
Test the route from the beginning and with back navigation. A value from a prior draft or an earlier page can change the result from a clean new journey.
A choice condition never passes
Use the choice operator and compare against the selection item ID, not the displayed choice text. Check the item ID is unique and stable, then test the exact option in User view.
For checkboxes, confirm whether the condition should look for one selected item or a combination of items. For dynamic choices, verify the source data still supplies the expected item identity.
An action does not run or has the wrong result
Check the trigger, action execution conditions, button filter and action order. A redirect before another action can prevent that later action from running. Ensure required fields or earlier action results exist when the action starts.
For integrations, inspect the action result and test safe normal, no-match, failure and retry routes in QA. Do not test with live credentials or sensitive data merely to diagnose a configuration problem.
Liquid output is blank
Check the exact case-sensitive field or action ID, the value path and the point in the lifecycle at which the template runs. Test missing and optional values explicitly. An action result is not available before the action has run successfully.
Use a small temporary content component in a safe QA service to inspect an expected non-sensitive value, then remove it after diagnosis.
A file, list or connected-source action fails
Check the environment-specific connection, access permissions, target site or list, path, source-file structure and action order. A successful connection test does not prove a real upload, lookup or list write will work.
Confirm that QA and production use their intended destinations. Never solve a QA connection issue by pointing the service at a live operational destination.
A task does not complete or a journey loops
Check the task end page, required answers, task navigation mode and any conditions that can skip a step. For loops, inspect redirects, reload actions and back-history behaviour. Test a fresh journey, a changed answer and a resumed draft.
When to escalate
Escalate with the service and environment, reproduction steps, expected and actual outcomes, relevant non-sensitive IDs, error/result details and the time of the test. Do not include secrets, API keys, access tokens, client credentials or personal information in an escalation.