Table Structure for Work Instructions Apps

Learn how to structure your tables for work instructions applications.

Tulip Tables are a means of organizing, storing, and using data in applications. Tables contain information organized into fields (columns) and records (rows) that you can customize and configure to your specific needs. You can use tables in a single app or across multiple apps.

What are Work Instruction Tables?

Manufacturing processes are often executed as a series of activities accomplished in sequence. In a table-based work instruction design, the details of the particular activities that constitute a process are held in Tulip tables. Work instructions tables are Tulip Tables that store information about the procedures and tasks that make up the entire process.

As you can see in the process diagrams below, a process is comprised of a series of procedures completed in sequence. Each procedure itself consists of a sequence of tasks. In a table-based work instruction designs, procedures and tasks are stored in tables, and application logic provides an end user with the steps appropriate to their location in a sequence of work.

Process Diagram 1 shows the flow consequential relationship between procedures and tasks, under one process.

Process Diagram 2 shows the hierarchical structure of process, procedures, and tasks.

In a table-based work instructions design, the applications contain a set number of embedded table records or variables that are mapped fields in a table. Rather than the instructions being hard-coded onto the steps themselves, they are organized in the tables to display when the user selects the appropriate current task. These procedures and tasks are then dynamically fed into the app based on the selected procedure.

Displaying instructions dynamically using tables allows for flexibility when building and using an application. Use one app to go through multiple procedures and display the tasks in sequential order according to your table set up. Below, we’ll go over possible table structures as well as considerations you should make when setting up your tables.

How to Structure Work Instructions Tables

There are multiple ways you can structure your tables. In this section we’ll walk through example tables from the Work Instructions app suite, explaining their relationship to each other, and go through some considerations you should recognize before making decisions regarding your own Work Instructions tables.

First, let’s look at an example using an app from the Work Instructions App Suite:

Example

The Procedure Scroller app uses two tables: Procedure and Tasks. The Procedure table has five fields: ID, description, Type, Item Master, and Tasks. Both the Item Master and Tasks fields use linked records for their data type, which means that the field shares data with another table’s field.

The other table, Tasks, includes a linked record field which connects to the ID field in the Procedure table. This field indicates the Procedure ID that the task belongs to.

In the Tasks table above, the linked field named Procedure establishes a relationship between the two tables. The text field to the right, also named Procedure, is used in an aggregation.

When a user selects a procedure, the ID is used to populate the tasks which include the same Procedure ID in their respective table. Here’s what this looks like in the application:

Remember, this is just one example of how you can configure tables to store work instructions information to populate dynamically in an app. When it comes to your own apps, stick to a configuration that is accessible and manageable for your process.

Methodology

Before you can jump into configuring tables, there are a few details to consider beforehand to ensure proper setup, customizing, and usage.

Set Up

• Who will set up and manage the table(s) and the app(s)?
• How many apps are needed to complete the process flow?
• How many different procedures do you have in your process?

Structure

• How many tables do you need? (Tulip typically uses one table for procedures, one for tasks, and one for parameters, if needed)
• Are your tables used in multiple apps?
• How many fields do you need?
• If using multiple tables, what information overlaps between them?

In-App Usage

• What is the layout of your app in relation to the instructions?
• How will the user interact with the table(s)?
• What information do you want to display in the app from the table(s)?

Understanding the full scope of your app and the information you want to present to the user is essential to building a table-based work instructions app.

Further Reading

• App-based vs Table-based
• Work Instructions Apps Overview