Maintaining Editor & Creator values when republishing a feature service

Question

I've been testing and preparing for a process of republishing nearly 100 feature services in our ArcGIS Online environment. The main aim is to update the coordinate systems of our feature services to use the standard  WGS84 Web Mercator Auxiliary Sphere for all data hosted in ArcGIS Online. Currently, we have a number of projections in use, and as we prepare to migrate all our non-AGOL data to GDA2020, we want to ensure that we have nothing left that uses GDA94 to prevent shift issues occurring.

After a recent migration in AGOL hosting from US to APAC servers, we lost a lot of editor tracking information. To prevent this happening again, I've been researching how to preserve the existing Creator and Editor information when publishing feature services as a V2 layer. I couldn't find any clear documentation on how to make this happen, but have now figured it out and will detail below for others in the future.

Restrictions:

1. Currently, if you load an existing feature service into ArcGIS Pro, use the Export Features geoprocessing tool to save as a feature class, and then share the output as a new Web Layer, any Creator and Editor fields will be included with their original values but they will NOT be used for editor tracking. Once published, if you then enable editor tracking in AGOL on the new layer, it will create new fields for this purpose.

On top of this, there is no way of manually updating values in editor tracking fields. Even if you turn Editor Tracking on a feature service off, then try to edit or calculate the field in ArcGIS Pro, it will fail. The values need to be there from the beginning.

2. Also, you can't simply Export Features and use the included CreationDate and EditDate fields as they are now automatically set as High Precision fields (as indicated by the *). The Enable Editor Tracking tool will only accept Low Precision date fields, and there is no way to downgrade a field or change it in the Field Map when using Export Features.

Workaround:

Below are the steps I took to publish a new feature service using existing data in an old feature service, preserving editor tracking information and working around the high precision field limitations.

1. Add old feature service to ArcGIS Pro

2. Use "Export Features" to create a copy of the data as a feature class in a File Geodatabase with the existing CreationDate and EditDate fields renamed (I've added a 1 to the end) and new CreationDate and EditDate fields created with no source field (set as Date type).

3. Use Calculate Field geoprocessing tool to calculate your empty CreationDate and EditDate fields from the renamed fields with original values.

4. Use "Enable Editor Tracking" geoprocessing tool to register existing fields for editor tracking

5. Delete original (renamed) CreationDate and EditDate fields.

6. Publish the layer by selecting "Share as Web Layer" from the sharing menu and ensure you check the "Enable editing and allow editors to:" option and the "Preserve editor tracking info" option. You may also need to customise your Timezone settings depending on what you selected in previous step.

Now.....to figure out how to preserve the info when running the Append tool (not holding high hopes based on what I've already found elsewhere in the Community...)

LindsayRaabe_FPCWA · Answer

Thanks for sharing your experiences! The problem we are facing with the projections is not actually in ArcGIS Online (as you say, it all works nicely up there)....it's back in ArcGIS Pro.

When we add a feature service to a map in Pro, if it uses a GDA94 projection, and the map also contains GDA2020 projections, the transformations get confused and Pro introduces shifts against some of the datasets. We've been agonising with this issue for a couple of years on and off. After reaching out on here (Solved: Clarification around Transformations in ArcGIS Pro - Esri Community), we finally got the answer back that GDA94 and GDA2020 do NOT play nicely together, and that all data in a map should be either in one of the other.

Thus, we have decided to do a bulk republish and bring everything in ArcGIS Online back to the standard WGS84 Web Mercator auxillary sphere, which does play nicely with other projections.

Nick_Creedon · Answer

Preserving editor tracking has been something I have been working on in recent times, if I am just now turning editor tracking on for a hosted feature layer or exporting a hosted feature layer into ArcGIS Pro or making a new feature class and wanting to start having editor tracking on then.

If you export a layer into ArcGIS Pro (now feature class in GDB) or just create a feature class, go to the catalog and right-click the layer and go down to "Manage" here is where you can enable or verify editor tracking is on.

Once you enable you can leave this default, and it will create 4 new fields or you can set existing fields to have the editor tracking data go into, they must be the same data type***

Once you enable editor tracking you will be able to see them in the data design or if you associated editor tracking to existing fields then I believe the data design would like the same as before.

ALSO, you mentioned updating all your projections. I am very positive that ArcGIS Online projects data on the fly, you can and should keep your data in its current projection. The data should still present itself correctly.

I have written about this to someone else about Publishing data to AGOL and preserving projections.

Solved: Shapefile Export with Datum Profile set in Field M... - Esri Community

I also want to say you should check your data that has been switched to the new projection. I had existing parcel data created in my local projection and all the Shape_Area and Shape_Length fields were in sq ft and were accurate when I did Acre conversions or mile conversions. Once I changed the projection it changed my Shape_Area and Shape_Length to Meters Sq I think and all of my conversions were incorrect, so I had to republish my data in its original projection and share to AGOL.

I figure it is good to share my experience before you get too far.

LindsayRaabe_FPCWA · Answer

Won't help directly with this case, but I do have other spots that could utilise something like this (models that update polygon areas across a whole layer for example after user edits in the web). Thanks for sharing.