nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Questions about Smart Forms' calculated values and attribute rules

MikeSlattery

1. Will calculated values be dynamic? If the field's dependencies change will the calculation update?

2. Will calculated values be available in exports like calculated fields in layers, or will these be ephemeral like expressions?

3. Do attribute rules serve to handle this, and replace stored data based on an update? Will attribute rules operate even if a field is updated via API?

Thank you for any clarification!

Trouver plus de publications taguées avec

Accepted answers

All comments

Anonymous User

The beta will be AGO only. The capability is planned to be available in the March AGO release and planned for Enterprise 11.0 when that becomes available this summer.

LeighStarr

Wonderful! Is that in AGO or Enterprise Portal or both???

MikeSlattery

This is great news, Aaron. Thank you.

Anonymous User

@LeighStarrA beta, which includes form calculations, is about to be released via Early Adopter. You can join it and find more info here: https://earlyadopter.esri.com/key/ArcGISFieldMaps

LeighStarr

Any idea when calculated fields might be rolling out??? This would be huge for us. The other feature that would help us a lot with data integrity would be the ability to utilize contingent fields in FieldMaps!

dougbrowning

Just going to add a yes please to this. Arcade expressions are great and do a lot for us but it not being a real field is very limiting. You can't use it for relationship classes (when making dynamic keys), cannot export them, cannot query on them, etc.

For some projects we are using arcade to show it and pass it to 123, then we have a second static copy of the field that we calc at night in a python script.

Attribute expressions do sound like a great way to go. And yes we would need them client side to be useful.

I initially thought the Form Builder would use Arcade for the values of the fields not just visibility. More like 123 where I calc the value of a field, but then it is a real field. For example I am trying now to generate a guid that I can pass to 123 for a join later. The value is stored in 123 fine but it is not actually in the parent, so when I move it to SDE later I am stuck. Cannot use globalid since that changes when moving to SDE.

Of course all of this gets tricky as to when a field should recal and when it should not. For example we use PrimaryKey_Date and then pass to 123. If someone goes back and changes the date, the calc fires, and we are in trouble.

thanks for considering this

MikeSlattery

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.

Anonymous User

I can answer some of your questions. Currently there is no support for persisted calculated values in Field Maps. This is on the roadmap. There are two main approaches that can be taken: client-side expression evaluation, or server-side calculations (Attribute rules).

1. Calculated values will be dynamic regardless of where the calculation takes place (client side in the app or on the server).

2. Yes since the calculated values are persisted in the feature layer & database, if you exported the data you would see the changes.

3. Attribute rules are one way calculated fields could be accomplished but it adds quite a bit of complexity when publishing the feature service. Since attribute rules are executed on the server, regardless of how the data is changed, the rules will be enforced if data was changed via the REST API directly. We are still figuring out a path for how Field Maps will handle calculated fields. There are significant advantages to supporting a client-side expression that can be defined in the form in addition to supporting attribute rules.

What use-cases are you looking to accomplish with calculated values? Do you have a preference for an approach?

Rejoindre la conversation

Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.

Liens rapides

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.