> 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/applets/plan-your-applet-and-workflow.md).

# Plan Your Applet and Workflow

Before creating an Applet, define what it must accomplish and how users will move through the process.

Planning does not require every field, page, or action to be finalized. The objective is to establish a clear starting point for the Applet’s workflow, data, and user experience.

A simple plan should identify:

* The Applet’s purpose.
* Who will use it.
* Where and how it will be used.
* The information users need.
* The information users will enter or update.
* The main workflow steps.
* The pages likely to be required.
* The actions and decisions that move the process forward.
* The expected result when the process is completed.

### Define the Applet’s purpose

Begin with a short statement describing what the Applet will do.

For example:

> This Applet allows employees to check shared equipment in and out and update its current assignment and status.

A useful purpose statement identifies:

* The user.
* The task.
* The information involved.
* The intended result.

Keep the initial scope focused. If the purpose statement includes several unrelated processes, consider whether more than one Applet may be appropriate.

### Identify the users

Determine who will use the Applet and what each user needs to accomplish.

Consider:

* The user’s role.
* Their familiarity with the process.
* The information they need to see.
* The information they are permitted to change.
* Whether different users follow different paths.
* Whether approvals or supervisory actions are required.

An Applet intended for frequent warehouse scanning may require a different interface from one intended for occasional use in a web browser.

### Consider where the Applet will run

Identify how users will access the Applet:

* On an enrolled Android device.
* As a Web App.
* On both Android devices and through a web browser.

Also consider the expected operating environment:

* Will users scan barcodes?
* Will they enter information using a touchscreen or keyboard?
* Will they capture images or signatures?
* Will the device sometimes be offline?
* Will users wear gloves or work in a fast-paced environment?
* Does the process require large controls or minimal text entry?

These decisions influence page layout, field selection, navigation, and workflow design.

### Outline the workflow

Write the main process as a short sequence of steps.

For example:

1. Identify the equipment.
2. Retrieve its current information.
3. Select the required operation.
4. Enter or confirm the assignment details.
5. Update the record.
6. Display the result.

Focus first on the normal path—the sequence most users will follow most often.

A simple workflow can be represented as:

> Start → Identify → Review → Update → Confirm → Finish

This outline will later help determine the Applet’s pages, records, fields, actions, and conditions.

### Identify decisions and alternate paths

After defining the normal workflow, identify any point where the process may change direction.

Examples include:

* The scanned item is not found.
* The item is unavailable.
* Required information is missing.
* A value fails validation.
* The user cancels the operation.
* Approval is required.
* The Applet is temporarily offline.
* An update fails.

For each decision, determine:

* What condition causes the alternate path.
* What the user should see.
* What action the user can take.
* Whether the process can continue, retry, return, or must stop.

Do not attempt to plan every rare possibility initially. Concentrate on exceptions that are likely or that would prevent the process from completing correctly.

### Identify the required information

List the information the Applet must:

* Retrieve.
* Display.
* Collect.
* Calculate.
* Update.
* Retain temporarily.

This information may come from different sources within the Applet:

| Information requirement                           | Possible source                       |
| ------------------------------------------------- | ------------------------------------- |
| Existing stored information                       | A record connected to a table         |
| Information used only while the Applet is running | A local record                        |
| A collection containing multiple entries          | A list record                         |
| A single temporary value                          | A local variable                      |
| User input                                        | A field placed on an Applet page      |
| Derived information                               | An action, expression, or calculation |

At this stage, identify what information is needed and how long it must remain available. The exact records and variables will be configured after the Applet is created.

### Identify stored and temporary data

Determine which information must remain available after the Applet finishes and which information is needed only during the current process.

Information generally needs to be stored in a table when it must:

* Be available to other Applets or users.
* Be retrieved during a future session.
* Update an existing business record.
* Be reported, exported, or accessed through an API.

Information may remain local to the Applet when it is needed only to:

* Hold temporary user input.
* control navigation or workflow decisions.
* Build a value before saving it.
* Display a temporary result.
* Support calculations or intermediate steps.

This distinction will help determine which table-based records, local records, list records, and local variables the Applet requires.

### Sketch the Applet pages

List the pages users are likely to need.

Possible page purposes include:

* Starting or selecting an operation.
* Scanning or entering an identifier.
* Displaying retrieved information.
* Collecting information.
* Reviewing an entry.
* Confirming completion.
* Displaying an error or exception.

A simple page plan might look like:

| Page purpose | User activity                       |
| ------------ | ----------------------------------- |
| Start        | Select an operation                 |
| Identify     | Scan or enter an identifier         |
| Details      | Review and update information       |
| Confirmation | Verify that the operation succeeded |

The page plan is preliminary. Pages can be combined, divided, reordered, or removed as the Applet is built and tested.

### Identify important actions

For each workflow step, identify what the Applet must do.

Common actions include:

* Retrieve a record.
* Add a record.
* Update a record.
* Clear temporary values.
* Validate an entry.
* Navigate to another page.
* Display a message.
* Set a local variable.
* Add or remove an item from a list.
* Call an API.
* Complete or restart the process.

Actions can occur when a user selects a control or when an Applet event occurs, such as a page loading.

Detailed action configuration is covered later in **Actions, Events, and Conditions**.

### Define the expected result

Determine what must be true when the Applet completes successfully.

For example:

* The correct table record was updated.
* Required information was captured.
* The user received a clear confirmation.
* Temporary values were cleared.
* The Applet returned to the appropriate starting point.
* Another user or system can access the updated information.

This provides a practical basis for testing the Applet later.

### Keep the first version manageable

The initial Applet should support the essential workflow without unnecessary complexity.

Before beginning the build, confirm that:

* The Applet has one clear purpose.
* The main users are identified.
* The normal workflow is understood.
* Important exceptions have been considered.
* Required information has been listed.
* Stored information is distinguished from temporary information.
* The likely pages and actions are identified.
* The expected result is clear.
* Features not required for the initial process have been deferred.

{% hint style="info" %}
Begin with the smallest Applet that completes the required process reliably. Additional pages, actions, and exception handling can be introduced after the primary workflow has been tested.
{% endhint %}

### Planning summary

A completed Applet plan should provide concise answers to the following questions:

| Planning question                                 | Answer |
| ------------------------------------------------- | ------ |
| What does the Applet accomplish?                  |        |
| Who will use it?                                  |        |
| Where will it run?                                |        |
| What are the main workflow steps?                 |        |
| What information must it retrieve?                |        |
| What information must users enter or update?      |        |
| What information must be stored?                  |        |
| What information is temporary?                    |        |
| What pages are likely to be required?             |        |
| What important actions or decisions are required? |        |
| What indicates successful completion?             |        |

The plan does not need to define every configuration detail. It should provide enough direction to prepare the data structure and begin building the Applet.

### Next

Continue to **Prepare Your Data Structure** to confirm that the required databases, tables, and fields are available before creating and configuring the Applet.


---

# 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/applets/plan-your-applet-and-workflow.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.