I am desperately missing a way to define some global variables that can be accessed from any app and are not bound to any user or app.
Think of it as global constants.
This one here seems to be somewhat related… Global variables
@sebme, this is a great suggestion. Global data is a topic on our radar. Would you mind sharing more about your particular use-case here?
Just came across this again… I would like to store a URL as a default from which certain information can be fetched - in this case not a connector but a URL to an asset path to display PDFs.
At present I need to either maintain this in a “Settings” table from which I need to then fetch the setting via a rather cumbersome procedure or define a placeholder variable with a fixed default in each app that needs it. The later entails that I need to maintain different app versions.
Being able define a workspace global value would alleviate this.
With “rather cumbersome procedure” I mean I need to define a table placeholder and then load the setting into that placeholder with the ID being the setting I want to load. And that every time I want to get something form the settings table as there is currently also no proper way to just load e.g. the entire table as an array and then select a single value out of that list by field name in the expression editor…
[Some Variable][0].[Some Field Name]
@sebme Using a statically defined table record is very similar to the global variable mechanism you are proposing. Perhaps you will have an easier time if you utilize one row with many columns. This way you can just load the “Global Variable Record” from that table On App Start in every app. Even if it needs many columns. This would also give you access to all of the data types.
I don’t think the juice is worth the squeeze when there is a pretty solid way to do this already. The Tulip team has lots of other exciting stuff in the backlog. Also, if custom expressions ever becomes a thing (please), users could create “global variables” by just having expressions which return a dedicated value. Seems like a better long term solution.
1 Like
Honestly, at this point I would prefer if some of the core functionality would be better ironed out rather than adding more “other exciting stuff”. But I guess it really depends on where you are in the development process and how complex your apps are.
Back to the topic: I would consider creating a config table and storing settings in columns the worst workaround possible for a number of reasons. The main one is long term maintainability.
Hi @John ,
One of the use case is … A material handler in the receiving are of the warehouse receive goods agains a purchase order and also wants to print corresponding labels.
Posting Goods Receipt for a purchase order is App1.
Printing labels is different App2.
After completing GRPO App1, we want the user to transition to App2 with the GRPO number created in the first app. Without shared variables between apps this is a challenging exercise.
Any update on shared variables between apps?
Thanks.
A related idea I’ve had is to use a delimited string to pass variables from one app to another using basically a two-column table: first column is the record ID (contains whatever lookup information you need plus whatever randomness required for uniqueness), second column contains all the pass-through variables (and perhaps their labels).
On completion of App A the values (and labels) for whatever pass-through variables would get added to a delimited string and written to the table.
On start of App B, it would look up the table record (perhaps via query/aggregation for the most recent record from App A + the same user, all of which info might be contained within the record ID). Then it would break up the delimted string, perhaps into an object list, which could then be “queried” internally by the app using array functions, etc.
Since there was the question of typical use-cases… I just ran into another one: global definitions of regex match strings used to validate barcode scanner input which are expected to be identical across all apps for the specific use-case in mind.
… the original assumption had to be revised because a used material suddenly also has characters in the code… now we have to chase all apps for steps where this needs to be changed 
Maybe an app search function would be beneficial, which can search inside trigger configuration/expressions as well.
We have a similar challenge and checking if all impacted triggers are correctly updated is easier said than done. Even when you are really structured and note it all down people make mistakes. I also tried exporting the app into a json file and double check there, but the exported json format isn’t super easy to decipher (I do appreciate that the intended use case is not for double checking changes).
1 Like
hehe, yep… search the JSON, have been there as well, done that. But I am nevertheless glad that this is at least possible - although not easy 
And some more:
- Standard decimal count when rounding a number.
- Date/time formatting if a specific kind is to be used in several places.
- …