> 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/devices-web-apps-and-deployment.md).

# Devices, Web Apps, and Deployment

After Applets have been organized into a Suite, the Suite can be made available to users on enrolled devices or as a Web App.

```mermaid
flowchart TD
    A["Applets"] --> S["Suite"]
    S --> D["Enrolled Devices"]
    S --> W["Web App"]
```

### Enrolled devices

On a mobile device, users run the Suite through the DC Works application.

The device must first be enrolled in the Suite. Enrollment connects the device to the appropriate Suite and makes its Applets available to the user.

A device is generally the best choice when the workflow requires:

* Barcode scanning.
* Mobile or handheld operation.
* Use of supported device hardware.
* Operation away from a desk.
* Offline data collection.

### Web Apps

A Suite can also be accessed as a Web App through a supported web browser.

Web Apps are useful for workflows such as:

* Desktop data entry.
* Reviewing or updating information.
* Supervisory tasks.
* Access from a computer without installing the mobile application.

Access to a Web App is provided to authorized Web Users.

{% hint style="info" %}
The same Suite can support both enrolled devices and Web Apps. However, the layout and workflow should be tested for each type of access.
{% endhint %}

### Deployment

**Deployment** is the process of making a Suite and its Applets available to the intended users and devices.

A typical deployment follows this structure:

```mermaid
flowchart LR
    B["Build and Test Applets"] --> S["Add Applets to Suite"]
    S --> C["Configure Access"]
    C --> R["Run on Device or Web"]
```

Deployment may include:

* Adding the required Applets to a Suite.
* Enrolling mobile devices in the Suite.
* Providing Web Users with access.
* Testing the complete workflow in its intended environment.

Applets can be tested within the Applet Designer. A Suite must be run on an enrolled device or as a Web App to test the complete user experience.

### Plan for how the solution will be used

Consider the deployment environment while planning the solution—not only after it has been built.

Ask:

* Will users work on handheld devices, computers, or both?
* Does the workflow require barcode scanning?
* Will the device always have a network connection?
* Does the interface fit the intended screen size?
* Which users or devices should receive the Suite?
* Will different groups need different Suites?
* How will updates be tested before wider use?

These decisions may affect the Applet layout, navigation, data structure, and workflow.

### Devices and Web Apps may serve different roles

A single solution can use devices and Web Apps for different parts of the process.

For example:

```mermaid
flowchart LR
    D["Warehouse Device"] --> T["Shared Table Data"]
    T --> W["Supervisor Web App"]
```

A warehouse employee might scan and record inventory on a handheld device, while a supervisor reviews or updates the same information through a Web App.

Both interfaces can work with the same underlying tables while providing experiences suited to their users.

### The Getting Started example

In Getting Started, the **Asset Check-In** Applet was added to the **Getting Started** Suite. The Suite was then made available by enrolling a mobile device.

The Applet contains the workflow, the Suite provides the launcher, and deployment makes the solution available for use.

### Next

Continue to **Offline Operation and Synchronization** to learn how DC Works supports work when a device temporarily loses its network connection.


---

# 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/devices-web-apps-and-deployment.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.
