> 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/understanding-applets.md). # Understanding Applets An **Applet** is the part of a DC Works solution that users interact with to complete a task or workflow. Applets can collect information, display data, guide users through a process, and create or update entries in tables. ### What an Applet contains An Applet can include: * One or more pages * Fields that display or collect information * Applet records that hold working data * Buttons and navigation controls * Actions that perform operations * Conditions that control when operations occur ```mermaid flowchart TD A["Applet"] --> P["Pages"] P --> F["Fields"] F <--> R["Applet Records"] AC["Actions and Conditions"] --> R R <--> T["Tables"] ``` These components work together to create the user experience and control the workflow. ### Pages and fields **Pages** organize the Applet into screens. Each page typically supports a particular step in the workflow, such as entering information, viewing a list, or editing a selected entry. **Applet fields** are the elements placed on those pages. Depending on their type, fields can: * Accept user input * Display information * Show a list of entries * Scan a barcode * Provide navigation * Start an action A field can be connected to a value in an Applet record. ### Records within an Applet Applet records hold the information used while the Applet is running. A record may contain a single entry or a list of multiple entries. Record values may be: * Entered by the user * Set by an action * Retrieved from a table * Evaluated by a condition * Added or applied to a table through an action {% hint style="info" %} Changing a value in an Applet record does not automatically save it to a table. An appropriate action must add, append, or update the table data. {% endhint %} ### Actions and conditions **Actions** make something happen within an Applet. For example, an action might: * Set a record value * Retrieve information * Add an entry to a table * Update an existing table entry * Open another page **Conditions** determine whether an action should occur. They allow the Applet to respond differently based on user input, record values, or other circumstances. Together, actions and conditions turn a collection of pages and fields into a working process. ### Applets and tables An Applet can interact with one or more tables. It can also use local records without immediately storing their values in a table. ```mermaid flowchart LR U["User"] <--> A["Applet"] A <--> L["Local Records"] A <--> T["Table Data"] ``` The Applet is the interface and workflow layer. Tables provide persistent data storage. ### Applets and Suites Applets are created independently and then added to Suites. A **Suite** provides the launcher through which users open its Applets. The same Applet may be included in more than one Suite, allowing it to be reused for different users, devices, or solutions. ### The Getting Started example The **Asset Check-In** Applet created in Getting Started includes pages for: * Entering asset check-in information * Viewing existing entries * Editing a selected entry Its fields are connected to Applet records, while actions move information between those records and the Asset Check-In table. This is one example of an Applet supporting a complete, focused workflow. ### Keep Applets focused An Applet should generally serve a clear purpose. For example: * Check an asset in or out * Perform a cycle count * Record an inspection * Receive inventory * Look up product information Keeping an Applet focused makes it easier to build, test, reuse, and maintain. Related Applets can then be grouped together in a Suite. ### Next Continue to **Understanding Suites** to learn how Suites organize Applets and make them available on devices and as Web Apps. --- # 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/understanding-applets.md?ask=&goal= ``` `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.