> For the complete documentation index, see [llms.txt](https://docs.amltd.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.amltd.com/dc-works/core-concepts/pages-and-navigation.md).

# Pages and Navigation

**Pages** organize an Applet into screens. **Navigation** controls how users move between those screens as they complete a workflow.

A simple Applet may use one page, while a more involved workflow may use several pages for entering, reviewing, selecting, or updating information.

```mermaid
flowchart LR
    P1["Enter Information"] --> P2["Review"]
    P2 --> P3["Confirmation"]
    P2 --> P1
```

### Pages

Each page should generally support a clear step or purpose within the workflow.

For example, an Applet might include pages for:

* Entering or scanning information.
* Displaying search results.
* Reviewing a selected entry.
* Editing information.
* Confirming that an operation was completed.

Pages contain the fields, buttons, and other controls users interact with.

### Navigation

Navigation moves the user from one page to another. It may occur when:

* The user selects a button.
* A field or entry is selected.
* An action is completed.
* A condition is met.
* The user returns to a previous page.
* The workflow is completed or restarted.

Actions and conditions can direct users to different pages based on the information in Applet records.

```mermaid
flowchart TD
    S["Scan Item"] --> C{"Item Found?"}
    C -->|Yes| D["Item Details Page"]
    C -->|No| M["Item Not Found Page"]
```

### Design pages around the workflow

The page structure should follow the real-world process the user is completing.

Before creating pages, consider:

* What does the user need to do at each step?
* What information must be visible?
* What choices can the user make?
* What should happen after each choice?
* How can the user go back or cancel?
* Where does the workflow begin and end?

Avoid placing too many unrelated tasks on one page. A clear sequence of focused pages is often easier to use, especially on mobile devices.

### Maintain information between pages

Moving to another page does not necessarily mean starting with new information. Applet records can hold values as users move through the workflow.

For example, a user might:

1. Scan an asset on one page.
2. View the retrieved asset information on another page.
3. Enter transaction details on a third page.
4. Confirm and save the transaction.

The same Applet records can provide the working information needed throughout these steps.

{% hint style="info" %}
Pages organize the user experience. Applet records maintain the working information used across those pages.
{% endhint %}

### Keep navigation clear

Users should always understand:

* Where they are in the workflow.
* What they need to do next.
* How to return to the previous step.
* How to cancel or restart when appropriate.
* Whether an operation was completed successfully.

Use clear page names and button labels. Labels such as **Review Check-In**, **Save Transaction**, or **Return to Search** are more useful than generic labels such as **Next**, **Submit**, or **Back** when the intended action may not be obvious.

### The Getting Started example

The **Asset Check-In** Applet uses separate pages to:

* Enter asset check-in information.
* Display existing entries.
* Edit a selected entry.

Navigation allows users to move between these tasks, while Applet records carry information between the pages and actions interact with the Asset Check-In table.

Detailed page types, navigation actions, layouts, and field configuration will be covered later in the **Applets** section.

### Next

Continue to **Devices, Web Apps, and Deployment** to learn how Suites and Applets are made available to users.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.amltd.com/dc-works/core-concepts/pages-and-navigation.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.