---
title: "Completions"
slug: "completions"
status: "update"
updated: 2026-04-13T19:45:30Z
published: 2026-04-13T19:45:30Z
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 {{glossary.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 {{glossary.Trigger}}s to save data at any point deemed valuable (e.g. when a process is completed).

Completions are a data storage method, like [{{glossary.Table}}s](/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){height="" width=""}

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
* {{glossary.Station}} name
* Comments
* App {{glossary.Version}}
* Execution ID
* {{glossary.Cancel}}ed (whether or not the app was canceled)

Signature data from the {{glossary.Electronic Signature}} widget also saves into the completion records. You can save additional information using {{glossary.Variable}}s 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

:::(Info) (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 {{glossary.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){height="" width=""}

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 {{glossary.Table Record}}s with one timestamp
* Reset all variables to their default value (unless they are set to not clear on completion)
* Clear all table {{glossary.Record Placeholder}}s
* Load the most recent {{glossary.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){height="" width=""}

### 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){height="" width=""}

## Technical behavior

Completion record saves are initiated by the following triggers:
1. The **Save all App Data** action
2. Any {{glossary.Cancel}} / {{glossary.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.

:::(Warning) (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 {{glossary.Variable}}s 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 {{glossary.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 [{{glossary.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 {{glossary.Analytic}}s 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 {{glossary.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){height="" width=""}

### Record history widget

The {{glossary.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.

:::(Info) (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){height="" width=""}

## 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/tulip-data-model-gxp/95360)


{{snippet.Did you find what you were looking for}}