Do we have any feature through which we can set value to Squidex audit fields : “created” and “lastModified”?
We intend to only provide the initial value at the onset, and thereafter let Squidex manage these as per it’s workflow.
Any inputs would be appreciated. Thanks.!
No, it is also not planned. Why do you need that?
It’s a good to have feature, and would be helpful for us to set the initial value (like in our case we require one). The general Squidex workflow for these 2 fields work just fine.
For example if we need to set back-dated values to createdon or lastmodifiedon, we can do it by adding new datetime fields, but it’s an unnecessary overhead to maintain, as Squidex does the job well out of the box. Plus we need to maintain these custom-set values, instead we could provide/set the initial values to these squidex fields, and let squidex take over from there. 
Would be a good use of the audit fields squidex provides us.
You have still not really explained the root cause. Every feature increases the complexity and this one in particular, so I need a good argument.
We are migrating a substantial amount of data from SQL to Squidex. However, during the migration process, Squidex automatically updates the createdDate and lastModified fields to reflect the migration date, causing us to lose the original timestamps. Since Squidex does not allow us to manually set these values, we are unable to retain the original creation and modification dates using its built-in audit fields.
A potential workaround is to introduce two custom datetime fields to store these values. However, this feels like an unnecessary use of database space, as we ideally want to rely on Squidex’s built-in audit fields for this purpose.
Importantly, we only need to set these audit field values once—during the migration process.
Also need to do the same thing, merging content from an external system into an existing Squidex system, and trying to figure out how to do this. Thinking I might have to migrate the data and then go into MongoDB and make changes there directly.
You cannot really do that, because collections in mongodb are just a derivation from the events. So you would have to update both, otherwise you would loose the data.
There are some operations that rely on the event datetime in th events being “correct” and in sync with the actual time, so I am not sure which implications it has. The best idea would be probably to maintain a nother timestamp field in the evcents and populate that from a header, but the priority is not that hight at the moment.
The question is also if you want to have a general solution that works for everything or something for content items only and I am not sure about that yet.