FR
It would be really helpful to be able to do basic parameter transformations in OMA, particularly concat (with custom separators), cast (e.g. timestamp to string) and basic numeric transforms (like in the new derived properties feature in Workshop).
Use case
Creating a unique title for an object, based on other properties, for example: “Ben Jones - Working - 21 Jul 25 until 23 Jul 25”.
Problem today
At the moment, it’s necessary to create a function-backed variable or complex input widget → inline action form in Workshop; having parameter transformations would be huge!
Hi @SeawardDread there is a beta feature called derived properties, that will allow you to do what you are describing. It is currently in an early state and the transformations you can do are still a bit limited (simple math and object set aggregation - no string concatenation). But it will be very powerful once fully available!
Note: I am not sure if it is possible to create a derived property that is used as a property in a link-type. But it might be interesting to test this out
Note 2: We explored it a bit and you feel a difference in performance (since it is on-the-fly calculation). So I would still consider, wherever you can prepare properties in back-end the better
+1 to this FR, particularly on the derived properties bit.
In particular, date-math would be ideal. There are situations where I’d like to compute a date_diff on object properties. In particular, say an object has a ‘due_date’ - I’d like to compute date_diff (‘due_date’, today) to derive a ‘days late’ property
As you mention @Phil-M, derived properties in it’s current form won’t help here.
The concat, cast and date/timestamp transforms mentioned by @OntologyOncologist aren’t available.
Derived properties only work on existing objects? For create object actions I would still need to rebuild the Action form using Workshop Widgets or use a function-backed action, which is time-consuming for a simple action form parameter concat; hence, this would defo need to be an OMA capability imo!
@Phil-M derived properties are currently only set in OSDK or in individual workshop modules, and involve either local computation in the front-end (OSDK) or a functions runtime (Workshop). It would be great to be able to define a derived property in OMA that is usable everywhere the object is used in a way that does not have either of those computation limitations. Conditional formatting is a small variant of that; the string concatenation that @SeawardDread mentioned is another. A third could be inherited properties from linked objects. Properties like this are conceptually pretty simple but currently are a pain to define (either function-backed properties as @SeawardDread mentioned, or pipeline-derived properties). OMA making this stuff easy would be a major quality-of-life improvement!
I see! And I like the direction this is going :). @SeawardDread and @pwest-northslope is your expectation/need that the properties are really calculated on-the-fly (like derived properties) or are you rather looking for a no-code way (a-like variable variable transformation/derived properties) to configure property transformations on create/edit action types?
I am just thinking from a cost perspective anything we want to calculate on-the-fly with the foundryghini will cost us that price
For me it would be a start if I would not need to create a custom ts function to back my create action type - only to strconcat the primary key
But rather have a first class no-code option for that in OMA → action type → form property configuration
I have seen a demo from Palantir PD recently where exactly this is possible. You can define derived properties in OMA as well as use inherited properties from linked objects.
This allows building truly normalised data models and avoids data duplication.
Not sure, when this would reach our stacks but it’s definitely coming soon.
For things like title formation from property concatenation or property inheritance from linked objects, on-the-fly isn’t necessary (or maybe even desirable).
For things like @OntologyOncologist’s date math relative to today, that probably would need to be on-the-fly.
anything we want to calculate on-the-fly with the foundryghini will cost us that price 
