---
title: "Capture app screenshot"
slug: "capture-app-screenshot"
updated: 2025-08-12T17:41:48Z
published: 2025-08-12T17:41:48Z
canonical: "support.tulip.co/capture-app-screenshot"
---

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

# Capture app screenshot

*The Capture App Screenshot trigger allows app builders to capture a screenshot of the Player app and save it as an Image URL datatype.*

**In this article, you will learn:**

- **How to use the Capture App Screenshot Trigger**
- **Limitations and Watch-Outs for Capture App Screenshot Trigger**

---

          Availability

          

If this is not available in your instance and would like it, please reach out to your Tulip Representative.

This feature helps users capture error logs or capture records in a readable state.

In any Trigger, you can use the "Capture App Screenshot" action to generate an image of the current step view.

You can then:

- Save the image to a Variable
- Save it to a Table Record
- Include it in an email or Completion

![Screenshot 2025-03-27 at 3.47.48 PM.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Screenshot%202025-03-27%20at%203.47.48%20PM.png)

## Use cases

You can use "Capture App Screenshot" to:

1. Record error logs for improvements to troubleshooting.
2. Capture information inputted by an operator in an extremely readable manner.

## Best practices

- The Player window must be maximized when taking the screenshot to capture the best quality.
- The dimensions of the app or Step must align with the form factor of the device so that certain floating elements, such as “Show message” and “Show error” triggers, fall within the active area of the app and are captured in the screenshot.
- Use the trigger on a button widget, instead of on step enter or app start. This method helps to fully load the step and its elements, including custom widgets, as the trigger cannot detect when user-defined logic within a custom widget has loaded.
- Use the trigger sparingly and as an augmentation to other captured data. Images are hard to work with as you need sophisticated tools to process and retrieve information from Images.

## Limitations

          Version Differences

          

If you are running a Player version < 2.7.2 or Mobile Player or Browser Player, the following do not render in the screenshot:

- Images
- Custom Widgets
- Embedded documents & PDF within variables, table records and such.
- Embedded videos
- CAD widgets
- Live feed in Camera widgets

- **The resolution and quality of the image depends on the size of the Player Window.**
  - The Image will be a representation of the pixels drawn on the screen of the device. If the Player window is very small, the captured screenshot will be of poor quality. For best results, the Player window should be maximized.
- **Only contents within the active area of the app will be recorded.**
  - Extra dark blue background will not be part of the screenshot
  - If the height of the window is too large compared to the width, the “Show message” and “Show Error” triggers will not be captured in the screenshot as they would render on the bottom of the window and lie outside the active region of the app.

![Screenshot 2025-03-27 at 3.42.14 PM.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Screenshot%202025-03-27%20at%203.42.14%20PM.png)

- For best results, the size of the app or step must align with the size and orientation of the device running player and the Player window must be maximized.
- **Screenshot waits for certain assets such as images to finish loading.**
  - If there are assets that have not yet fully loaded when the trigger is executed, the trigger waits for the assets to load before capturing the screenshot.

          Warning

          

Assets within [custom widgets](/r230/docs/custom-widgets-overview) are excluded from the loading state deduction.

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

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.

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