Export & Import

Prev Next
This content is currently unavailable in Ja - 日本語. You are viewing the default (English) version.

This guide will show you how to move content between Tulip instances or workspaces.

Who can use this feature

Users on Enterprise plans and above.

Many Tulip customers choose to utilize multiple Workspaces or Instances within their overall Tulip deployment. The two most common reasons for this are:

  1. Management of multiple plants
  2. Using dev, test and prod instances for app development within one plant

Because of this, they require a way to move content throughout their Tulip deployment. Tulip offers five overall ways to move content:

  1. App Import/Export: Move apps and all of their dependencies together
  2. Automations Import/Export: Move automations and their dependencies together
  3. Table Record Import/Export: Move table records from one table to another
  4. Connector Import/Export: Export connectors individually
  5. Enterprise App Exchange: A formal way to allow citizen developers to import the latest version of agreed-upon app standards.

This article will focus on points 1 and 2.

Transferring content between sites allows the work done by one site to be shared across all sites, reducing the time required to deliver value with Tulip.

Fundamentals of Import/Export

Applications and automations do not operate in isolation; they rely on various supporting assets.

An automation may depend on a connector, or an app may rely on a machine. These supporting components are known as dependencies.

When an application is exported, its dependencies are collected and exported along with it. However, not all dependencies are included in the export.

Dependencies

Generally, dependencies are any components that can be shared across applications or automations and can be explicitly referenced in an application or automation. These include:

  • Connectors
  • Machines
  • Users
  • Analytics
  • Tables
  • Etc.

image.png

Exporting Rules

Before export, it is essential to evaluate which assets are being used in an application or automation and should be exported along with it. There are complex rules governing whether certain assets are exported with an application.

Importing Rules

During import, the goal is to avoid duplicating dependencies if the asset already exists in the importing site.

Automations Import/Export

There is only one way to export an automation: from the overview page of the individual automation.

image.png

You can import an automation from the top of the Automations home page:
image.png

Methods for App Export

This section will detail the different ways to select apps and app versions before moving them throughout your Tulip deployment

Single App Export

This allows you to export the development version of a single app. You can access this from the top of the App Overview page:

image.png

App Version Export

You can export a single published version of an app from the Versions tab of that app:
image.png

App Group Export

You can export an entire app group at once from the app group overview page:
image.png

Methods for App Import

This section will detail the different methods for moving content around your Tulip deployment, and the pros/cons of each one.

Each import method can be accessed from the same place as the corresponding app export above.

App Import

This is the most common method for moving apps. The rules are described in the articles in this section of the knowledge base. This will create an entirely new app, with only a development version.

App Group Import

This method of moving apps has the same rules as the one above. The main differences are the following:

  1. If apps are imported in a group and there are analytics that reference multiple apps in the group, those analytics will continue to successfully reference all apps in the group.
  2. If apps have transitions to other apps in the group, those transitions will still successfully function within trigger logic on import.

App Version Import

This allows you to overwrite the development version of an existing app, which preserves the version history of that app and all stations assignments. The previous development version will be saved as a snapshot within that app.

The following elements from the new development version will be successfully linked to past app versions:

  1. Variables
  2. Record Placeholders
  3. Esignatures
  4. Step Groups
  5. Steps

Summary Diagram

This diagram summarizes the section above.

image.png

Further reading

The following documents provide detailed information on how each asset is handled during export and import: