Thank you for your reply - it helps a lot. I understand this is on the horizon. We are changing schema right now so it is important to know what our target is.
We have two scenarios off the bat. In these cases we would want a calculated field to update in storage whenever the values in fields involved in the calculation change and get committed, without manual or batched help.
1. We need to calculate an integer for a critical root zone ring as a field on a tree point based on an updatable integer field for diameter. That updated CRZ integer field needs to be stored and act like any field in terms of views and exports. (Polygon layer ring updates are another topic once this one is settled. Happy to use webhooks, etc. Excited that the storage will make such a process less fragile.)
2. We have a few instances where we use FeatureSet expressions on a field to grab the latest or max value of a given field in a related feature or table. In some places, the display is all we need as in-context data. In others, we need that value to be stored in the parent record as it updates the display. We want that value to be accessed in views without recreating expressions in each map, and we want to have an always up-to-date dataset endpoint for export.
We would need to know up front if there were any restrictions or conditions on the layer that would bar the use of calculated fields, such as tracking, syncing, etc.
The new working Field Maps FeatureSet expressions are already helping us with in-context display, so thanks team! And I really like the idea of the portable form object. This next step for us is to be able to have that endpoint for a layer that is always up to date.
Late Edit: the last scenario for these calculated fields - Ideally these would behave the same way if they were updated using Field Maps or updated via a notebook and the api.
Thanks again.
