---
title: "Process data corrections and review"
slug: "process-data-corrections-and-review"
updated: 2025-09-16T16:48:58Z
published: 2025-09-16T16:48:58Z
---

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

# Process data corrections and review

*This article discusses a current best practice on logging corrections on a batch.*

Process data logged via Completion Records is immutable, but you can add a correction by creating a "note" as a new data entry on top of the original record.

To update the same record (including add new requirements), see [Record history widgets](/r230/docs/record-history-widgets).

## Summary

- Use a common **Submit Correction** step to capture a reason code and/or comments.
- Use an **On Step Exit** Trigger to store the process’s current step in a **Previous Step** Variable or Table Field where **Is Correction** is currently **False**.
- Use an **Is Correction** Boolean variable and set the default vaule to **Yes** when navigating to a **Submit Correction** Step. This will aid visibility in eBR review apps.
- Upon submitting the **Submit Correction** information, navigate the user back to the previous step (as saved in a Variable or Table Field).
- In the **Previous Step**, the operator will then enter new information and proceed to the next step.

## Walkthrough solution

It's crucial to make this feature robust to [Pause and Resume Functionality](/r230/docs/pause-and-resume-functionality).

1. In the **Batches** table, add a text field to store the previous process step completed. Name this field **Previous Process Step**.
2. In your app's Base Layout, build an **On Step Exit** Step Level Triggers like the following: ![Robustness to App Cancellations - App Base Layout - On Step Exit Trigger v2.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Robustness%20to%20App%20Cancellations%20-%20App%20Base%20Layout%20-%20On%20Step%20Exit%20Trigger%20v2.png)
3. In the app, create a step named **Submit Correction Context** that includes:

- Input Widget(s) to capture context like a correction reason code via a single select input and/or Correction Comments via a text input.
- A **Previous** or **Cancel** button that allows an Operator to back out of this step.

![Robustness to App Cancellations - App - Submit Correction Context Step 2.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Robustness%20to%20App%20Cancellations%20-%20App%20-%20Submit%20Correction%20Context%20Step%202.png)

1. Create a **Submit** button and configure it with the follow trigger logic:

- Action: Data Manipulation -> Store -> Static Value -> "yes" -> Boolean variable called **Is Correction**
- Action: App -> Save All App Data
- Transition: Go to Step by Name -> Table Record / Batch / Previous Process Step

![Robustness to App Cancellations - App - Submit Correction Context - Submit Button Trigger.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Robustness%20to%20App%20Cancellations%20-%20App%20-%20Submit%20Correction%20Context%20-%20Submit%20Button%20Trigger.png)

1. In the previous step from the **Submit Correction Context** step, create a **Next** button that has the following trigger logic:

- Action: Data Manipulation -> Clear -> (each variable used in this step)
  - NOTE: Variables that are present on this step are not needed for calculation in a subsequent step. This method will declutter the Record History Widget viewed in apps like an eBR Review or eDHR Review.
- Action: Data Manipulation -> Store -> Static Value -> Boolean -> No -> **Is Correction**
- Action: Data Manipulation -> Clear -> (each variable used in the **Submit Correction Context** step)
- Action: App -> Save All App Data
- Transition: Go to Step -> Next

![Robustness to App Cancellations - App - Process Steps - Next button Trigger logic.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Robustness%20to%20App%20Cancellations%20-%20App%20-%20Process%20Steps%20-%20Next%20button%20Trigger%20logic.png)

When reviewing the batch in the Digital Record History Widget, sorting by oldest to newest and filtering by app step name will show the follwing:

- Logged process data for a process step with the value for **Is Correction** being "No", with various variables and values ![image.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/image%28409%29.png)
- Logged process data for the same process step but with the value for **Is Correction** being "Yes" and new variable values
- Any context from the **Submit Correction Context** step (e.g. a correction reason code) ![image.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/image%28410%29.png)

          NOTE

          

You do not need to filter the Record History Widget by the step with the correction. Without that filter, the reviewer will see the full history of the Batch.

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

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

**Table Record Fields**are single columns within a **Tulip Table.**

![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Table%20Record%20Field(1).gif)

**Boolean**

**Boolean's**are a Tulip Datatype. Booleans can have True/False (Yes/No) values.

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

**Base Layout**

The **Base Layout** is the base template that all other **S****teps** will be built on top of. Establishing common navigation buttons, and a consistent app background and style across all of your app steps can expedite the training and app-building processes. ![](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Intro%20to%20the%20Tulip%20App%20Editor_511473104%201.png)

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

**Input Widget**

**Input widgets**are a set of **Widgets**specifically designed for users to enter information. Input widgets must be associated with a location where the user input is stored.

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