---
title: "Pause and resume functionality"
slug: "pause-and-resume-functionality"
tags: ["GxP", "App Architecture"]
updated: 2024-02-20T14:56:31Z
published: 2024-02-20T14:56:31Z
canonical: "support.tulip.co/pause-and-resume-functionality"
---

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

# Pause and resume functionality

*Learn how to pick up where you left off in your Tulip apps.*

Batch processes may last many hours or many days. To enable an operator to pause work on a batch, and pick up where they left off at a later time consider the following solution recommendations.

**There are two fundamental things you need to do to enable this:**

1. Variables are session-based, meaning that they are, by default, refreshed between each app execution with their pre-defined default values. If you need to store a parameter or a piece of information for use in another trigger later in the process, store it in a Tulip Table before exiting the app.
2. In order to resume the App and navigate the operator to where they left off, store the App Step Name in a designated column in your Batches table. Do not store the App Step Name if the step is a modal or Common step (e.g. a step wherein an operator briefly logs a deviation). Use [‘On Step Enter’ or 'On Step Exit' triggers](/r230/docs/step-level-triggers) to save the App Info / Step Name to that designated column in your Batches table.
  - You can put such a trigger in the [Base Layout](/r230/docs/how-to-use-base-layout) / Step level, however be sure to add conditions to NOT save the step name for modal/common steps as discussed earlier.
  - Depending on your solution design, you may also need to store the App Info / App Name into its own designated column on your Batches table for use in Transitions.

When resuming the batch:

- For the scenario in which you need to use previously-stored process data from the Batches table (as discussed in 1 above) in some later Trigger (e.g. in a calculation), you can either:
  - Design those latter triggers to read the value from the table directly (e.g. a table Record Placeholder's column)
  - OR use 'Data Manipulation - Store' to save that process data back to their corresponding app variables.
- Use a Transition of 'Go to Step by Name' to return the Operator to the App Step Name stored in your Batches table (as discussed in 2 above)

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

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

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

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

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