Export & Import Overview

What is Asset Modularity?

Asset modularity refers to the capability of transferring assets between Tulip accounts or instances. This functionality is crucial for regulated industries, customers with global Tulip deployments, and more.

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

Where Does Tulip Leverage Asset Modularity?

Typically, we consider asset modularity in the context of app export and import, but this functionality is utilized throughout the product.

The Tulip Library, Enterprise App Exchange, and App Export & Import are the most prominent areas where this functionality is exercised. Some assets, such as connectors, can be moved independently of an application or automation.

Fundamentals

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.

This documentation aims to define the expected behavior of each dependency of a Tulip application, as well as any actions required after an 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.

Export

What is in use?

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

Import

During import, the goal is to avoid duplicating dependencies if the asset already exists in the importing site. Instead, the existing asset in the target site is used, provided that the asset in both the source and target sites are functionally identical.

This raises two fundamental questions that must be answered for each asset:

What is the same?

When an asset is imported, we check if it already exists in the target instance. The rules defining equality vary depending on the asset.

Consider the following scenario:

1. Connector A with Function A is exported and then imported into Site 2.
2. Connector A, Function A is modified to add another input.
3. Connector A is exported again and imported into Site 2.
   1. Is Connector A the same? Yes, no behavior-changing modifications were made to the connector.
   2. Is Function A the same as when it was last imported? No, it has a new input, so a new function must be created.

What to do if a same thing is found?

If a match is found, the next question is what to do. As a core principle, Tulip always respects the configuration of the target instance (importer) over the source instance (exporter).

App Import Flow

Further Reading

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

• Import Export - Connecting the Wires
• Table Import Export
• Connector & Connector Function Import