App Versions

An App Version is a saved state of an app that will use the same logic and visuals every time it is run in the Tulip Player.

There are three types of versions:

  1. Development Version: This cannot be run in the Tulip Player. It is a test version of the app that is meant for testing logic and visuals that have been created in the App Editor.
  2. Published Version: This is an immutable, saved state of the app that can be used by a device running the Tulip Player. These can be “restored” to the development version at any time, which will replace all content in the development version.
  3. Snapshot: This cannot be run in the Tulip Player. It is meant for app builders that want to store a version of the app outside of the versioning system that they may want to return to later.

An App Version must be approved using a series of App Approvals before it can be published and released to the Tulip Player.

An App Version can have five states:

  1. Development: Described above. Cannot be used in the Tulip Player.
  2. Published pending approval: Published by the app builder, but has not received a review from an approver within every App Approval yet
  3. Published: Approved by at least one approver in every App Approval and can be run in the Tulip Player
  4. Rejected: At least one approver has rejected the version and it cannot be used in the Player
  5. Approval request cancelled: sAn app builder realized a mistake and canceled the request for approval.

It contains the following Models:

The following Models can be changed and will automatically update within published versions. This means that they can impact published versions from outside of the app publishing system.

The following Models are versioned alongside the app version, and therefore that means that they cannot impact published versions if they are changed:


Name Description
Version Number A number that automatically increments by 1 every time a new version is published. Cannot be edited by user.
Publisher The name of the user that initiated the publishing workflow
Description An optional description fields for details about the version
Publish Time The timestamp that the publishing workflow was completed and the version was released
Completion List This can be seen on the App Completions Page. A list of all completions related to the version
App Triggers Triggers that can be fired upon the following events:
  • App Started
  • App Completed
  • App Cancelled
  • App Resolution The default size of all steps in that app version. Can be overridden at the step level. Variable List A list of all variables, their default values and the steps that reference these variables Process Cycle Time An expected time to complete the app. Can be either set manually or automatically sum all step cycle times


    QA-T327Apps Page : 05 - App Versions


    15Provide ability to apply status to managed content. E.g. Development, In Review, Released, Published, etc.
    16Manage the release to use of content based on approval status.
    49Provide a managed way to configure and maintain content including creating, copying, editing, making obsolete, and deleting.
    50Disallow deletion of content that have been used in execution of a work order or material processing.
    53All content must have configurable version control.
    98Ability to view current process step in the context of the executing production model.
    121Ability to define procedural sequences with relevant process information that can guide an operator through task execution.
    461Only approved content can be used for production execution activities
    806All records shall be Enduring, ie. store, managed and unalterable for the full retention period.
    827Ability to capture data during App execution and identify the data with the version of the App that was used and its status in the workflow. ie. be able to identify if data was generated during App testing, review or approved states.
    850Ability to test Apps in production execution during the development and review process.