Dear Tulip Team and Community,
I would like to propose a valuable enhancement to Tulip Analysis: the ability to use Connector data as a data source.
Currently, Tulip Analysis supports Tulip Tables, App Completion data, and Machine data. However, as Tulip applications continue to scale and integrate with a growing number of external systems, the need to analyze external data alongside native Tulip data is becoming increasingly critical.
Enabling Connector data as a source for Tulip Analysis would:
- Allow seamless integration of external system data into analytics workflows
- Reduce dependency on third-party tools like Power BI or Tableau
- Empower developers and end users to build more insightful, real-time dashboards directly within Tulip
- Enhance the overall value and usability of Tulip’s native analytics capabilities
This feature would significantly improve the flexibility and power of Tulip Analysis, making it a more central and efficient tool for data-driven decision-making within the platform.
I encourage the community to support this suggestion by upvoting, and I look forward to hearing your thoughts.
Hi @sagar007 Thank you for reflagging this suggestion.
Integrating Connector/third-party data directly into Analytics has a number of considerations about load, performance, and real-time behavior. At the moment, we’re prioritizing performance of native Tulip data sources, which includes best practices for integrating and surfacing external data.
What kind of third-party data are you hoping to integrate into Analytics this way, and what limitations are you running into when piping them into Tulip Tables? We’d love to find out more about your use case here and see if we can share our vision and help with best practices around the data architecture.
1 Like
Hi @OlgaStroilova ,
Thank you for your detailed response and for addressing the considerations around performance and real-time behavior.
To share our real-world scenario:
We are working with a client where production and transactional data resides in PostgreSQL, and this data is exposed through MuleSoft APIs. These APIs are integrated into Tulip via Connector Functions because the client has a strict policy not to store sensitive or production data in Tulip Tables due to compliance and governance requirements.
Current limitation:
-
Analytics gap: Tulip Analysis cannot directly consume Connector data, which prevents us from building real-time dashboards without duplicating data into Tulip Tables.
-
Data duplication & overhead: Syncing large volumes of ERP/MES data into Tulip Tables adds complexity and maintenance effort.
-
Latency: For real-time decision-making, relying on periodic updates to Tulip Tables does not meet responsiveness requirements.
Why direct Connector integration matters:
-
Enables analytics without violating client data governance policies.
-
Provides real-time insights without redundant data sync.
-
Reduces dependency on external BI tools like Power BI or Tableau, keeping analytics within Tulip.
If there are best practices or architectural patterns you recommend for achieving similar outcomes today, we’d love to explore them. This enhancement would significantly improve flexibility for customers with strict compliance requirements.
Looking forward to your thoughts.
Best regards,
Sagar
Thanks Sagar for the additional detail. Have you already discussed this use case with your Partner Success Manager to unblock the specific build you’re doing right now?
In the short term, as you note, Tulip Analytics is not intended for visualizing off-platform data in real-time, so a 3rd party could be useful for visualizing data you are not planning to bring in to Tulip.
We are considering broader Analytics investment in the longer term, but we don’t have a timeline or scope for this yet.