Three questions! Feel free to split them up into separate posts next time to share the internet points around 🤣
Dates:
I created a date field which, using an expression defaults to "return now()". This is great, but I have found if I create a entry in FieldMaps then later edit the entry, the date is updated to reflect when it was edited. The date field really wants to be locked to the "Created" date not the edited date.
Is there a way to do this?
$originalFeature and $editcontext.editType
You should be able to refer to the previous state of the feature being calculated if the edit context is an update, otherwise if it's an insert (new), calculate the date.
I haven't done it but it seems possible and cleaner than relevant fields + preserving values, or splitting adds/edits into two layers.
https://www.esri.com/arcgis-blog/products/arcgis-pro/data-management/originalfeature-new-attribute-r...
Coordinate System:
The phone in my GPS is giving x and y with Lat/Lon - is there a way to include fields for other co-ordinate systems? Like here in New Zealand NZTM is very common.
Arcade geometry functions get the coordinates of the basemap. So you can create a custom basemap in the desired coordinate system and call that. Otherwise not directly, but some users have shared Arcade snippets to insert projection calculations from the Esri basemaps to others. I'd only recommend that for The simple WGS84 ones.
Fields:
If when I am designing the form in AGOL, and lets say I add a drop down for a field called "Codes" - but then delete the dropdown and use a Radio button - I then can't add a radio selector called "Codes" because there is already a field in the table called "Codes".
It appears removing the input element, doesn't remove the corresponding field from the table, while I can then go and edit the table, doing it this way seems like a clunky design process.
Maybe there is a way to add a input element, and connect it to a existing field in the table?
This is expected behaviour. Forms are built on top of the table/schema. Previously Collector 'drop-downs' existed only if you had a choice list / domain / codes on the field itself.
Users requested Field Maps have greater ease of access to adding values and fields directly to the layer through the form designer. We've seen some of this come across. But otherwise removing values or questions won't update your table - which is reasonably desired behaviour. Otherwise removing a question could delete an entire column of data, when maybe you just don't want the field in your form.
It's similar to ArcGIS Pro and other application interactions. It's on us as professionals to know what changes will be superficial/cosmetic, and what changes will update values or the schema of our database.
I'd recommend starting with your desired schema first and then aligning your form to it.
