---
title: "Digital Traveler Use Case"
slug: "digital-traveler-use-case"
updated: 2024-01-12T21:38:10Z
published: 2024-01-12T21:38:10Z
canonical: "support.tulip.co/digital-traveler-use-case"
---

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

# Digital Traveler Use Case

*Imagine you’re an industrial engineer responsible for improving an assembly process. Your supervisor tasks you with decreasing cycle time. After overseeing several orders, you note that operators are spending a significant amount of time filling out paperwork. Not only are operators responsible for sections of the assembly, but they also have to manually record data for each step, including down parts, serial numbers, and spec requirements with critical measurements. Then, quality managers need to verify all data entries for accuracy and to ensure all fields are filled in. This tedious paper process is costing the company and employees time, money, and resources that could be saved or allocated elsewhere. To solve this problem, decrease time to delivery, and error proof the data collected by everyone involved in assembly, you introduce digital traveler applications.*

Digital traveler refers to the collective digital documentation of the materials and processes that go into the production of an item. The details in this documentation can include order information, product parts, [Bill of Materials (BoM)](https://tulip.co/blog/bill-of-materials-bom-management/), datetime intervals, product routing, cycle time, yield, and related production metrics. Digital travelers are an optimal solution in place of paperwork that can transform your process.

![Paper%20vs%20Digital%20Traveler](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Paper%20vs%20Digital%20Traveler.png) *Paper travelers vs. digital travelers*

## Impact and Requirements

Digital travelers increase the efficiency of an operation by eliminating the inefficiencies introduced by paper. It sounds obvious, but it’s important to drill down and look at how this works in practice.

1. **Saving time**: If you’re using and storing stacks of paperwork for each item’s production, digital traveler applications reduce administrative work and the time for manual entry. You can use the extra time to analyze the data you’re collecting, and then drive continuous improvements.
2. **Error proofing**: If your operators are entering data in the incorrect format—or just incorrectly— digital travelers can error proof your documentation by setting required data formats and automating data collection.
3. **Data accessibility**: Paper travelers are prone to mistakes between incorrect documentation, corrupted or altered data, or getting lost.

All these scenarios create disruptions on the production line that can be detrimental to order fulfillment.

There are several benefits of using digital travelers in your production operations. The table below highlights how to accomplish each:

| Benefit | Means |
| --- | --- |
| Traceability and Serialization | Data collection that becomes widely available and simple to track throughout production |
| Real-time data collection & visualization | Immediate data saving that updates cycle times, WIP tracking, and pareto charts |
| Reduce admin work | Reduced time on data entry and corrections |
| Error proofing | Required data formats, standardized inputs, and intentional |
| Genalogy | Regulatory tracking, eliminates the potential of losing paper travelers |

Digital travelers increase production efficiency and the visibility into production status. Because the data is widely available, any personnel who needs access to the data can do so immediately.

Digital travelers are valuable across all industries. Operations with low volume, high mix, and long lead times can especially benefit to not lose information throughout the process. For this use case, you need to understand [data collection](/r230/docs/data-storage-1) in Tulip, including [Completions](/r230/docs/overview-of-completion-records) and [Tables](/r230/docs/an-overview-of-tables), and [configuring Trigger logic](/r230/docs/what-are-triggers). Additionally, the use of plug and play devices such as [barcode scanners](/r230/docs/how-to-set-up-a-barcode-scanner) further reduce human error.

## How to Get Started

Digital traveler apps are an ideal first use-case with Tulip because they collect data and create visibility. Visibility drives continuous improvement which makes tracking more valuable. When building digital travelers, remember to break down the process into many apps. Apps should be divided by physical location, such as assembly stations.

![Shop%20Floor%20Stations%20to%20Apps%20Mapping](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Shop%20Floor%20Stations%20to%20Apps%20Mapping.png) *Shop floor stations that tie to their app's purpose*

This architecture simplifies apps and clearly identifies each one’s functionality. For each app you have, follow these steps to ensure optimal capability:

1. **Identify the app’s purpose and who will use it**. These decisions dictate the content and output. Here are some examples:

| Purpose | User |
| --- | --- |
| Document materials and parts used during assembly | Assembly operator |
| Spec requirements/critical parameter measurements | Machine operator |
| Assembly oversight and management | Production supervisor |
| Assessment of delivery timeline | Delivery coordinator |
| Data validation | Qaulity assurance |

1. **Determine the data collected in the app**. Decide what data will be stored in immutable completion records or in tables. Apps reflect a process and so completions gather process data, whereas tables collect information that informs a process. For example, units of measurement, sensor readings, and unique IDs should be stored in completions with Variables. Whereas other information like equipment, materials, batches/lots, and user comments should be stored in Table Records.
2. **Build an application and necessary tables to store data. Start simple then gradually get more complex as needed**. Begin using [buttons](/r230/docs/how-to-use-buttons-in-apps) and Input Widgets to store values.
3. **Deploy and reiterate**. The best way to optimize digital travelers is to start collecting data and revamp the app from there.

Here’s what data inputs can look like in an assembly app:

![Motor%20Assembly%20Example](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Motor%20Assembly%20Example.png) *Example 1 : Input widgets collect lot numbers.*

![Work%20Instructions%20Rotor%20Assembly%20Barcode%20Scanner](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Work%20Instructions%20Rotor%20Assembly%20Barcode%20Scanner.png) *Example 2: Input widgets use device triggers that use a barcode scanner to collect lot numbers.*

A production manager app that reviews lot information could look like this:

![Rotor%20Assembly%20BOM%20Order%20Tracker](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Rotor%20Assembly%20BOM%20Order%20Tracker.png) *Example 3: Collected data displays the lot produced on the left and the component items with respective information on the right.*

Consider using plug and play devices like [barcode scanners](https://tulip.co/library/devices/barcode-scanners/) to help contextualize data to a specific part. You can easily identify materials and batches/lots with a barcode. The key is using them as a device with [device triggers](/r230/docs/how-to-add-device-triggers), not just using them as a keyboard to enter data. Once you feel comfortable with collecting data, you can extend your digital travelers to other use cases, such as work instructions.

Additionally, once your digital travelers are successfully working with your operation, you can deploy other use cases such as [Performance Visibility](/r230/docs/performance-visibility-use-case) and [Production Tracking](/r230/docs/production-tracking-use-case).

It’s important to note the challenge of wanting to automate each and every process within travelers. As you build out apps, consider the steps that are simple to automate, like data entry and capturing cycle times, compared to the manual steps like operator annotation. **A digital traveler will not look like a paper traveler**. Brainstorm the ways you can accomplish the same result with different paths (such as annotations in the form of comments).

### Tulip Resources

Whether you want to learn more about Tulip features to build digital traveler apps or you want to use Tulip’s ready-made templates, we have the tools to help you get started.

#### Videos

- [Completions vs. Tables](https://tulip.co/library/videos/completions-vs.-tables/)
- [Passing Data Between Apps](https://tulip.co/library/videos/passing-data-between-apps/)

#### University Courses

- [Working with Data and Tables](https://university.tulip.co/working-with-data-and-tables?_ga=2.111793986.773738623.1701200316-1575919792.1661456261)
- [Store a User Input Value](https://university.tulip.co/store-a-user-input-value-in-a-variable)

#### Library Apps

- [Traveler and Material Flow Dashboard](https://tulip.co/library/apps/traveler-and-material-flow-dashboard/)

#### Examples

- [Tulip Data Functional Example](https://tulip.co/library/apps/tulip-data-functional-example/)
- [Simple Checklist Functional Example](https://tulip.co/library/apps/simple-checklist-functional-example/)

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

**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(1).gif)

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

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

**Input Widget**

**Input widgets**are a set of **Widgets**specifically designed for users to enter information. Input widgets must be associated with a location where the user input is stored.