Work Instructions Apps Overview

An overview of the Work Instructions App Suite to help you decide which template is best suited for your needs.

What Defines a Work Instructions App?

Work instructions are comprised of sets of procedures. Putting work instructions into applications means utilizing the functionality of the app to aid in completing the instructions with ease and clarity. Work instructions are a means to guide an operator through a procedure, such as an assembly or an inspection. Procedures are made up of a series of tasks containing instructional content. The overall process combines the procedures into a complete work instruction. The hierarchy of these concepts is shown below:

Overall, work instructions apps help fulfill the process by walking the operator through procedures and tasks. But where should you start when creating a work instructions app?

Tulip offers a series of templates that differ based on your needs. In order to choose which app is best suited for your work instructions, let’s go over each app so you know exactly how they work.

Work Instructions App Suite

The work instructions apps are separated into two categories: app-based and table-based. Understanding the differences between app-based and table-based work instructions is crucial to selecting which method is best suited for your needs.

App-Based Templates

App-based work instructions are static and encoded in the app. The data collects into Completion records, which are immutable records of app data.

Single Procedure

This app handles a single work instructions procedure with each task displayed on a single step. The operator completes the procedure by going through the tasks and recording the necessary input field.

The Defect Report step enables you to enter a defect report using fields that store the responses into Variables. These variables save when the user clicks Complete, where a Trigger on the button saves all app data into a completion record.

Finally, the Analytics step consists of a series of analysis Widgets that only show data once the app has been completed by a user. Without any completion records, the analyses have no data to pull from.

Multiple Procedure (One Task per Step)

This app handles multiple work instructions procedures, with each procedure broken up into separate step groups and the individual tasks displayed on their own step. The operator chooses which procedure to go through and each step prompts the user to complete the units according to the instructions on the step.

The Log Defect button on each task step allows the operator to log any defects with the material and detail the defect. All data is saved upon clicking the Report Defect button.

The Analytics step consists of a series of analysis widgets that only show data once the app has been completed by a user. Without any completion records, the analyses have no data to pull from.

Multiple Procedure (All Tasks One Step)

Like the Multiple Procedure (One Task per Step) app, this app handles multiple work instructions procedures, with each procedure broken up into separate step groups. The main difference between the multiple procedures apps is that this app displays the tasks on one step per procedure. The operator chooses which procedure to go through and then completes all the tasks on the following step.

The Log Defect button on each task step allows the operator to log any defects with the material and detail the defect. All data is saved upon clicking the Report Defect button.

The Analytics step consists of a series of analysis widgets that only show data once the app has been completed by a user. Without any completion records, the analyses have no data to pull from.

Table-Based Templates

Table-based work instructions are dynamic and encoded into the tables themselves. The selections made in the app and data from the operator saves into Tables. The information in the tables is not immutable, anyone with access to the tables can change the data within them.

One Task per Step

This app handles multiple work instructions procedures. The operator walks through the procedure tasks step-by-step, based on the procedure they initially select. This app uses two tables, Procedures and Tasks. When the user selects a procedure from the interactive table, the Procedure ID correlates with the associated tasks in the Tasks table.

An aggregation loads only the tasks with the selected procedure number into the following steps by filtering via mode of the task IDs in the table.

By filtering the IDs, only the tasks related to the selected procedure appear. This dynamic configuration allows an operator to complete different procedures and tasks based on their selection.

The Log Defect button on each task step allows the operator to log any defects with the material and detail the defect. All data is saved upon clicking the Report Defect button.

The Analytics step consists of a series of analysis widgets that only show data once the app has data to reference. Without any records, the analyses have no data to pull from.

Procedure Scroller

This app is used for handling multiple work instructions procedures. Procedures are stored in tables that populate when the operator selects the relevant work instruction to reference.

When a user chooses a procedure on the Select Procedure step, that selection is stored in a Linked Placeholder which populates the procedure’s information on the right side of the step.
On the Tasks step, the tasks in the interactive table are filtered from the procedure ID selected on the previous step.

The Log Defect button on the Tasks step allows the operator to log any defects with the material and detail the defect. All data is saved upon clicking the Submit Defect button.

The Analytics step consists of a series of analysis widgets that only show data once the app has data to reference. Without any records, the analyses have no data to pull from.

Procedure Viewer (Mobile)

The Procedure Viewer application is the mobile version of the Procedure Scroller app. From the first screen, the operator has the option to either Select a Procedure, Scan a Procedure, or View Analytics regarding the procedures completed to date.

Similar to the Procedure Scroller template, when the operator selects a procedure then the Procedure ID is used to pull the tasks that share that same ID in their respective record.

If the operator scans a procedure, the ID is loaded into the tasks filter with the following Step level Triggers in the machine and Device section:

To gather more information about the task the operator can select View Details on the View Task step. The View Details step loads information about the selected task from a Table Record.

The Log Defect button on each task step allows the operator to log any defects with the material and detail the defect. All data is saved upon clicking the Submit button.

The Analytics step consists of a series of analysis widgets that only show data once the app has data to reference. Without any records, the analyses have no data to pull from.

Procedure Scroller with Parameters

This app handles multiple work instructions procedures. Procedures are stored in tables that populate the scroller element where the operator can choose the relevant work instruction task. This version contains an additional table, Parameters, to store work instruction parameters.

Use parameters to set limits to your work instructions tasks, such as adding a roof rack to a specific car model or keeping a soldering iron temperature within a specific range.

The Log Defect button on the Tasks step allows the operator to log any defects with the material and detail the defect. All data is saved upon clicking the Submit Defect button.

The Analytics step consists of a series of analysis widgets that only show data once the app has data to reference. Without any records, the analyses have no data to pull from.

Procedure Creator

Use this app to add procedures, procedure steps, and parameters into their respective tables (Procedures, Tasks, and Parameters) provided in the table-based templates of this App Suite.

Using the Add buttons, the user can add procedures, tasks, and parameters to their selections, as well as use the Edit button to modify their selection.

The Procedure Creator app is merely an app to create, edit, and organize the tables in your table-based work instructions apps.

How to Choose the Right Template for Your Needs

The first thing to decide when choosing a template is whether you want to use app-based, table-based, or a mix of both. Tulip services recommends starting with an app-based solution, however there can be some scenarios where you would prefer to use table-based. It’s important to understand app-based vs table-based work instructions in order to weigh all options and configuration methods required with these template types.

First let’s go over specific indications in which app-based and table-based templates are more useful.

Aligning app paths to your workflows ensures that your apps follow your processes and accommodate any tentative changes or parameters in the procedures or tasks. Noting where in the process these changes or parameters appear influences how your app(s) are structured and also how many apps you may want to have.

The following diagram shows popular app paths you might want to follow when designing or adopting your own:

For example, Single Procedure and the One Task per Step applications follow linear paths, whereas the Procedure Scroller and Procedure Viewer apps follow configurable paths. If you’re not sure which app path best suits your needs, map out your process and its potential variations or parameter settings that affect how the app behaves.

Another consideration to make is the expanse of your process including the procedures and respective tasks.

For example, let’s say you’re manufacturing two new car models: one with specific parameters based on a luxury model and the other with standard features. The selection of the car model you make defines the instructions. Your process would look like this:

You could use multiple apps for the different models and store the instructions statically in the app, using completion records to store the data. Or you could use a single app and load the instructions dynamically into the application based on the selection the operator makes. An example of these two options would look like the following:

In the App-based design, the data from each work instructions app saves into separate completion records. This way, the records don’t overlap and they’re easy to distinguish from one another.

In the Table-based design, the data from each work instruction process saves into separate tables, despite them using the same application to host the instructions.

If you’re still unsure which type of app to choose, follow the flow chart below to assess what kinds of configuration needs you have.

For more information and resources on designing an app that's perfect for your needs, take the Tulip University Work Instruction Solution Design course!