> 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/data-and-workflow-planning-worksheet.md). # Data and Workflow Planning Worksheet Use the **Data and Workflow Planning Worksheet** to document a process before creating its databases, tables, and fields in DC Works. The worksheet helps identify: * What is being tracked. * What one record represents. * The major stages of the process. * The information that must be stored. * The tables that may be required. * Predefined reference values. * Events that must be preserved historically. * Immediate requirements and future enhancements. Completing the worksheet provides a starting plan. The structure can still be revised as the process is tested and better understood. ### Download the worksheet {% file src="/files/TOsneepykjrJ9hE5JtVW" %} *Download and complete the worksheet before creating the database structure.* Yellow cells in the workbook are intended for user input. Some cells provide drop-down choices to help keep the planning responses consistent. ### Worksheet sections The workbook contains six worksheets. | Worksheet | Purpose | | ------------------- | ------------------------------------------------------------------------------------------ | | Start Here | Records the project overview and provides the recommended completion order | | Process Plan | Defines the process boundaries, workflow stages, decisions, corrections, and exceptions | | Data Requirements | Lists the information that must be stored, changed, preserved, searched, or reported | | Table Plan | Organizes the information into proposed main, reference, history, or other tables | | Reference & History | Defines controlled value lists and the events that should create historical records | | Priorities & Review | Separates immediate requirements from future ideas and provides a final planning checklist | Complete the worksheets in the order shown. ### 1. Start with the project overview On **Start Here**, enter: * The project or process name. * The person preparing the plan. * The purpose of the database. * What is being tracked. * What one main record represents. * What begins the process. * What completes the process. Complete the statement: > One main record represents… Examples include: * One physical item. * One customer request. * One repair. * One inspection. * One shipment. * One transaction. If this statement cannot be completed clearly, the purpose of the main table may need further consideration. ### 2. Document the process Use **Process Plan** to record the major stages through which an item moves. For each stage, identify: * What starts the stage. * What occurs during it. * What information is created or changed. * Who is responsible. * What stage follows. * Any decision or exception that may change the path. Focus on meaningful workflow stages rather than individual screen actions or minor corrections. The worksheet also provides space to document: * Canceled processes. * Repeated stages. * Items returning to an earlier stage. * Corrections to existing information. * Exceptions requiring different handling. For each exception, determine whether it represents a meaningful historical event. ### 3. List the required information Use **Data Requirements** to list every item of information the process may need. For each proposed item, record: * Its purpose. * Its information category. * Whether it is required. * When it first becomes known. * Whether it can change. * Whether earlier values must be preserved. * Whether it will be used for searching or reporting. Do not select DC Works field types at this stage. First determine what information is needed and why. Field types will be addressed later in **Define Table Fields**. {% hint style="info" %} Information used for searching, filtering, calculations, or reporting should normally be stored in a dedicated field rather than included only in unstructured notes. {% endhint %} ### 4. Prepare a preliminary table plan Use **Table Plan** to group the required information into a small number of proposed tables. For each table, identify: * A descriptive name. * Its purpose. * Its general type. * What one record represents. * A possible primary field. * Related tables or shared identifiers. * Why the information requires a separate table. The worksheet includes the following table categories: * **Main** * **Reference** * **History** * **Integration** * **Other** This is a preliminary plan. Detailed table relationships and fields will be refined in **Design Your Data Structure**. ### 5. Define reference values and history rules Use **Reference & History** to identify predefined values that may require reference tables. Examples include: * Statuses. * Operators. * Categories. * Locations. * Departments. * Reason codes. * Result codes. For each list, consider how often it changes, who maintains it, and whether a separate table is necessary. The same worksheet is used to define historical events. For each possible event, determine: * What qualifies as a new event. * Whether a history record should be created. * Whether the current record should also be updated. * Which values must be preserved. * Whether a sequence or step number is required. {% hint style="info" %} Distinguish meaningful workflow events from corrections. A status change may create a history entry, while correcting a spelling error may only update the current record. {% endhint %} ### 6. Set priorities and review the plan Use **Priorities & Review** to classify proposed requirements as: * **Required now** * **Useful later** * **Future enhancement** This helps keep the initial database structure manageable. Before proceeding, confirm that: * The process has a clear beginning and end. * One record in each table has a clear meaning. * Every proposed table has a distinct purpose. * Required information has been identified. * Predefined values have been identified. * Meaningful historical events are defined. * Corrections are distinguished from workflow events. * Search and reporting requirements have been considered. * Future enhancements are separated from immediate needs. * The plan has been reviewed with people familiar with the process. {% hint style="info" %} The worksheet is a planning aid, not a fixed specification. Update it when testing reveals a simpler or more effective way to organize the data. {% endhint %} ### Next Continue to **Design Your Data Structure** to refine the proposed tables, identify their relationships, and determine how information should be divided between them. --- # 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/data-and-workflow-planning-worksheet.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.