> 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/databases-and-tables/plan-your-data-and-workflow.md).
# Plan Your Data and Workflow
Before creating a database, first define the process it must support and the information that must be stored.
A simple workflow outline helps identify the required tables, records, and fields before they are created in DC Works. It also helps prevent unnecessary tables, missing information, and structures that are difficult to report on later.
The objective at this stage is not to define every technical detail. It is to create a clear model of:
* What is being tracked.
* How it moves through the process.
* What information is required.
* What information changes.
* What history must be preserved.
### Define the purpose
Begin with a short statement describing what the database is intended to accomplish.
For example:
> Track equipment as it is checked out, used, and returned.
A useful purpose statement should identify:
* What is being tracked.
* What process is being supported.
* What result the organization needs.
Avoid beginning with a list of tables or fields. First define the business need, then design the data structure around it.
### Define the beginning and end
Identify where the process begins and where it is considered complete.
Ask:
* What causes a new item or transaction to enter the process?
* What must occur before it can be considered complete?
* Can the process be canceled?
* Can an item reenter the process after completion?
* Must completed items remain available for future reference?
For example, an equipment-checkout process might begin when an employee requests an item and end when the item is returned and inspected.
Clearly defining these boundaries helps determine which information belongs in the database.
### Identify what one record represents
Before planning fields, decide what one record in the main table will represent.
A record might represent:
* One physical item.
* One customer request.
* One inspection.
* One shipment.
* One repair.
* One inventory transaction.
* One workflow event.
This decision affects the entire data structure.
For example, if one request can contain several physical items, determine whether the main table should contain:
* One record for the complete request.
* One record for each item.
* Separate request and item tables.
{% hint style="info" %}
Describe a record using the phrase **“One record represents…”**. If this statement is unclear, the table’s purpose may not yet be defined well enough.
{% endhint %}
### Outline the workflow stages
List the significant stages an item passes through from beginning to completion.
For example:
1. Requested
2. Approved
3. Issued
4. Returned
5. Inspected
6. Completed
Focus on meaningful changes in the process rather than every click, correction, or administrative task.
*Outline the major stages and decisions before designing the database structure.*
For each stage, consider:
* What information becomes available?
* What information may change?
* Who is responsible for the stage?
* What determines when the item moves forward?
* Can it return to an earlier stage?
* Does the transition need to be preserved historically?
### Identify decisions and exceptions
Not every item follows the same path. Identify the decisions that may change the workflow.
Examples include:
* Approved or rejected.
* Passed or failed.
* Complete or incomplete.
* Repairable or nonrepairable.
* Returned or sent back for additional work.
* Standard handling or exception handling.
Also consider unusual situations:
* Incorrect information must be corrected.
* An item skips a stage.
* A completed item is reopened.
* A process is canceled.
* An item returns to a previous stage.
These decisions can affect which statuses, dates, notes, and historical records must be stored.
### Identify the required information
List the information needed throughout the process.
Organize it into general categories before assigning fields.
| Information category | Examples |
| ------------------------ | ---------------------------------------------- |
| Identification | Item number, serial number, request number |
| Description | Item name, model, category |
| Ownership or association | Customer, department, location |
| Current state | Status, assigned user, current stage |
| Dates and times | Created, received, issued, returned, completed |
| Process details | Reason, result, action taken |
| Notes | Comments, observations, exceptions |
| Measurements | Quantity, duration, count, score |
For each item of information, ask:
* Is it required for every record?
* Is it entered once or updated over time?
* Is it selected from a predefined list?
* Can it contain more than one value?
* Must its previous values be preserved?
* Will it be used for searching, filtering, or reporting?
At this stage, concentrate on the information itself. Field types and detailed field configuration will be addressed in **Define Table Fields**.
### Separate stored data from calculated information
Not every displayed value must be stored as a separate field.
Determine whether a value is:
* Entered by a user.
* Retrieved from an existing record.
* Selected from a predefined list.
* Generated automatically.
* Calculated from other values.
* Supplied by another system.
For example, a completion date may need to be stored, while the number of days between creation and completion may be calculated later.
Avoid storing the same information in several places unless there is a clear reason to do so.
### Identify reference information
Some values are known in advance and reused across many records.
Examples include:
* Statuses.
* Categories.
* Locations.
* Departments.
* Operators.
* Reason codes.
* Result codes.
These values may be suitable for reference tables, particularly when they must be consistent, centrally managed, or reused.
A short and rarely changing list may be simple to maintain. A larger list or one that changes regularly may require more planning.
Detailed guidance is provided in **Use Reference Tables**.
### Decide what history must be preserved
Determine whether the database needs only the latest information or must also retain previous events and changes.
A history record may be appropriate when the organization needs to know:
* Which stages an item completed.
* When each stage occurred.
* Who performed an action.
* What status was assigned.
* What notes or results were recorded.
* How many times an item repeated a stage.
* How long the complete process took.
Only meaningful events should normally be treated as workflow history.
For example, correcting a spelling error may update the current record without creating a new historical step. Changing an item from one workflow status to another may update the current record and add a history entry.
{% hint style="info" %}
Define what qualifies as a new historical event before building the tables. Recording every edit can create unnecessary history, while recording too little can make the process difficult to audit or measure.
{% endhint %}
### Consider reporting requirements
Think about what users may need to search, filter, count, or measure after data has been collected.
Possible questions include:
* How many items are currently active?
* How many items are in each status?
* How long does the process normally take?
* Which stages cause the most delays?
* How many times does an item repeat a stage?
* Which categories occur most frequently?
* Who completed a particular action?
* What happened during a specific period?
Reporting requirements help identify which values should be stored consistently in dedicated fields instead of being included only in notes.
### Start with the essential structure
The first version of the data structure should support the essential workflow without trying to anticipate every possible future requirement.
Classify proposed information and functions as:
* **Required now**
* **Useful later**
* **Possible future enhancement**
Build the required structure first. Additional tables, fields, and integrations can be added after the initial process has been tested and understood.
{% hint style="info" %}
A smaller, clearly defined structure is usually easier to test and improve than a large design containing tables and functions that are not yet needed.
{% endhint %}
### Review the plan
Before creating the database, review the proposed process with the people who perform or manage the work.
Confirm that:
* The beginning and end of the process are clear.
* The major workflow stages are included.
* Exceptions and repeat steps have been considered.
* One record has a clearly defined meaning.
* Required information has been identified.
* Predefined values have been identified.
* Historical requirements are understood.
* Likely reporting needs have been considered.
* Future ideas have been separated from immediate requirements.
The plan can still change after implementation begins. Its purpose is to provide a reliable starting point and reduce avoidable restructuring.
### Next
Continue to **Data and Workflow Planning Worksheet** to document the process, required information, proposed tables, and historical requirements before building the database.
---
# 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/databases-and-tables/plan-your-data-and-workflow.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.