Service navigation settings determine how a person starts or returns to a journey, where Continue and Back take them, and how answer documents are presented. These settings shape every route in the service, so configure them before final usability testing and re-test after any change to pages, conditions or review steps.

Choose the signed-in entry and exit model

The Signed-in service entry/exit mode controls the journey model for authenticated services.

Homepage mode requires an authenticated service. Design its start and resume choices as carefully as any other page: people should understand whether they are opening an existing journey or beginning a new one.

Set Continue and Back behaviour for the journey

The Builder’s Navigation settings offer three Continue behaviours:

You can also choose a page number from which the service always returns to Check your answers. Use this only when a long journey has a well-tested review pattern; a sudden change in Continue behaviour can be disorienting.

For the Back link, choose either Previous visited page for true history, or Previous journey page for a linear route that ignores skipped pages. Conditional journeys usually need careful testing here—people should not be sent to a page that does not apply or lose the context of an earlier decision.

flowchart TD
    A["Person changes an answer"] --> B{"Continue setting"}
    B -->|"Next page requiring attention"| C["Go to the next page needing work"]
    B -->|"Next page in journey"| D["Follow the configured route"]
    B -->|"Always go to Check answers"| E["Return to review when available"]
    C --> F["Test conditions, Back and direct links"]
    D --> F
    E --> F

Make review pages useful

A Check your answers page is not just a list of fields. Use its page-level settings to add a concise heading, instructions before the answers, a meaningful layout and clear declaration or submission content above the final action. Group answers by page when people need context, or use a flat layout when a compact summary is genuinely easier to scan.

Review content should tell people what they are confirming, how they can change an answer and what will happen after submission. Avoid putting critical policy information only in a declaration beneath a long answer list. Test each change link, the route back to review and any conditionally hidden answer.

Produce answer PDFs safely

The Answers playback page header content appears at the top of every answer-document page. It is raw HTML, so use it only for trusted, pre-reviewed markup. Keep it semantic, compact and suitable for repeated pages. A title or reference can be useful; a large banner, complex layout or untrusted dynamic data is not.

The downloadable document should be understandable when separated from the service. Use a meaningful answer-document title, include only approved information and check that content wraps cleanly on multiple pages. Never rely on colour or layout alone to explain a status in a document.

Test the complete navigation loop

1. Complete the standard route from start to finish.
2. Change answers from Check your answers and confirm the selected Continue behaviour.
3. Test every conditional branch, then use Back from each branch.
4. Test a saved draft and the signed-in entry model.
5. Download the answer document with short, long and missing optional answers.
6. Repeat in QA before deploying a navigation or document change.

Related guides

• Design pages and navigation
• Use conditions and branching
• Service authentication and user access
• Test, deploy and maintain a service