--- title: "App management" slug: "app-management" updated: 2025-06-25T18:53:52Z published: 2025-06-25T18:53:52Z canonical: "support.tulip.co/app-management" --- > ## 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. # App management ## App organization Account Owners need to manage the organization of apps on their instance, including: - Creating app folders and moving apps between folders - Duplicating apps - Archiving and recovering apps - Importing and exporting apps You should organize apps into folders for both findability purposes and in cases where a group of apps share the same permissions. #### Further reading - [Add, Duplicate, Archive, Recover, or Print an App](/r230/docs/add-duplicate-archive-print-an-app) - [How To Copy/Paste Content Within Apps And Between Apps](/r230/docs/how-to-copypaste-content-within-apps-and-between-apps) ## App roles and restrictions You can set restrictions and abilities for users on individual applications. With Permissions and Approvals, you can set the specific app privileges and reviewing abilities designated to individual users. To access the Permissions and Approvals settings, select an app from the Apps page and click on the respective tabs located below the app description. ![Permissions and Approvals Tabs.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Permissions%20and%20Approvals%20Tabs.png) ### Permissions With Permissions, you can restrict editing privileges per app. This ensures that users only have editing permissions for the apps that pertain to the lines they work on. Otherwise, they’d have access to a variety of apps unnecessary for their work. Limiting permissions ensures quality control and access based on a need-to-have basis. There are four types of permissions: - **Can view** - Users can view apps and their assets, for roles such as quality assurance - **Can edit** - Users can edit apps in the App Editor, for roles such as engineers and supervisors - **Can publish** - Users can edit apps in the App Editor and publish them, for roles such as Subject Matter Experts and - **Owner** - Users can do everything and delegate permissions to users, for roles such as Administrators ### Approvals More information on versioning and approvals is available here: [Set Up Approvals for Your Apps](/r230/docs/set-up-approvals-for-your-apps) Approvals assign who is responsible for reviewing and approving apps before publication. Regulated industries may require multiple parties to review an app to ensure it meets requirements and standards for production. By default there are three types of approvals in Tulip: ![Approvals Default.png](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Approvals%20Default.png) You can set up more approvals as needed by going to the Approvals tab, located in Workspace Settings for Enterprise customers and in Account Settings for all other customers, after clicking on your user icon. ### In-app access control As another means of controlling access, you can use Fields in Tables and Step level Triggers and App Level Triggers as well. In a table, you can set up fields that designate user roles to associated Users and with those in place, set Triggers that fire only if a user has a particular role. For example, if you want only supervisors to have the ability to complete an app, create a trigger that only Completes the app if a user has the role of supervisor. For more information on updating User fields, see How To Update Fields on Individual Tulip Users and Operators From Apps. #### Further reading [Change Editing Permissions on Individual Apps](/r230/docs/change-editing-permissions-on-individual-apps) [Set Up Approvals for Your Apps](/r230/docs/set-up-approvals-for-your-apps) ## Version control You’ll often need to make changes to applications that are currently in use. With Published Versions, you can save all information and data from a previous version while working on a new version. This ensures that production won’t be impacted even as an app is revised. There are two types of app versions: ### Development version A Development Version of an app is still being worked on by app builders in the App Editor. Development versions are created using **Snapshots**. Snapshots enable you to save the app at critical points of the development process: ![Create Snapshot 1.jpg](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Create%20Snapshot%201.jpg) ![Create Snapshot 2.jpg](https://cdn.document360.io/7c6ff534-cad3-4fc8-9583-912c4016362f/Images/Documentation/Create%20Snapshot%202.jpg) To test apps in development, use Developer Mode/Test Mode. Developer Mode allows you to test an app without affecting the version in production. You can skip between Steps, view the Variables used on each step, and test functionality with all assets such as Widgets, buttons, and more. ### Published version A Published Version of an app is able to run in the Tulip Player as an official release of an application. You can have multiple published versions as you edit an app to update standards and functionalities. Because numerous versions exist, you can easily go back to a previous published version if you need to reload it. For example if you update a function in an app and later determine that the previous version was more efficient, you can easily go back to the previous one. #### Further reading [Create and Manage App Versions](/r230/docs/create-and-manage-app-versions) [Restore a Development Version of an App from a Published Version](/r230/docs/restore-a-development-version-of-an-app-from-a-published-version) [Run Applications in Production](/r230/docs/running-applications-in-production) ## Export app data When apps run in the Player, a Completion Record is created every time the app is saved or completed. Completion data captures App Info such as: - Start Time - End Time - Duration - Logged-In User - Station Name - Comments - App Version - Whether the app was canceled or completed - Connected Tulip Table names - End values of all app Variables You can export this data to CSV for use cases such as third-party data analysis, reporting, etc. #### Further reading [Export App Data to CSV](/r230/docs/how-to-export-app-data-to-csv) [How To Analyze Data From Multiple Apps](/r230/docs/how-to-analyze-data-from-multiple-apps) **Permissions** Settings for controlling which users have access to specific applications. Use permissions to ensure that only approved users are able to access published applications in production settings. **Approval** A mechanism for ensuring that applications are reviewed and approved before publication. *Approvals types* can be configured under the settings menu. Specific approvals may be applied to an application on the application homescreen. **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) **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.gif) **Published Version** The **Published** **Version** of a Tulip app is a complete version of your Application. When an app is ready to be run in production, its logic can be *frozen* by Publishing that app. One application can have multiple published versions. If a **Station** is assigned to run the Published version of an application, it will only see changes when they are published. **Development Version** The **Dev Version** of a Tulip app is the work-in-progress of your application after an app has been published. If a **Station** is assigned to run the Development version of an application, it will see live changes as they are made in the app editor. Generally, **Stations** running in production will be running the **Published Version** of an Application. **Developer Mode** **Developer Mode** is a dedicated interface to test your applications. Dev mode doesn't write to **Tables** or create **Completions** so production data isn't impacted.