A task list gives people a clear home page for a longer, multi-part service. It shows the work still to do, what is available now, and what has been completed. Use it when people may need to return over time or when several meaningful sections must be completed; for a short linear form, ordinary page navigation is usually simpler.

Design the tasks before adding the task list

Think of each task as a self-contained piece of work that has a recognisable start and finish. Give it a plain-language name and make sure people can understand what they need to do before selecting it.

Create the task pages and their end pages first. Every task must contain at least two pages and must end at one of these page types:

• a Check your answers page
• a page configured as a task overview
• the final acknowledgement page

Only after those end pages exist should you add the Task List page from the special page templates. The task list is the first page of a task-list service and links each task to its configured start and end point.

flowchart TD
    A["Create task pages"] --> B["Add a task end page"]
    B --> C["Repeat for every task"]
    C --> D["Add Task List as the first page"]
    D --> E["Group tasks into steps"]
    E --> F["Set dependencies only where needed"]
    F --> G["Test every task state in User view"]

Build clear task groups

Use steps to group related tasks, not as a substitute for a long list of unrelated work. A useful step heading tells someone what they are completing, such as Your organisation details or Supporting information. Keep the number of tasks in a step manageable, and use task titles that begin with an action where that makes the next step clearer.

Each task can direct the person to its first page, its first unanswered page, or its Check your answers page. Choose the behaviour that helps somebody resume confidently. If people commonly return to correct or review a section, taking them to Check your answers can be useful; if a task is often left part-way through, the first unanswered page is usually more helpful.

Use dependencies only for real prerequisites

Make a task dependent on an earlier task only when the person genuinely cannot begin it yet. A dependency creates a Cannot start yet state, so unnecessary dependencies can make the service feel restrictive and hide useful preparation work.

Before adding one, ask:

• Does the later task need an answer or outcome from the earlier task?
• Could the person complete some of the later task safely before that answer is available?
• Can the task title or guidance explain the prerequisite instead?

If you do use a dependency, test what happens when the earlier task is returned for changes or becomes unavailable through a condition.

Understand the task states

The Not required state depends on page visibility conditions, not on field visibility or validation conditions. If a task should not apply, make the task’s pages consistently conditional and test the route with the answers that exclude it.

Configure the task-list page

On the Task List page, configure the list of steps and tasks, plus any support content people need while they work. You can choose whether to show a reference number and task progress, add different introductory content before and after all tasks are complete, and choose the wording of the return link shown on task pages.

Keep any reference number explanation short and useful. If the service permits people to start over, decide whether the task list should show a Delete and start again link and make the consequence clear. This should match the service’s saved-draft and retention approach.

Important: The normal saved-draft options that automatically resume or delete a draft are not available where a Task List or Review workflow is present. Check the navigation behaviour in User view, rather than assuming it matches a simple linear service.

Finish the whole service deliberately

Use the task-list completion trigger for work that genuinely belongs after all tasks have been completed. The completion page should tell the person whether the submission is final, whether someone will review it, and how they will receive updates. If a workflow follows, make the change in status clear so people do not expect to keep editing a completed task list.

Test the real-life routes

Test with separate journeys for each state, not just one successful completion.

1. Start a new journey and complete tasks in the planned order.
2. Leave a task part-way through, return to the task list, and check the resume route.
3. Complete a prerequisite task and confirm that a dependent task becomes available.
4. Use answers that make an entire conditional task not required.
5. Change an answer after completion and check task status, review links and completion content.
6. Complete the full task list, including any downstream workflow, in QA.

Related guides

• Design pages and navigation
• Use conditions and branching
• Add actions and workflows
• Test, deploy and maintain a service