> 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/suites-and-deployment/deploy-a-suite-as-a-web-app.md). # Deploy a Suite as a Web App Learn how to create a runtime user, assign a Web License and Suite, and make the Suite available through a web browser. A Web App allows users to run a Suite and its Applets without installing the DC Works Android application. Users sign in through the organization’s DC Works Web App address. ### Before you begin Confirm that: * The Suite has been created, configured, and saved. * The correct Applets are included. * Each App Button opens the intended Applet. * A Web License is available. * You have permission to create runtime users and manage licenses. * The user has a supported browser and network connection. * You know the organization’s DC Works Web App address. Web App deployment requires both a user account and a Web License assigned to that user and Suite. ### Understand Web App access Web App users run Suites and Applets through a browser. The basic deployment process is: 1. Create the user account. 2. Create a Web License. 3. Assign the user and Suite to the license. 4. Provide the user with the organization’s Web App address. 5. Sign in and test the Suite. Creating a Web App runtime account does not provide access to the DC Works Designer. ### Create the user Web App runtime users are created from the **Device Users** area in Administration. To create a user: 1. Open **Admin**. 2. Select **Device Users**. 3. Select **+ Add User**. 4. Enter the required user information. 5. Create the user’s sign-in credentials. 6. Save the user.
Create a runtime user before assigning a Web License. Enter a username that clearly identifies the user. Follow the organization’s password and account-management requirements. {% hint style="info" %} The Device Users area manages runtime users of Suites and Applets, including users who access them as Web Apps. It is separate from access to the DC Works Designer. {% endhint %} ### Create a Web License After creating the user, create a Web License. To create the license: 1. Open **Licenses**. 2. Select **+ WebLicense**. 3. Select the applicable user. 4. Select the Suite the user should run. 5. Save the license assignment.
A Web License connects the selected runtime user to the assigned Suite. Confirm that the correct user and Suite are selected before saving. ### Assign the correct Suite The Suite assigned to the Web License determines which Suite the user receives after signing in. Before assigning it, confirm that: * The Suite is intended for that user. * The required Applets are included. * The Suite has been saved. * Its layout is suitable for a browser. * The user should have access to the data and workflows used by its Applets. If the wrong Suite is assigned, edit the Web License and select the correct Suite. ### Locate the Web App address Each organization uses its own DC Works Web App address. For example: `dcacademy.dcworks.io` The organization’s address is based on its DC Works environment. Provide the correct address to the Web App user along with their username and initial sign-in instructions.
Users open the organization-specific address in a supported browser. ### Sign in to the Web App To run the Suite: 1. Open a supported web browser. 2. Navigate to the organization’s DC Works Web App address. 3. Enter the assigned username. 4. Enter the password. 5. Select the sign-in control. 6. Wait for the assigned Suite to load. The Suite launcher appears in the browser. After signing in, the user can open the Applets assigned through the Suite. No DC Works Android APK is required for Web App access. ### Verify the Web App deployment After signing in, confirm that: * The correct Suite loads. * The Suite logo and background appear correctly. * All required App Buttons are visible. * Each App Button opens the correct Applet. * Page navigation works. * Text and fields fit the browser window. * Input fields accept keyboard entry. * Data is retrieved and saved correctly. * Logout behavior works as intended. Test the workflow using the same browser and screen dimensions expected for actual users. ### Test the Suite layout in a browser A Suite designed for a handheld Android device may appear differently in a desktop browser. Confirm that: * The Suite remains easy to navigate. * App Buttons are appropriately sized. * Fields do not overlap. * Text is readable. * Background images display correctly. * Floating or fixed-position fields remain in the intended locations. * Applet pages fit the available browser area. Adjust the Suite or Applet dimensions when necessary and test again. ### Test input and device-dependent features Keyboard input is generally appropriate for browser workflows, but hardware-dependent functions must be tested separately. Review any use of: * Hardware barcode scanners. * Camera scanning. * Image capture. * Printing. * Sound. * Device-specific keyboard input. * Offline operation. Browser permissions and connected hardware can affect these functions. {% hint style="info" %} An Applet that works on an Android device may not behave identically as a Web App. Test every device-dependent feature in the intended browser environment. {% endhint %} ### Test records and database actions Use designated test data to confirm that: * Lookup actions return the expected records. * Bound fields display the correct information. * User input updates the working Applet record. * Add Record creates the intended database entry. * Update Record changes the correct entry. * Required fields prevent incomplete submissions. * Conditions produce the expected workflow. * Delete operations affect only the intended records. ### Update a Web App Suite After changing the Suite or one of its Applets: 1. Save the changes. 2. Open the Web App. 3. Refresh the browser or sign out and sign in again as needed. 4. Confirm that the updated Suite loads. 5. Retest the affected Applets. ### Change a Web App assignment To assign a different Suite: 1. Open **Licenses**. 2. Locate the applicable Web License. 3. Edit its assignment. 4. Select the required Suite. 5. Save the change. 6. Sign in as the user and verify the result. Changing the assignment affects the Suite available to that Web App user. It does not modify or delete either Suite. ### Troubleshoot sign-in problems If the user cannot sign in: * Confirm that the organization-specific Web App address is correct. * Verify the username. * Confirm that the user account is active. * Reset or verify the password according to the applicable administrative process. * Confirm that the browser has network access. * Try signing in again after correcting the issue. ### Troubleshoot a missing Suite If sign-in succeeds but the Suite is unavailable: * Confirm that a Web License exists. * Confirm that the license is assigned to the correct user. * Confirm that the correct Suite is assigned. * Verify that the Suite still exists. * Save the Suite again if recent changes were not preserved. * Sign out and sign in again. ### Troubleshoot browser behavior If the Suite loads but does not behave correctly: * Refresh the browser. * Confirm that the browser is supported and current. * Review browser permissions. * Disable unnecessary browser zoom. * Test at the intended window dimensions. * Confirm that network-dependent actions can reach their services. * Test the same Suite with another authorized user to isolate account-specific issues. ### Complete Web App deployment testing Before giving the user access, confirm that: * The user account works. * The Web License is active and correctly assigned. * The correct Suite opens. * All Applets are available. * The layout works in the intended browser. * Keyboard and scanner input behave correctly. * Database operations have been tested. * Logout and subsequent sign-in work. * The user can complete the workflow without Designer access. --- # 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/suites-and-deployment/deploy-a-suite-as-a-web-app.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.