--- title: "Defect Tracking Data Model" slug: "defect-tracking-data-model" updated: 2023-05-18T19:16:46Z published: 2023-05-18T19:16:46Z --- > ## Documentation Index > Fetch the complete documentation index at: https://support.tulip.co/llms.txt > Use this file to discover all available pages before exploring further. # Defect Tracking Data Model ## Overview Getting the data architecture right is critical to driving the right actions to improve your process. Data is never *one-size-fits-all* because the problems being solved are seldom identical. This Functional Example outlines the core data recommended for Defect Tracking. Feel free to add more Fields to extend this Functional Example. The [Extending the Concept](/r230/docs/defect-tracking-extend-the-concept) document goes into some ways this data model could be built on top of to drive even more value. ## Tables This application relies on Tables for data storage. This is recommended (over using Completions) because it means this same Table can be used across multiple apps, a critical characteristic of Composability, especially if this defect tracking exists across multiple apps. This application relies on a single `[Defect Events]` table. [Extend the Concept](/r230/docs/defect-tracking-extend-the-concept) covers some opportunities to extend this data model, including more extensive interconnectivity with [Order Tracking](/r230/docs/order-tracking), or other use cases. ## `[Defect Events] Table` ![Defect Events.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Defect%20Events.png) The Defect Events table is the bare bones needed to drive visibility into your process. Some Table Record Fields are optional, and others really are required to maintain visibilitiy into your operations. Keep in mind, these fields don't necessarily need to be populated by a person. Order information could come from an external datasource, or be inferred based on conditional logic. *ex. The defect `Description` is automatically calculated by combining the `Material` Variable and `Reason` variable with the Expression:* `'Defected ' + @Variable.Material + ' due to ' + @Variable.Reason` ### Table Fields **ID** (Text)- All tables need an ID column to uniquely represent each Table Record. In this usecase we are using a random string as the record ID. **Description** (Text) - A human-readable description of the defect. In the Functional Example this will follow the format "Defected `Material` due to `Reason`" **Reported Date** (Datetime) - The time the defect was originally reported. **Reported By** (User) - The user who reported the defect. In the Functional Example, this is populated with the Logged in User, but could be set to a static user, or allow users to select a reporter. **Material ID** (Text) - The ID of the material where the defect was found. Replacing this field with a Linked Record to the `[Materials]` table would be a great way to[Extend the Concept](/r230/docs/defect-tracking-extend-the-concept). **Quantity** (Number)- As the name implies, this is the quantity of defective parts. **Reason** (Text) - Much like the `Status` field, the Reason field can be leveraged to route defects to the correct team automatically. *ex. All `excess inventory` defects should be handled by the production managers* **Assignee** (User) - The User who is responsible for dispositioning the defect. This can be dynamically set based on the Reason, or statically to a single user/team **Status** (Text) - The current state of this defect. When the defect is reported in the Functional Example this will default to `NEW`. In our use case, defects move through 3 statuses: 1. NEW 2. IN REVIEW 3. CLOSED **Comments** (Text) - A freeform text field where any notes about the defect can be collected. Leverage this field as part of root cause analysis. Combine with the Digital Record History widget, you can see the historic data around each defect. **Photo** (Image)- Collect a photo of the defect. Images can be leveraged to better understand root cause. **Closed Date** (Datetime)- When a defect is resolved, this field can track the date the defect report was closed. Leverage this field in Analytics to understand the backlog of existing open defect reports. **Location Detected** (Text)- Sort defects by the location where they were first identified. Use this field to drive insights around the most common failure points in your process. Additionally, this field can be leveraged to get the defect assigned to the correct `Assignee`. **Next Stes** (Text) - Track resolution on the defect, when combined with the Digital Record History Widget users can see how a defect has been addressed. **Functional Example** **Functional Examples**are intended to explain the right approach to core Tulip use cases. Functional example applications cover the core applications, their underlying data models, and ways those concepts can be extended when combined with others. *Functional Example apps aren't intended to be run in production, but rather as tools to learn the underlying concepts needed to implement core Tulip use cases.* **Table Record Field** **Table Record Fields**are single columns within a **Tulip Table.** ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Table%20Record%20Field(1).gif) **Tulip Tables** **Tulip Tables**are a global location to store your production data. Tables are made up of Records (rows). A single can be accessed from multiple apps or stations at the same time. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Tulip%20Tables%20Overview%20-%20Feature%20Overview.gif) **App Completion** **App Completions**are a mechanism to store immutable data from a Tulip app. When an app is completed, all **Variable's**current values will be stored in the app completions tab.****This completion data can be analyzed in **Analytics.** By default, after a Completion users will be brought back to the **Begin Screen**of your application. This behavior can be adjusted with other **Transition**types. **Composability** **Composability**in software is the concept that resources, logic, and assets can be reused throughout solutions. When this comes to Tulip, Compostability matters when developing apps and data architecture that can be used by multiple teams, facilities, and roles. **Table Record Field** **Table Record Fields**are single columns within a **Tulip Table.****![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Table%20Record%20Field.gif)** **Variable** **Variables**are a location to store app information. Variables have a specific type that must match the contents they can store. Variables are only accessible within a single application and are cleared when the app is restarted or completed. **Expression** A configured code snippet that returns a calculated value based on certain inputs. **Expressions**have access to all of the variables, Table Records, and any other data available to an application. **Table Record** A **Table Record** is a reference to a row in a **Tulip Table**. Table Records can be created either from the Table UI or from with an App Trigger. To edit a record it must be loaded into a **Table Record Placeholder.** **Datetime** **Datetimes**are a Tulip Datatype. Datetimes represent a time in the ISO8601 format. *ex. 2022-08-31T19:56:16+00:00* **User** **User**is a Tulip Datatype. Users represent a single user in your Tulip **Instance.**User****variables include attributes like **Badge Id, Name, and Shift.** **Linked Records** **Linked Records**are interconnections between multiple **Tulip Tables.**Fields in one Table can be mapped to another table. Linked records simplify traceability, genealogy, and data association for more advanced Tulip apps and app suites. **Digital Record History Widget** The **DRH Widget**allows users to review the changes that have occurred to a **Record.**Traceability to changes is critical in a **GxP**Environment. **Analytics** **Analytics** are live updating graphs and metrics calculated based on app data, Table data, and machine data. Analytics can be embedded and dynamically filtered within an application. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/image-1662410510869.png) **Widget** **Widgets**are the elements that make up a specific **App Step.**Widgets can display information to users, collect user input, or trigger app logic. *Common widgets include: Interactive Tables, Number inputs, Machine attribute widgets, and more.*