---
title: "Record history widgets"
slug: "record-history-widgets"
updated: 2025-04-09T17:50:59Z
published: 2025-04-09T17:50:59Z
canonical: "support.tulip.co/record-history-widgets"
---

> ## 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.

# Record history widgets

*Learn when to use the record history widget and how to configure it for your needs.*

          Who can use this feature

          

Users on Regulated plans.

The record history widget (RHW) shows recorded data that regards a specific Table Record. These can include:

- Changes to the table record
- Data from Completion records
- Electronic Signatures, if it includes the record as signed data

![Record History Widget scroll through](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Record%20History%20Widget%20scroll%20through.gif)

It’s important to understand [GxP Data Collection](/r230/docs/gxp-data-collection) in Tulip to know when you should use the record history widget.

The widget can be used for use cases where you want to capture the history of a given manufactured item, such as

- Logbooks
- Compliance and traceability
- Digital history records

## How does the record history widget work?

The record history widget offers visibility for a specific record ID by gathering and displaying data from the following sources:

- Apps
- Table API
- Table UI (admin interface)
- Automations

![RHW update source types](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/RHW%20update%20source%20types.jpg)

The diagram above shows examples of updates per various sources.

**The record history widget shows the following data related to one record ID.**

- Any changes to fields of that record through an App, the Table UI, Table API, Automations
- Any completion data that was pointed by a Record Placeholder at time of completion for apps
- Any signature that includes the record as signed data

The widget shows the chronological history of the record in a scrollable view and updates when it is refreshed (e.g. Step changes). This view allows the user to see what has happened to or related to that record since its creation.

For example, if a record is updated via an app, an automation, or the Table UI, the changes are sequentially logged by the widget.

![RHW workflow diagram](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/RHW%20workflow%20diagram.jpg)

The workflow diagram above illustrates how different sources of record information are captured by record history widget. Each step saves a new iteration of the original variable. The record history widget details each update made through the app's duration.

## How is data displayed in the record history widget?

### Sections

Data collected from each source is visualized using sections and entries. All data is shown in chronological order and sections group data with the same session. The session is defined by different elements depending on the data source:

- **App**: User + App(Version) + Station
- **API**:  API (Token)
- **Table UI**: User + Admin Interface
- **Automations**: Automation Name

A new section is shown when an entry was not created from the same session as the previous one. For example:

- The user running an app has changed
- A record is first updated from an App and then from the Admin Interface

![RHW entry sections](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/RHW%20entry%20sections.png)

### Entries

Within each section there are one or multiple entries. Entries can contain information about record changes, signatures, or completion records. **All entries are accompanied by a timestamp.**

#### Entries related to record changes

Entries, related to the change of a record, show the full history of the record including modifications. These include:

- Creation of a record
- Update of a record
- Deletion of a record
- All records deleted
- Step / App changes (these entries occur if there is data collected in this step)

![RHW old vs new record](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/RHW%20old%20vs%20new%20record.png)

The example above illustrates a user (**John Smith**) + app (**Assemble History Tester**)+ Station (**Unnamed**) section header along with 2 entries. The first states the app step and second shows updated records with old and new values.

## Collect different types of data

### [Completion records](/r230/docs/overview-of-completion-records)

Completion records capture process data of an App such as values of Variables, loaded record placeholders, and metadata like user, station, etc. A new completion record is created for the app whenever an app is completed, canceled, or when the **Store all app data** trigger action is executed. The collected data is labeled as **Logged process data** in the record history widget.

![RHW logged process data](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/RHW%20logged%20process%20data.png)

Requirements for inclusion of completion data in the record history widget:

- The record is loaded into any Table Record Placeholder when the completion record is created
- The Table Record Placeholder is set to **Save for Analysis**

Data shown in record history:

- **Values of Variables**: All variables set to "save for analysis" are included.
- **Record ID**: The ID of any record loaded into a record placeholder that is set to "save for analysis." This excludes the record for which the record history is shown.

### Changes to Table Record Data

Changes to table record data can be done through three sources:

- In an app, through Record Placeholders (Ran **App X** from **Station Y**)
- Tables UI (Admin Interface)
- Tables API
- [Automations](/r230/docs/automations)

The record history widget shows information regarding changes to a table record, such as:

- What was the change?
- Who updated it?
- From which channel did the update happen? (Apps, Tables UI, Table API)
- What was the interface it was updated in?
- When did the change happen?

#### Changes to Record through Record Placeholders

*“John Smith ran App X at Station Y”* All changes made to the individual record display in the widget appear in a section with before-and-after snapshots of the table record. These changes appear no matter which app you use.

**Example** ![RHW old vs new display](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/RHW%20old%20vs%20new%20display.png)

#### Changes to Record through Tables UI (Admin Interface)

*“Updated the record through the admin interface”* Changes made through the tables admin interface are shown in a new section. Every change appears in a separate entry, including:

- Logged-in User
- Type of Change
- Old vs. New Values
- Timestamp

**Example**

![RHW admin interface update](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/RHW%20admin%20interface%20update.png)

#### Changes to Record through Table API

*“Updated record from the API"* API requests that change the specified table record display in a new section, including:

- API Token
- Type of Change
- Old vs. New Values
- Timestamp

**Example**

![RHW API key update](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/RHW%20API%20key%20update.png)

#### Changes to Record through Automations

*“Automation X updated the record"* Changes to table record can be done using automations. These are displayed in a new section, including:

- Automation Name
- Type of Change
- Old vs. New Values
- Timestamp

**Example**

![RHW automation update](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/RHW%20automation%20update.png)

## Configuration

### Add the record history widget to an app step

1. In the App Editor, click **Embed** from the toolbar.
2. Select **Record History**.

![embed RHW dropdown](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/embed%20RHW%20dropdown.png)

### Configuration options

Configure the record history widget in the Side Pane.

![RHW Configuration](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/RHW%20Configuration.png)

#### Linked placeholder

Select the record placeholder that will load the records and record history.

#### Enable printing

An option to print the record history from the Tulip Player. When enabled, a **print** button displays in the header of the widget.

#### Sorting default

Choose to sort the data in the widget by either:

- Newest to oldest
- Oldest to newest

#### Filters

You can filter your record history either dynamically (through a variable, table record, or App Info) or through a static value determined by your filter type. The available filter types are:

- Datetime
- App name
- Step name
- Table field name (Fields from the table in which record placeholder was linked)
- User (User utilizing the app)

**Tulip recommends using the following filters at a minimum, as they slice data into a more digestible view for users:**

- Datetime
- App name
- Step name

#### Hide “old” values in record updates

When enabled, the user can only see the updates and the ‘new’ values of the records.

#### Hide process data

When enabled, saved variable data from apps are hidden in the widget. The widget will show table updates, signature data, app names, step names, and timestamps. This is useful to have a high-level view (without process data), such as a pure review app.

#### Signed completions only

When enabled the user can only see e-signature records.

## FAQ

### How can I avoid having log-type granular data?

When a table record is loaded into an input field and as the user logs into the input field, a very granular log type data is produced within the same entry. This can cause many “entries” within the record history, and could potentially make the review process more difficult. **Using table records as the datasource for input fields is not the best practice, especially for GxP customers.** Alternatively, the input field can be linked to a variable which is then saved into the completion record by the **Save all app data** step.

### Why is it important to be cautious of the Table Field Name Filter when using a static value?

The record history widget will use the current name of the field to filter the data. If the user changes the table field name, and the filter still uses the old field name, this can cause inconsistencies in data review. Alternatively, the table record could be used as a filter.

### How to solve “Missing completion data during Step X”?

This can happen when users are not completing the app each time they act on a table record, meaning the users are handling several records in a single completion, or the table record placeholder has **Don’t save for analysis** checked.

**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.**

**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.

**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.

**Automation**

**Workflow** that performs tasks in the background, without an interface. Automations run logic every time an **event** occurs.

![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Glossary/Automations1.gif)

**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.

**Step**

A view your users will see within an application. **Steps** can be viewed chronologically or in whatever order best fits your process.

Steps can be grouped into **Step Groups**to manage and organize your app Steps.

**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.

**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.

**App Editor**

The web interface used for building applications. Where you design a user interface, add logic, and connect your applications to **Tables**. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Screen%20Shot%202022-09-13%20at%207.50.23%20AM.png)

**Side Pane** **(Context Pane)**

The**Side Pane**is the configuration pane on the right side of the **App Editor**where steps, apps, and widgets can be configured. **Triggers**can be added to adjust widget behavior.![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Context%20Pane.png)

**Tulip Player**

**Tulip Player** is the Windows/Mac executable program where users can run Tulip apps. Tulip player allows you to create a more seamless user experience by removing the need for a web browser and allows increased IT controls.

**App Info**

**App Info**is a subset of the data available within an application automatically. This data can be used both in **Widgets**and**Triggers.**This includes the current date and time, the app name, the app version, the current shift, and more.