> 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/conclusion.md).

# Conclusion

You now have the foundational knowledge required to plan, build, test, and deploy solutions with DC Works.

This manual introduced the complete DC Works structure and followed the solution-building process from data planning through deployment.

### What you have learned

You have learned how to:

* Understand how DC Works is organized.
* Plan a workflow before beginning development.
* Create databases and tables.
* Define fields and primary fields within a table.
* Create Applets and organize them into pages.
* Define single records and list records.
* Bind fields to Applet records.
* Load information from database tables.
* Collect user input and write changes back to a table.
* Add and configure visual, input, container, and action fields.
* Use events, actions, and conditions to control Applet behavior.
* Configure field capture, validation, and appearance.
* Apply preset styles and customize pages and fields.
* Save, test, and prepare Applets for use.
* Create and configure Suites.
* Add and organize Applets within a Suite.
* Style the Suite launcher.
* Deploy Suites to Android devices.
* Make Suites available as Web Apps.

### Remember the DC Works structure

A DC Works solution follows a consistent structure:

1. **Databases and tables** store information.
2. **Records** provide the working connection between data and Applet fields.
3. **Applets** perform individual tasks and workflows.
4. **Suites** group Applets and provide access to them.
5. **Android devices and Web Apps** allow users to run the deployed solution.

Understanding this relationship makes it easier to plan new solutions and troubleshoot existing ones.

### Continue refining your solutions

A DC Works solution does not need to begin as a large or complex project.

Start with:

* A clearly defined task.
* The minimum data required.
* A simple table structure.
* A focused Applet.
* A small number of pages.
* Clear navigation.
* A Suite designed for a specific group of users.

Test the basic workflow first, then add fields, actions, conditions, validation, styling, and additional Applets as requirements become clearer.

{% hint style="info" %}
Starting with a small, working solution is usually more effective than attempting to anticipate every future requirement before testing the workflow.
{% endhint %}

### Test changes carefully

Changes to tables, records, data binding, actions, conditions, Applets, and Suites can affect other parts of the solution.

After making changes:

1. Save the affected Applet or Suite.
2. Test the modified workflow.
3. Confirm the expected database results.
4. Test alternate and invalid inputs.
5. Verify the deployment on its intended platform.
6. Confirm that existing workflows still operate correctly.

Use designated test records or tables when testing actions that add, update, or delete data.

### Keep your solutions understandable

As solutions grow, use descriptive names for:

* Databases.
* Tables.
* Table fields.
* Applet records.
* Applets.
* Pages.
* Page fields.
* Actions and workflows.
* Suites.

Clear naming makes a solution easier to modify, test, transfer, and support.

### Continue learning

This manual provides the foundation for working with DC Works. Additional documentation can build upon it with:

* Practical tips and techniques.
* Design patterns and reusable approaches.
* Workflow examples.
* Troubleshooting guidance.
* Data-planning recommendations.
* Performance and maintenance practices.
* Advanced actions and conditions.
* Detailed field and action references.
* Offline workflow guidance.
* Administrative procedures.
* Integration and API examples.

As these sections are added, they will provide more specialized guidance for developing and maintaining larger DC Works solutions.

### Final thoughts

DC Works provides the building blocks needed to turn operational requirements into working data-collection applications without developing a traditional application from the ground up.

Begin with the workflow, organize the data, build focused Applets, group them into a Suite, and test the complete solution where it will be used.

With those principles in place, DC Works solutions can grow alongside the processes they support.


---

# 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/conclusion.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.