> 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/planning-an-app-before-you-build.md).

# Planning an App Before You Build

Before building an Applet, take time to define the real-world process it will support. A clear plan helps determine what data, pages, records, actions, and conditions will be needed.

### Start with the workflow

Describe the process in plain language from beginning to end.

Consider:

* Who will use the Applet?
* What task are they completing?
* What begins the process?
* What information must they enter, scan, or view?
* What decisions occur?
* What should happen when the process succeeds or fails?
* How does the process end?

```mermaid
flowchart LR
    S["Start"] --> I["Collect Information"]
    I --> D{"Make Decision"}
    D -->|Continue| A["Perform Operation"]
    D -->|Stop| M["Notify User"]
```

### Identify the data

Determine what information the workflow requires and whether each value should be temporary or stored permanently.

Ask:

* Which information must be saved in a table?
* Which values are needed only while the Applet is running?
* Will the Applet create new table entries or update existing ones?
* Will it retrieve a single entry or a list of entries?
* Which information must be searchable or reportable?

This helps define the necessary databases, tables, fields, and Applet records.

### Plan the Applet

Outline the pages users will need and the purpose of each page.

For example:

1. Scan or enter information.
2. Display retrieved data.
3. Collect additional details.
4. Review the information.
5. Save the result.
6. Confirm completion.

You do not need to design every field immediately. Begin by identifying the major steps and how users should move between them.

### Identify actions and decisions

For each step, determine what DC Works must do.

This might include:

* Setting a record value.
* Retrieving table data.
* Checking whether information is valid.
* Moving to another page.
* Adding a new table entry.
* Updating an existing entry.
* Displaying a confirmation or error message.

At this stage, it is enough to describe the intended behavior. Detailed action and condition configuration can be completed while building the Applet.

### Consider deployment

Plan where and how the solution will be used.

Consider:

* Will it run on enrolled devices, as a Web App, or both?
* Does it require barcode scanning or other device features?
* Must it continue operating without a network connection?
* Which Applets should be grouped in the Suite?
* What screen sizes and working environments must be supported?

These decisions can affect the Applet’s layout, navigation, and data requirements.

### Recommended planning order

A practical order for planning a DC Works solution is:

1. Define the real-world workflow.
2. Identify the required information.
3. Structure the databases and tables.
4. Plan the Applet records and pages.
5. Build the necessary Applets.
6. Organize the Applets into Suites.
7. Deploy to devices or as Web Apps.
8. Test the complete workflow using representative data.

{% hint style="info" %}
Start with the process and its data—not with the appearance of the screens. The interface should support the workflow and data structure.
{% endhint %}

### Keep the first version focused

Begin with the simplest version that completes the required task. Test it with realistic users and data before adding optional features or additional workflow branches.

DC Works solutions can be revised and expanded as requirements become clearer.


---

# 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/planning-an-app-before-you-build.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.