we are very frequently stumbling across a missing functionality, which is the reset/discard user edits on object types.
Imagine, you have an object type that is backed by a backing dataset. It has a property that frequently updates via pipeline, but you want to allow users to edits that value. The underlying dataset is still frequently updating the value, but since it has an ontology edit, only that edit is valid - so far so good.
Now imagine the case, the user wants to reset that edit (discard) and let again the value be defined by the frequently-updating backing dataset value.
As per my understanding, there is actually no direct way of achieving such a discard. In situations where we can not prevent the discard case, we are implement a very effortfull workaround
This is: we store edits which potentially require reset in separate object types additionally. When the user applies an edit, we edit the main object type and create the secondary „edited property" object. With every pipeline build, we actually use again the edited property objects to set those values again in pipeline. We have to do this, so since it requires the conflict resolution of the object type to be „most recent" . This is very annoying, since it requires a latest timestamp property which updates with every build. Meaning also, the full object type indexes completely with every build, since the timestamp property updated . If you try to be cost-aware this is not helping
Not sure if I am missing something. Do others phase a similar issue?
Edit: also found this doc section stating that this functionality does not exist. Really wondering why such a functionality does not yet exist.
In Ontology Manager, have you tried switching the Conflict resolution strategy from Apply user edits to Apply most recent value? Note: I think this will only help going forward and does not apply retroactively. It might update objects after re-building the backing dataset.
I havent used this in a long time, but I think it it will always rely on a specific timestamp (maybe date?) property to identify which property to use. So you will have to create a “property_X_edited_at” property that will track the timestamp of edits to property_X. Of course if your idea is to have the user discard edits you can be “creative” here and force that property to be some timestamp in the year 2100 and then a user discard would send it back to 1970 until a new edit happens. Seems like a fun exercise to be honest
I think my point is still not fully clear. So I tried to visualize it in excel.
In many cases we build data models that combines system key figures like sales and orders with user-editable key figures. Now in some cases these user -editable key figures can be based on system data as a start. And this is the case where the struggle begins.
It is especially painful if you want to UNDO/DISCARD a user edit and let again the system value be taken (see below oven | 2026_10). The only way I found was to:
store each edit in a separated object type
join them in every pipeline build on dataset level
have built_timestamp on the dataset
use conflict resolution with using “latest build_timestamp” (<-this makes indexing painfully expensive
So I am again advocating for a 4th ontology action type class alongside Create, Edit and Delete which is the DISCARD Edit. This discard should be callable just like the edit on specific properties (not like the Delete the full object). The expected behaviour is that if there was an edit the user edit is discarded and the backing dataset value is again surfaced.
