--- title: "Defect Tracking - Extend the Concept" slug: "defect-tracking-extend-the-concept" updated: 2022-09-29T00:59:21Z published: 2022-09-29T00:59:21Z canonical: "support.tulip.co/defect-tracking-extend-the-concept" --- > ## 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 - Extend the Concept ## Overview Functional Examples arent intended to perfectly fit any one process or facility, but rather to act as a starting point in building your own order tracking apps. This guide is intended to give you some ideas on how this functional example could be changed and adapted to your process, along with ways it could be combined with other fantastic Tulip use cases. ## Extend the Apps ### Split Apps by Job Function As we talked about in the [App Architecture guide](/r230/docs/defect-tracking-app-architecture) one of the simpliest ways to get value with Tulip is by making apps specific for the users who will be interfacting with them. In most processes, operators will be reporting Defects, but a seperate team will be doing the root cause analysis, taking corrective action, and completing the audit resolution. Seperating this into a seperate app will streamline the operator interface and allow increased controls around user access. ### Modify the User Interface Adoption of a new process is always a challenge in manufacturing, but intuitive apps will always be easier to get buy-in for. Adjust the Functional example to better suit the needs of your users. - Determine which `[Defect Events]` Table Record Fields you want users entering, vs. those that can be automated. - In the Functional Example the description field is automatically generated, but it might make more sense for your users to be able to write a custom note. - Modify defect routing so users only see defects that apply to them. This filtering could happen on the `Next Steps` field, `Reason` field, `Assignee` field, or any other key differentiator for your process. - Add 'quick action' buttons to automate common workflows. Maybe your quality department has standard resolutions to specific defects. These resolutions can be added to buttons that auto-populate the respective table fields. ## Extend the Data Model Each process is unique, and these differences in process almost always mandate some additional data is added to the default data model. As the app builder, you know best where the Common Data Model doesn't match your process, but here are so examples of ways the model could be extended. ### Linked Tables Linked Records allow you to associate one Record with another. This means your `[Defect Events]` table doesn't need the details of the material that was found to be defective, it can instead just reference the *linked* record in the `[Materials]` table. ### `[Materials] Table` ![Defect Events Linked Record (1).png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Defect%20Events%20Linked%20Record%20%281%29.png) The Materials table is intended to be used to track materials, their associated orders, defects, and more. One material can have muliple defects. This associated allow you to track defects by material, and leverage the information about each material in the `Materials` table, while working with its defects. | NAME | TYPE | DESCRIPTION | | --- | --- | --- | | ID | Text | Unique Identifier for record. **Must be unique** | | Material Number | Text | Material Idenfier | | Material description | Text | Human readable description of component | | Status | Text | Current status of the material. Used to track the material through production. | | Type | Text | The type of material e.g. Batch, Unit, Product, Sub-Assembly, Component, Lot etc. | | Unit of Measure | Text | Unit of measure used for the quantity | | Location | Text | Current location of the material | | Quantity | Number | Current quantity of the material | | Photo | Image | Photo of the material item to be produced | | Batch / Lot / Serial Number | Text | Unique reference of the material linking it to the supplier. This is used to extend the tracking of the material to a supplier ( internal / eternal) that is outside of Tulip. | | Order | Linked Record | Order that is using this material item. This is only used for the top level material, the remaining hierachy is developed through the materials child/parent links. | | Child Materials | Linked Record | Materials that are used(combined/assembled) to produce this material | | Parent Materials | Linked Record | Material that is using this material | ### Add Table Fields The `[Defect Events]` table is a good starting point to track the important data around your defects, but probably doesn't include every field important for your process. Maybe you want to also track: - Sunk cost in defective goods (Cost-Of-Goods could come from the *Linked* `[Materials]` table. - Linked Record to the associated `[Orders]` record. ### Add Tables There are dozens of different great uses for Tulip, adding more processes might mandate adding more Tulip Tables. - And-On Tracking - Quality Events - Inspections - Equipment - Shipping/Reciving Orders Any/all of these Tables can be built and incorportated into a core Defect Tracking use case. Because of the flexible nature of Tables, these new Tables can also be managed by dedicated apps. **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.gif)** **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. **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.** **Number** **Number**is a Tulip Datatype. Numbers can be any positive or negative number. Numbers support decimals. *ex. -5, 15, 47, 155, 15.2, -12.73* **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)