App/App Group Based Table Structure Visual Diagram

Hello @Geoff.Winkley / Team,

I think it would be quite useful if within the App Editor for an individual app or even at the app group level, in the Records tab (or somewhere similar) the user could ‘View Table Structure’ and be show a visual of tables used within the app (or app group) and how they link to each other (see attached example).

Currently: In order to view the full table structure the database has to be reconstructed in tools like for the initial table design then exported to Figma to finish cleaning up the diagram and designate ‘Pre-Loaded’ tables vs Process Tables.

This feature would be extremely useful in multiple scenarios:

  1. The developer who built the app leaves the company and new support for the app is required
  2. Using the app table structure for Validation documentation (it’s important to note the difference from Pre-Loaded (reference tables) and process tables (get filled in as the apps execute). Reference table need to be repopulated as the app migrates instances so it requires extra effort to recheck the upload was successful.

BD Kiestra Tulip Table Structure.pdf (1.4 MB)

Current Version: LTS 11.1

Really cool to see that example Relationship Diagram, Alec. Thanks for sharing.

While I agree tools like this are super critical to support sustainment of production applications, I don’t see how Tulip would be able to get close to this while linked records remains a relatively limited piece of functionality. At best, Tulip will be able to output a list of tables, but Tulip tables fundamentally don’t have relationships and it would be very difficult for the Tulip team to imply relationships based on trigger logic.

I think it is more feasible to imagine Tulip visualizing/exporting the “flow” of applications from step to step, app to app, and completion points. Separately, being able to extract which pieces of a tulip app interact with which table columns (create, read, write, or delete) would go along way towards easier documentation-- or maybe even enabling the community to build parsing tools to make documentation easier.

This is a big concern of mine for the future of the Tulip platform. Production applications trend towards complex, and without manually creating documentation like you are creating, this can get out of hand real quick.