--- title: "Work Instructions Apps Overview" slug: "work-instructions-apps-overview" updated: 2024-01-15T14:09:03Z published: 2024-01-15T14:09:03Z canonical: "support.tulip.co/work-instructions-apps-overview" --- > ## 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. # Work Instructions Apps Overview To download the app, visit: [Library](https://tulip.co/library/suites/work-instructions-templates/) *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: ![Process Hierarchy.jpg](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Process%20Hierarchy.jpg) 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](https://tulip.co/library/suites/work-instructions-templates/) 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](/r230/docs/app-based) 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. ![WI Single Procedure.gif](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/WI%20Single%20Procedure.gif) 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. ![WI Single Procedure Analytics.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/WI%20Single%20Procedure%20Analytics.png) 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. ![WI Multiple Procedure 1 per step.gif](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/WI%20Multiple%20Procedure%20%281%20per%20step%29.gif) 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. ![WI Multiple Procedure Multiple step.gif](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/WI%20Multiple%20Procedure%20%28Multiple%20step%29.gif) 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](/r230/docs/table-based) 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. ![WI One Task per Step.gif](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/WI%20One%20Task%20per%20Step.gif) 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. ![WI One Task per Step Aggregation.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/WI%20One%20Task%20per%20Step%20Aggregation.png) 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. ![WI Procedure Scroller.gif](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/WI%20Procedure%20Scroller.gif) 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. ![WI Procedure Scroller Task Filter.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/WI%20Procedure%20Scroller%20Task%20Filter.png) 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. ![WI Procedure Scroller Mobile.gif](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/WI%20Procedure%20Scroller%20%28Mobile%29.gif) 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. ![WI Procedure Scroller Task Filter.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/WI%20Procedure%20Scroller%20Task%20Filter%281%29.png) 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: ![WI Procedure Scroller Mobile Load Procedure by ID.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/WI%20Procedure%20Scroller%20%28Mobile%29%20Load%20Procedure%20by%20ID.png) 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. ![WI Procedure Scroller with Parameters.gif](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/WI%20Procedure%20Scroller%20with%20Parameters.gif) 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. ![WI Procedure Creator.gif](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/WI%20Procedure%20Creator.gif) 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. | App-based | Table-based | | --- | --- | | Low-mix process | High-mix process | | Logic-dependent or branching progression through the application | Common app progression | | Regulated industries where procedures must be tightly controlled, with all changes approved | Less regulated industries where the emphasis is on efficiently delivering work instruction content, which can be changed quickly across many interfaces | | Process settings (such as torque, temperature, tooling) are standard across product families and relatively few | The process may be the same, at a high-level, but the settings or parameters are highly sku dependent and can be loaded into a common app from a table | | High dependency on devices or variable user inputs throughout the workflow | Low dependency on devices or variable user inputs throughout the process | 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: ![Pretty App Patterns.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Pretty%20App%20Patterns.png) 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: ![WI Example Process Diagrams.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/WI%20Example%20Process%20Diagrams.png) 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: ![WI App-based Design.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/WI%20App-based%20Design.png) 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. ![WI Table-based Design.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/WI%20Table-based%20Design.png) 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. ![Flow Chart Final.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Flow%20Chart%20Final.png) For more information and resources on designing an app that's perfect for your needs, take the Tulip University [Work Instruction Solution Design](https://university.tulip.co/work-instructions-solution-design) course! **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. **Variables** **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. **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**. **Widgets** **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.* **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) **Linked Placeholder** **Linked Placeholder**are one of the**Side Pane**settings for the Interactive Table **Widget**and **Record** **History** Widget**.**This setting can be tied to a **Table Record Placeholder,**and when users select a row in the **Widget,**that record is loaded into the mapped **Record Placeholder.** **Step-Level Trigger** A**step-level trigger** is a trigger configured with each app step. Step-level triggers can be triggered based on 4 actions: 1. Step Opened 2. Every X seconds (Timer) 3. Machine/Device outputs data 4. Step Exited **Device** Devices are tools or pieces of hardware that are integrated into Tulip applications. Examples include barcode scanners, digital scales, or Zebra printers. Devices must be connected to applications on the **Shop Floor**pages after an application has been assigned a **Station.**Not to be confused with **Display Devices,**or the interfaces through which an end user accesses an application**.** **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.**