Increased Metadata fields in Tulip Table

Currently, there are 2 metadata fields exposed when toggling the ‘View Metadata Fields’ toggle button in a Tulip Table ellipsis option. Requesting to add the following as metadata fields:


  • App Name Created
  • App Version Created
  • Station Created
  • User Created

Optional Extras:

  • Step Name Created
  • Step Group Name Created
  • App Name Updated
  • App Version Updated
  • Station Updated
  • User Updated
  • User’s Name (string type)
  • Station’s Name (string type)

For all of our production Tulip Tables, we need to add all of these columns to each table and add triggers to write to each of those columns. I’d imagine there is a large need for this type of data and many Tulip customers are adding these columns manually. I also think these are critical properties of a table record that should be exposed for use without manually having to track this.

and please, make all settings persistent.

When viewing the metadata, then until disabling. For the other options yet.
Store and reuse the current sorting settings

Regards Chris

@ChrisF But then you need a reset button as well (for untangeling after bug fixing :smiley: )

@iamwout How would you realize a App /Station / User … - created/updated field? You would need to display it for every single cell, because it is not always a complete record set at once…

A Table with a 1000 records and 12 columns would have 144000 additional values, when realizing all of your suggestions… would that really help?

Don’t get me wrong, I like the idea behind this.
But maybe it could be solved with some kind of interactive history log or so…

Hi Thorsten,

I think you misunderstood my request. I’m simply asking for a metadata column similar to the Date Created and Date Updated columns currently exposed for each Tulip Table for each of the following:

  • User
  • Station
  • App Name
  • App Version
  • Etc as mentioned in original post

See below and attached example:




Increased Metadata fields in Tulip Table.pptx (326 KB)

Yes I got, that you had this in mind.

But I can’t see the big advantage in that, as long as I don’t know what columns came from this source.
Column A can come from App1, column B from a machineX, column C from an API input (source unknown?!), column D from an Automation and column E from App2.

So when there is any change the metadata will tell the time (already) and the source (suggested).
That is for sure possible (but more complex then your suggestion because of the amount of possible sources). The real deal to me would be to know what the sources target was :slight_smile: Thats why I thought about a history log…