ArcGIS Online - Append Data and maintain CreationDate and EditDate

[BrandonA_CDPH]

Core issue: I have Feature Service data downloaded as a FGDB. I need to append the data into a layer with the same schema and am looking for a way to keep the EditDate and CreationDate fields the same as when they were downloaded. Currently they are updating to the date and time the data is appended. I use these fields for other analyses, so if they change, it doesn't work.

Longer explanation: I have a Feature Service fed by an existing Survey123 Form. I have a special project that needs to use the same form (and collect some additional data), so I am trying to make a related table to store the project-specific data. The way I have figured out to do this is by creating a repeat to store the project-specific data. When I publish the form with the additional repeat, the Feature Service is rebuilt and the data is erased. So, to get around this, I found a workaround that involves downloading the data as a FDGDB, republishing the form (eliminating the existing data), then appending the data back to the rebuilt Feature Service. I think this will work for my needs. Problem is that when I do this, the EditDate and CreatedDate fields are recalculated to be the date and time the data was appended. I need to preserve the original values since I use those to filter dashboards and for other analyses. 

So, if you're read this far and aren't lost yet, any ideas on how to maintain the EditDate and CreatedDate values? Also open to other ideas for relating this separate special project data to the data in the main form, but I think I have exhausted those options.

Thank you in advance for the assistance.

[Anonymous User]

...

[BrandonA_CDPH]

Thank you for this idea. Unfrotunately, this has the same effect. The Update and Edit date for the appended data still shows when it was appended, not originally created.

[MobiusSnake · Accepted solution]

In every Survey123 form/service I make, I create a hidden question named something like "survey_date" or "capture_date".  This points to a date/time field, and in the calculation column of the XLSX I use "now()".

I began doing this because of the scenario you're describing, I sometimes had to republish surveys with updated schemas, and appending the old surveys to the new schema meant losing the creation date.

An additional benefit is that the system-maintained CreatedDate reflects when the record was created in the feature service, but the approach I use captures the time the form was opened.  If you have someone working offline and submitting multiple records at the end of the day, the system-maintained value can be off by half a day.

[BrandonA_CDPH]

Thank you.  I think this is the solution moving forward. For this form, I think I'll have to calculate a field in Pro to retain the current data, reconfigure the dashboards, then republish the data.  Little more work, but a good note for the future. Live and learn. 😬

[DarrylKlassen1]

Thanks for the idea.  This is a simple solution to  my issue.  My end user wanted to add a bunch of records to the survey results and back date them a few months.  Adding a captureDate field to my survey and populating the current data points with the Creation date and the "new" old records with the 4 month old date worked great.  A small change to the dashboard was needed, but this was a minor detail.  This was way easier than turning of Data Tracking, appending, and then turning it on again.  I will be sure to do this to all my surveys in the future from the start. 

[MobiusSnake]

I copy/paste a record from a template I have right at the top of every survey now with this, haha.  Actually, it's three lines - I also get the device user on all my surveys whether it's strict requirement or not, instead of relying on the Created By field.  I also have a Note question which checks to make sure the user's logged in and raises a big red warning text if they're not, tells them to log in and ensure they have the latest update.

[DarrylKlassen1]

This is are great points/ideas, txs.  I will keep that in mind for any future surveys that require logins.