> 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/saving-testing-and-publishing.md).

# Saving, Testing, and Publishing

Saving preserves the Applet’s configuration, while testing confirms that its pages, fields, records, actions, and conditions work together as intended.

An Applet is not published directly to users. To make it available on a device or as a Web App, the Applet must first be added to a Suite.

### Save an Applet

Save the Applet regularly while working in the Applet Editor.

To save an Applet:

1. Select the **Save** icon in the Top Taskbar.
2. Wait for the save operation to complete.
3. Continue editing or close the Applet Editor.

Select the Save icon to preserve changes made to the Applet.

Save after making changes such as:

* Creating, renaming, copying, or deleting pages.
* Adding, moving, resizing, or deleting fields.
* Changing page or field properties.
* Creating or changing records and data bindings.
* Adding, editing, or reordering actions.
* Adding or changing conditions.
* Applying or modifying styles.

{% hint style="info" %}
Save the Applet before testing it to ensure that the test uses its latest configuration.
{% endhint %}

### Test an Applet in the Applet Editor

Use the Applet Editor’s test control to run the Applet and review its behavior.

To test an Applet:

1. Save the Applet.
2. Select the **play** icon in the Top Taskbar.
3. Begin on the Applet’s home page.
4. Interact with its fields and controls.
5. Navigate through its pages.
6. Confirm that actions, conditions, and data operations produce the expected results.
7. Return to the Applet Editor and correct any issues.
8. Save and test the Applet again.

Select the play icon to test the Applet’s pages and interactions.

Testing should verify more than the page’s appearance. Follow the same sequence that an actual user would follow when completing the Applet’s intended task.

### Test page structure and navigation

Confirm that:

* The correct page is configured as the home page.
* The Applet opens on the expected page.
* Page Load Actions execute correctly.
* Buttons open the correct pages.
* Previous-page navigation works as intended.
* Users can complete the workflow without reaching an unintended page.
* There is a clear way to complete, cancel, or exit the process.

Test each possible navigation path, including paths controlled by conditions.

### Test fields and captured input

Confirm that:

* Fields display the correct labels and default values.
* Input fields accept the intended capture types.
* Scanner-only and keyboard-only settings behave correctly.
* Minimum and maximum lengths are enforced.
* Character restrictions and case conversion produce the expected values.
* Required fields prevent incomplete operations.
* Lockable fields and **Lock On Input** behave as intended.
* Clear, focus, show, hide, enable, and disable actions affect the correct fields.

Use realistic test values as well as empty, incomplete, and invalid values.

### Test records and data binding

Confirm that:

* Fields are bound to the correct Applet records and record properties.
* Lookup and load actions return the expected database information.
* Values loaded into a record appear in the correct bound fields.
* Values entered into bound fields update the working Applet record.
* List records contain the expected results.
* Reset actions clear or restore the intended records.
* Table View row selection populates the intended record.

Remember that changing a bound field updates the working Applet record but does not, by itself, update the database table.

### Test database actions

Test each operation that writes information to a database table:

* **Add Record**
* **Update Record**
* **Update Or Add Record**
* **Delete Record**
* **Batch Delete Records**

Confirm that:

* New records are added only when intended.
* Existing records are updated rather than duplicated.
* The correct record is selected before an update or deletion.
* Required values are present.
* The database table contains the expected information after the action executes.

{% hint style="warning" %}
Testing data actions can add, change, or delete database records. Use test records or a dedicated test table whenever possible, especially when testing Delete Record or Batch Delete Records.
{% endhint %}

### Test actions and conditions

Actions execute from top to bottom. Confirm that they are arranged in the correct order and that each action has the information it requires from earlier actions.

When testing conditions, verify each possible result:

* The **If** condition is true.
* The **If** condition is false.
* Each **Else if** condition is reached when expected.
* The **Else** branch executes when no preceding condition is true.

Also confirm that:

* Actions inside a condition execute only when the condition is satisfied.
* Navigation occurs after required data operations.
* Messages appear at the appropriate time.
* Fields are shown, hidden, enabled, or disabled correctly.
* Record actions use the intended filters and records.

### Test appearance and layout

Preview each page at the dimensions for which it was designed.

Confirm that:

* Text is readable.
* Field labels and values are not cut off.
* Buttons are large enough to select easily.
* Fields do not overlap unintentionally.
* Normal, floating, and docked fields appear in the intended locations.
* Background colors and images provide sufficient contrast.
* Table View content remains readable.
* Pages do not contain unnecessary empty space or scrolling.

If the Applet will be used on more than one screen size, test each intended layout.

### Test on the intended platform

Editor testing is useful for reviewing the Applet’s general behavior, but some features should also be tested on the platform where the Applet will be used.

Device testing may be required for:

* Hardware barcode scanning.
* Camera capture.
* Image capture.
* Keyboard entry.
* Sound playback.
* Printing.
* Offline operation and synchronization.
* Other device-dependent functions.

Web App testing may also be required to confirm browser behavior, screen layout, keyboard input, and network-dependent operations.

The Applet must be added to a Suite before it can be tested on an enrolled device or through a Web App.

### Use a repeatable test process

A simple test process helps ensure that changes do not introduce new problems:

1. Begin with a known set of test data.
2. Follow the workflow from its home page.
3. Enter or scan representative values.
4. Verify each displayed result.
5. Confirm database changes in the applicable table.
6. Repeat the test using alternate and invalid values.
7. Correct any issues in the Applet Editor.
8. Save and test again.

When an Applet contains multiple workflow paths, test each path separately.

### Prepare an Applet for publishing

Before adding the Applet to a Suite, confirm that:

* The Applet has a descriptive name.
* Its home page is configured.
* Its preview page is configured.
* All required pages are present.
* Fields are bound to the correct records.
* Actions execute in the correct order.
* Conditions handle the expected outcomes.
* Database operations have been tested.
* The layout has been reviewed at the intended screen dimensions.
* Device-dependent features have been identified for device testing.
* The latest changes have been saved.

An Applet that passes these checks is ready to be added to a Suite.

### Publish an Applet through a Suite

Applets are created first and then grouped into Suites. A Suite determines which Applets are made available together to device or Web App users.

The general publishing process is:

1. Complete and save the Applet.
2. Create or open a Suite.
3. Add the Applet to the Suite.
4. Configure and save the Suite.
5. Make the Suite available to the intended device or Web App users.
6. Test the complete Suite on its intended platform.

Detailed instructions for creating, configuring, and making Suites available are provided in the **Suites** chapter.

{% hint style="info" %}
An Applet cannot be made available to users by itself. It must be included in a Suite before it can be run on an enrolled device or as a Web App.
{% endhint %}

### Complete the Applet

An Applet is ready for use when its pages provide a clear workflow, its fields exchange information with the correct records, its actions and conditions produce the intended behavior, and its appearance is appropriate for the intended screen.

Continue refining and retesting the Applet whenever its fields, data connections, actions, conditions, or visual design are changed.

### Next

Continue to **Suites** to learn how to group Applets, configure the Suite interface, and make the completed solution available on enrolled devices or as a Web App.


---

# 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/saving-testing-and-publishing.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.