This guide takes you through a small, complete service: collect a short set of answers, let the person review them and show a clear completion message. Build this simple version first; add conditions and integrations only after the core journey works.

Plan before opening Builder

Write down the person’s goal, the information you genuinely need, the completion outcome and the team that will act on it. Sketch the shortest sensible route. For a first service, avoid designing several branches, external calls or file uploads until the basic path is clear.

flowchart LR
  A[Start] --> B[Ask focused questions]
  B --> C[Check answers]
  C --> D[Complete]
  D --> E[Explain next steps]

Create the service

1. Open the appropriate library and choose to create a service.
2. Give it a clear name and a stable, readable Service ID.
3. Start with the default or blank structure that best supports a simple journey.
4. Open the service overview and use Add page to create the first question page.

Choose the library carefully. Its people, authentication, integrations and deployment controls may apply to your service.

Add pages and questions

Create a small sequence of pages. On each page, use Page content to add the component that best matches the information you need.

1. Set a clear page title or instruction.
2. Add a component, write its label as a question or direct instruction, and add a hint only where it helps.
3. Choose a stable Field ID for every value you will use later.
4. Configure validation that tells the person how to fix an error.
5. Use User view to try the page before adding the next one.

Use one primary question per page when that makes the task easier to understand. Group closely related information only when people naturally answer it together.

Add review and completion

Add a check-answers page so the person can review the information before completing the service. Then add an acknowledgement page that confirms the outcome and explains what happens next, including any reference, expected timescale or contact route.

Make the acknowledgement useful without relying on an email. A person should know whether the service was completed and what to do next even if a message is delayed or unavailable.

Add a simple branch only when needed

For a short same-page follow-up, use a revealing choice. For a route that changes the next page or several later steps, create a reusable condition and attach it to the relevant page or action.

Test every route from the beginning. Check a person can go back, change an answer and receive the correct next page without stale information appearing in the review.

Test before deployment

In User view, test:

• the normal completion route;
• required-field errors and invalid values;
• empty optional values;
• every conditional branch;
• back navigation and changed answers; and
• the review and acknowledgement content.

When the service includes real integrations, deploy to QA and test using safe representative data. Check the result in the receiving system, not only the Builder page.

Prepare the release

Review service settings, access, navigation, accessibility information and retention or integration requirements. Record approval, deploy the tested version to the intended environment and keep an owner for ongoing changes and support.

Next steps

• Design pages and navigation
• Add and configure components
• Use conditions and branching
• Test, deploy and maintain a service