---
title: "Defect Tracking App Architecture"
slug: "defect-tracking-app-architecture"
updated: 2022-09-28T18:26:22Z
published: 2022-09-28T18:26:22Z
canonical: "support.tulip.co/defect-tracking-app-architecture"
---

> ## 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 App Architecture

## App Structure

This Functional Example is a single application in the Tulip Library, but much of the value comes with Tulip apps when dedicated apps can be built to support different user roles and needs.

Legacy defect tracking solutions at a best are buggy, one-off point solutions, and at worst, involved dozens of random Excel sheets, paper forms, and many hours spent doing manual data entry.

Defect Tracking is a bit of a unique problem because the best defect tracking solutions exist in-context (within the process where the defect can be found) so the best defect tracking solutions should be usable across all of the process applications where defects might be found. App Transitions can be used to move users from any process app to a central defect tracking app, or the defect reporting function can be copied across all of your applications.

### One Central Defect Tracking App

**PROS**:

- Changes to defect management process are simple, one point of changes
- Seperate team can manage app Versions as opposed to the process apps

**CONS** :

- More disjointed user experience because defects are being entered in a seperate app
- Managing Variables across multiple apps can be a bit more Trigger intensive.

### Defect Reporting in Every App

**PROS**:

- User experience is more seamless.
- Processes with different defect types can have different UIs to better support their standard defects.
- App Variable management is simpler.

**CONS** :

- Many points of changes when process changes do happen. Those changes would need to be applied to each app one-off.
- The same team who manages the process app would own the defect tracking for each of those apps.

## App Breakdown

The Functional Example for Defect Tracking serves as the core functionality needed to track defects:

- Report defects
- Edit defect reports
- (optional) Print defect labels for quarantine
- View defects
- Update next steps and status
- View defect history
- Drive insights about defects with Analytics

As the Functional Example shows, all of the functionality can be combined in a single app, or any of its core functions can be leveraged in more segment applications.

With either approach (listed above), Tulip recommends moving the edit and disposition functons of defects to a seperate application that only users with special permissions have access to. This enables greater control over which users can edit quality critical data.

**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.*

**Transitions**

**Transitions** are a type of logic in **triggers****.** **Transitions** can move operators between steps/apps or start/stop the app.

Only 1 **Transition** can be added to a single **Trigger.**

*ex:* *Complete then change to X app, Next step, Previous step, Cancel app, etc.*

**Published Version**

The **Published** **Version** of a Tulip app is a complete version of your Application. When an app is ready to be run in production, its logic can be *frozen* by Publishing that app. One application can have multiple published versions. If a **Station** is assigned to run the Published version of an application, it will only see changes when they are published.

**Variables**

**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.

**Trigger**

**Triggers** are groups of logic that are tied to an app event, such as step open, timer, widget interaction, etc. App builders can add triggers to **widgets**, **machines**, **devices**, **apps**, and **steps**.

**Triggers** can contain **actions**, **transitions**, and **conditions**.

**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.

**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)