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

{{glossary.Functional Example}}s 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 {{glossary.Widget}} to display the important information to your operators.
- Add/Combine App {{glossary.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 {{glossary.Linked Record}}s 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 {{glossary.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 {{glossary.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

{{glossary.Linked Record}}s allow you to associate one {{glossary.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){height="" width="400"}

### `[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 {{glossary.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 | {{glossary.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 | {{glossary.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 | {{glossary.Linked Record}} | Materials that are used(combined/assembled) to produce this material |
| Parent Materials | {{glossary.Linked Record}} | Material that is using this material |