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 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 covers some opportunities to extend this data model, including more extensive interconnectivity with Order Tracking, or other use cases.
[Defect Events] Table
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 MaterialVariable 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.
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:
NEW
IN REVIEW
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 HistoryWidget 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.
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.
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.
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 Field
Table Record Fields are single columns within a Tulip Table.
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.
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.
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. Uservariables 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.
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.
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.
Datetime
Datetimes are a Tulip Datatype. Datetimes represent a time in the ISO8601 format.
ex. 2022-08-31T19:56:16+00:00
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.
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.
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.
Was this article helpful?
Thank you for your feedback! Our team will get back to you
.gif)
