Good evening,
I’d like more control over which assets Tulip creates when importing an app.
Before committing an import, could the importer show a list of assets it plans to create, such as functions, table queries, connectors, and custom widgets? Ideally, we could choose how to handle each asset:
-
Create: Create the asset using the existing import behavior.
-
Skip: Continue without creating that asset, where dependencies allow it.
-
Fail: Stop the import if creating that asset is required.
If skipping an asset would leave unresolved references, the importer should explain the dependency and require resolution before proceeding, even if it means choosing to leave those triggers in a broken state.
The current behavior could remain the default, with these controls available as an optional review step. It would also be useful to configure rules by asset type at the account or workspace level—for example, allowing app imports while blocking the creation of custom widgets or connectors.
Import permissions should also respect asset creation permissions. In our testing, a user could create an instance-wide custom widget through an app import despite lacking permission to create that asset directly. Permission to import an app should not automatically grant permission to create every asset bundled with it.
These controls would help prevent unexpected duplicates, reduce cleanup, and let administrators authorize imports without implicitly authorizing broader asset creation.
When we learned we could import custom widgets into our instance despite not having permission to create them normally, we thought we had found a serious backdoor! According to Import & Export , however, you are already aware of this.
Thank you for your time!