--- title: "Completions" slug: "completions" status: "update" updated: 2026-08-13T10:01:07Z published: 2026-08-13T10:03:28Z canonical: "support.tulip.co/completions" --- > ## 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. # Completions *Learn the basics of completion records and how you can optimize them for use in your application data.* ## Overview A Completion record is an immutable set of data that stores its values from a Tulip app. Records are saved automatically when an app is completed. You can also use Triggers to save data at any point deemed valuable (e.g. when a process is completed). Completions are a data storage method, like [Tables](/r230/docs/an-overview-of-tables). However, unlike tables, completion records cannot be altered or changed, ensuring that the data is captured honestly. Tulip recommends utilizing both completions and tables for your [data collection](/r230/docs/gxp-data-collection) methods. To access an application’s completion records, navigate to the **App Info** page and click the **Completions** tab. ![Go to Completions](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Go%20to%20Completions.gif) There are several fields of completion data which automatically save in every app when it’s completed or canceled, such as: - App duration - Start and end time - Durations for each Step completed - Logged-in user - Station name - Comments - App Version - Execution ID - Canceled (whether or not the app was canceled) Signature data from the Electronic Signature widget also saves into the completion records. You can save additional information using Variables and configuring a trigger to save them. ## When to use completions Completion records store values from variables, app steps, timestamps, user info, electronic signatures, and more. While you can also use tables to store data, there are distinct scenarios more suited towards using completion records, such as: - User or machine captured values, including photos, results recorded for critical process parameters, sensor readings, etc. - Units of measurement that pair with captured values. It is best practice to separate UoM variables in addition to measurement variables. - Contextual information to ensure history records are human readable. For example, step names or a unique ID captured at the start of each app cycle to enable easy search - To capture cycle times of a process App, down to the level of each Step in the App ## Save completion data NOTE Completion data only saves when you run an app. Testing an app in development mode will not save completion records, however it will show a simulated completion record. ### Complete app While completion data saves automatically when a user completes an app, there still must be a trigger with a Transition to [complete the app](/r230/docs/how-to-complete-an-app). ![Complete%20App%20Trigger](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Complete%20App%20Trigger.png) Completing an app will… - Save all metadata fields from the app - Store the current values of all app variables - Store current field values of all loaded Table Records with one timestamp - Reset all variables to their default value (unless they are set to not clear on completion) - Clear all table Record Placeholders - Load the most recent Published Version of the app* *if the station is configured to run the most recent published version ### Cancel app The **Cancel App** transition performs the same operations as **Complete App** with the added function that all variables in the app reset to their default value. ![Cancel%20App%20Trigger](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Cancel%20App%20Trigger.png) ### Save all app data This action saves metadata fields, current values of variables, and field values of loaded table records from the app. Unlike the **Complete App** transition, **Save All App Data** does not reset variables to their default value or clear table record placeholders. ![Save%20All%20App%20Data%20Trigger](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Save%20All%20App%20Data%20Trigger.png) ## Technical behavior Completion record saves are initiated by the following triggers: 1. The **Save all App Data** action 2. Any Cancel / Complete app action. Completions can also be initiated during the following scenarios: 1. A user logs out, and the instance has Validation Mode enabled 2. The Player account setting **Cancel running apps when operator logs out** is enabled During a completion save, Tulip takes a snapshot of app data to send to the server and write to the database. Additional information for the snapshot is then recorded from other Tulip services. For table records, completions snapshot only the **record ID** at the time the completion process starts. The record IDs in the completion are used to request the full record data. Therefore, a completion does not immediately capture the full set of field values for a table record. This behavior minimizes data transfer and system load time. Table record discrepancy warning Because of this behavior, it is possible for a completion save action to initiate, and then a table record update action occurs before the completion save has been processed. This scenario may result in the completion record capturing the updated table record value, instead of the original record value at the time the completion save action was initiated. To avoid the possibility of table record data discrepancies in completion records, consider the following methods: - Use separate triggers for **Save all app data** actions and **Table record update** actions - Save key record fields to Variables before starting a completion save action ## Limitations and best practices Completion Records enable easy storage of immutable data records; however, the stored data cannot be sent offline to a third-party system, such as a Business Intelligence platform. Completion records also cannot be used as an input to another variable or trigger action. In an operational/process app a Completion Record should be saved at the end of the process. Especially in GxP industries, it’s recommended to use **Save All App Data** upon exiting any process step. In non-operational-process use cases (e.g. a Work Order Management app), a completion record should be created at the end of the process (e.g. at the end of creating a Work Order) to have a simple audit trail of the app’s usage. These completion records provide immediate answers to question such as: - When was the app last used and by whom? - How often is the app used? - Is the app being canceled and at what step? It’s best practice to clear data in variables once a single process is complete in an app. Each variable should also follow [good naming conventions](/r230/docs/best-practices-for-naming-elements-in-tulip), especially if you plan on viewing the data via the Record History widget. ## View completion records in an app There are two ways to use data from completions in an app: - in an [Analysis](/r230/docs/completions#use-completion-records-in-analyses) - in the [record history widget](/r230/docs/completions#record-history-widget) Note that data in completion records is not accessible via the [Tulip Table API](/r230/docs/how-to-use-the-table-api). ### Use completion records in analyses Just like using Analytics to create analyses from table or machine data, you can also create them using app data. Embed an analysis in an app to show information about cycle times, shift duration, or completed units. [Create a new analysis](/r230/docs/how-to-create-a-new-analysis) from one or [multiple apps](/r230/docs/how-to-analyze-data-from-multiple-apps). Once you’ve created the analysis, use the analysis Widget in an application and choose the analysis you want to embed. ![Completion%20Analysis%20in%20App](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Completion%20Analysis%20in%20App.png) ### Record history widget The Digital Record History widget reveals the process data associated with each completion record. It’s a scrollable widget that you can also apply filters to in order to sort through records. You can also view electronic signature data. Read [Using the Record History Widget to View Changes to Table Records](/r230/docs/using-the-record-history-widget-to-view-changes-to-table-records) to understand how you can configure this widget. NOTE The record history widget is available only for Enterprise customers. ![Record%20History%20Widget%20Ex](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Record%20History%20Widget%20Ex.png) ## Further reading - [Data Storage](/r230/docs/data-storage) - [Common data model](/r230/docs/common-data-model) - [Tulip University brief - app completions and tables](https://university.tulip.co/learn/courses/98/gxp-data-storage-ebook) --- Did you find what you were looking for? You can also head to [community.tulip.co](https://community.tulip.co/?utm_source=intercom&utm_medium=article-link&utm_campaign=all) to post your question or see if others have solved a similar topic! **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. **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**. **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) **Station** **Stations** are a digital representation of a physical place or device in your facility. Stations are 1:1 with **Interfaces (display devices)** running Tulip Player, but Stations can also be assigned **Edge Devices,** Tulip Vision Camera Configurations, Machines, and more. **Published Version** The **Published** **Version** of a Tulip app is a complete version of your Application. When an app is ready to be run in production, its logic can be *frozen* by Publishing that app. One application can have multiple published versions. If a **Station** is assigned to run the Published version of an application, it will only see changes when they are published. **App Cancel** **App Cancels** are a restart of an application without storing its data in a **Table.** By default, after a cancellation users will be brought back to the **Begin Screen** of your application. This behavior can be adjusted with other **Transition** types. **Electronic Signatures** In regulated environments (GxP) getting a user signature to the accuracy of data is critical for process validation. The **E-Sig Widget** allows users to collect user signatures along with associated metadata. **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. **Transitions** **Transitions** are a type of logic in **triggers**. **Transitions** can move operators between steps/apps or start/stop the app. Only 1 **Transition** can be added to a single **Trigger.** *ex: Complete then change to X app, Next step, Previous step, Cancel app, etc.* **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.** **Table Record Placeholder** A **Table Record Placeholder** is a reference to a row in a **Tulip Table**. Table Records can be created either from the Table UI or from an App Trigger. **Published Version** The **Published** **Version** of a Tulip app is a complete version of your Application. When an app is ready to be run in production, its logic can be *frozen* by Publishing that app. One application can have multiple published versions. If a **Station** is assigned to run the Published version of an application, it will only see changes when they are published. **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. **GxP** **Good *X* Practice**. An abbreviation collecting many of the core principles of Life Sciences compliance. *ex-* - *GMP - Good Manufacturing Practice* - *GLP - Good Laboratory Practice* - *GDP - Good Distribution Practice* **Analysis** An **analysis** is a live updating combination of a data query and a visualisation. It allows to show metrics based on app completion data, Tulip Table data, or machine data. Analyses can be embedded and dynamically filtered within apps, placed on dashboards and shared via a direct link Example - Bar chart ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/image-1662410531382.png) **Analytic** **Analytics** are live updating graphs and metrics calculated based on app data, Table data, and machine data. Analytics can be embedded and dynamically filtered within an application. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/image-1662410531382.png) **Widget** **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.* **Digital Record History Widget** The **DRH Widget** allows users to review the changes that have occurred to a **Record.** Traceability to changes is critical in a **GxP** Environment.