> 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/how-dc-works-is-organized.md).

# How DC Works Is Organized

DC Works brings together data storage, Applet design, workflow logic, and deployment within one platform.

A solution generally consists of several connected components:

```mermaid
flowchart TD
    D["Databases and Tables"] --> A["Applets"]
    A --> S["Suites"]
    S --> M["Enrolled Devices"]
    S --> W["Web Apps"]
```

### The DC Works Designer

The **DC Works Designer** is the web-based interface used to create and manage a DC Works solution.

From the Designer, you can:

* Create databases and tables.
* Build and test Applets.
* Create Suites and add Applets to them.
* Generate enrollment barcodes for mobile devices.
* Manage users and device access.
* Configure other solution and account settings.

The Designer is where a solution is built and managed. Users interact with the completed solution on enrolled devices or through a Web App.

### Databases and tables

Databases and tables provide the data structure behind a solution.

* A **database** organizes related tables.
* A **table** stores a particular type of information.
* A **record** represents one stored item, transaction, or entry.
* Each record contains values organized into table fields.

For example, the Getting Started tutorial created a table for recording asset check-ins. Each check-in becomes a record in that table.

The data structure should usually be planned before the Applet is designed.

### Applets

An **Applet** is the part of the solution users interact with to complete a particular task or workflow.

An Applet can contain:

* One or more pages.
* Data-entry and display fields.
* Buttons and navigation controls.
* Records connected to table data.
* Actions and conditions that control its behavior.

Applets can capture, display, search, and update information stored in DC Works tables.

In the Getting Started tutorial, the **Asset Check-In** Applet provides the screens and controls used to work with asset check-in records.

{% hint style="info" %}
Applets are created before they are added to Suites. An Applet may also be reused in more than one Suite.
{% endhint %}

### Suites

A **Suite** organizes one or more Applets into a launcher that users can run.

A Suite controls how its included Applets are presented and accessed. Its launcher may contain:

* Applet buttons.
* A logo.
* Text or other fields.
* A background color or image.
* Actions that run when the Suite launches.

A Suite can contain a single Applet or several Applets. Each launcher button is linked to the Applet it opens.

In the Getting Started tutorial, the **Getting Started** Suite contains the **Asset Check-In** Applet.

### Devices and Web Apps

A Suite can be used in two ways:

* On a mobile device running the DC Works application.
* As a Web App through a supported web browser.

For a mobile device, the DC Works application must be installed and the device must be enrolled in the Suite.

For web access, the Suite must be made available to the appropriate Web User.

{% hint style="info" %}
Applets can be tested in the Applet Designer. Suites do not have a Designer test mode; they must be run on an enrolled device or as a Web App.
{% endhint %}

### How the components work together

The workflow begins with data and ends with user access:

1. **Databases and tables** organize and store the information.
2. **Applets** provide the pages and controls used to work with that information.
3. **Suites** organize the Applets into a launcher.
4. **Devices or Web Apps** allow users to run the Suite and its Applets.
5. **Actions and conditions** control what happens throughout the workflow.

The Getting Started solution follows this same structure:

```mermaid
flowchart TD
    T["Asset Check-In Table"] --> A["Asset Check-In Applet"]
    A --> S["Getting Started Suite"]
    S --> D["Enrolled Scepter Pro"]
    S --> W["Web App"]
```

Changes should be made in the component responsible for that part of the solution. For example:

| To change…                           | Work with…                             |
| ------------------------------------ | -------------------------------------- |
| The information being stored         | Database or table                      |
| A data-entry screen                  | Applet                                 |
| Workflow behavior                    | Actions and conditions                 |
| Applet access or launcher appearance | Suite                                  |
| Who or what can run the solution     | Users, devices, or deployment settings |

### Build in the correct order

Although a solution can be revised at any time, it is generally best to work in this order:

1. Define the real-world workflow.
2. Identify the information the workflow requires.
3. Structure the databases and tables.
4. Build the necessary Applets.
5. Organize the Applets into Suites.
6. Make the Suites available on devices or as Web Apps.
7. Test the complete workflow with representative data.

Planning in this order helps ensure that the screens and actions support a well-organized data structure.

### Next

Continue to **Understanding Databases, Tables, and Records** to learn how DC Works organizes and stores solution data.


---

# 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/how-dc-works-is-organized.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.