Have you tried using non persistent objects? You could copy the whole to non persistent entities and when the claim is saved use a microflow to move the non persistent object to their persistant ones. If the non persistent objects can not be used you could also use persistent temp objects.
This is an incredibly common scenario, and there is no neat way to handle this: each solution has drawbacks. You could:
Usually, I go for option one, and this is acceptable for the customer. For my latest project, I implemented the last option: I have a master-detail workflow, where a new claim is immediately committed. You can then add information as you go, only preventing saving when the information is clearly incorrect (e.g. a negative claim amount). Then I have a status which indicates if a claim is complete and only if it is complete, it can be submitted. Fianlly, I have task entity which refers to incomplete claims and which has validation messages which need to be fixed by the user before a claim is considered complete.
I actually figured this out on my own eventually by using a Non persist-able object to store any editable values and made my own roll back. Which turns out to be very similar to what Ronald suggested. I'm still testing it but it seems to be working perfectly.
Basically every time you click edit it creates a new instance of the non persist-able, stores all the values, if you click cancel, it simply puts them back.
Rom van Arendonk
The first suggestion was my original solution, but when a claim disappeared in UAT, I fear that this solution opens up the possibility for a claim to autodelete itself if something unexpected happens and somehow that 'savedbyuser' doesn't get changed. for all I know the user might have deleted it himself, but my reaction to that was to find a new way of saving expenses and to improve my audit trails.
Thanks a lot for the answers.