---
title: "Order Tracking - Extend the Concept"
slug: "order-tracking-extend-the-concept"
updated: 2022-09-27T13:33:10Z
published: 2022-09-27T13:33:10Z
canonical: "support.tulip.co/order-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.

# Order 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](https://support.tulip.co/docs/order-tracking-app-architecture) one of the simplest ways to get value with Tulip is by making apps specifically for the users who will be interacting with them.

In most processes, operators won't be doing everything from creating orders, to scheduling them, to auditing them. Splitting these different job functions by job function will really streamline the training process, and enable iteration on each sub-process even faster.

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

- Adjust the fields visible in the Interactive Table Widget to display the important information to your operators.
- Add/Combine App Steps to better suit your users and process.
- Add buttons to complete common actions. *For example*, maybe your Production manager often needs to send emails to the fulfillment department when a material is out of stock. Add a button to your app where an [email will be automatically](https://support.tulip.co/docs/how-to-send-emails-to-users-dynamically)  to the fulfillment requesting a reorder for the selected component.

### Add More Functionality

### Quality Inspection

Most processes require quality inspections. Adding an interface to collect inspection data, and writing those results to the `[Defect Events]` table (with Linked Records to the Order) will enable further visibility into the historic order information critical in the case of an audit.

### Material Tracking and Geneaology

In the case of defective finished goods, the ability to track back the source of all of the components of the defective components. The `[Materials]` table is actually setup in advance to be able to support this sort of visibility. The Linked Record fields for `Parent Materials` and `Child Materials` already exist in the `[Materials]` table so genealogy can be automatically tracked.

### Request for Assistance

We have all seen operators walking around the production floor looking for a supervisor to ask a question. Building out native And-on functionality that automatically triggers a request for help can save on *motion* waste and get production critical issues resolved more quickly.

### Order Auditing App

The Functional Example assumes the process is being followed, but often its deviations from a process that drive manual, highly wasteful, processes. Adding an app to your process to allow *power users* to deep dive into the historical information about an order, and untangle any crossed wires all in one place can really streamline the process of completing orders.

## Extend the Data Model

Each process is unique, and these differences in the process almost always mandate some additional data be 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 some examples of ways the model could be extended.

### Linked Tables

Linked Records allow you to associate one Record with another (or multiple others). This means your order table doesn't need the details of each component needed to complete it, but instead can just reference the record where that information lives.

![https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Order%20Tracking.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Order%20Tracking.png)

### `[Materials] Table`

![https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Materials.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Materials.png) {height="" width="200"}

The Materials table is intended to be used to track the upstream materials required to complete the order.

One order can have multiple *linked* materials, to reflect the BOM required to complete an assembly.

### Add Table Fields

The `[Orders]` table is a good starting point to track the important data around your orders but probably doesn't include every field important for your process. Maybe you want to also track:

- Order Value
- Link to ERP Order
- Sales Representative to reach out to with issues
- [Inspections](https://support.tulip.co/docs/order-tracking-extend-the-concept#quality-inspection) on that order
- Customer deliverables like PDF inspection reports, STL part files, and more.

### 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/Receiving Orders

Any/all of these Tables can be built and incorporated into a core Order Tracking use case. Because of the flexible nature of Tables, these new Tables can also be managed by dedicated apps.

| NAME | TYPE | DESCRIPTION |
| --- | --- | --- |
| ID | Text | Unique Identifier for the record. Must be unique |
| Material Number | Text | Material Identifier |
| Material description | Text | Human readable description of the 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 | The 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 | The order that is using this material item. This is only used for the top-level material, the remaining hierarchy 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 |

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

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

**Steps**

A view your users will see within an application. **Steps** can be viewed chronologically or in whatever order best fits your process.

Steps can be grouped into **Step Groups** to manage and organize your app Steps.

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

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

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