hmmm... Given the added specifics after my last post, I am less keen on my earlier suggestion, since it seems like the objective is not to deduplicate, per se, but to envision the source of record delta effects or an explanation for mismatches.
From that, I would assume that it is just as important to show a discrepancy created as a result of internal actions as it would be to show the ones created externally. Or, to put it another way, External sets it to X, Internal changes it to Y, External changes it to Z... now, in order to decide whether or not we adopt Z, we need to know that whole history; It is no longer adequate to look at the record and say "it is Y, and External is changing to Z" because we need to know that Y was set Internally and it is therefore of different intrinsic value.
Solving this is non-trivial... to say the very least. The most straightforward answer is to build a control of some kind that monitors the audit history of the record, and ensure that all transactions coming in from the External system are using a specific principal that makes them readily identifiable. Your control then can do the rendering side-by-side for any value on the entity that has been touched by more than one side of the interplay. You could do this with a PCF (not sure if you can attach to the audit history grid itself but I'd say give it a try and find out! If not you can always just make webapi calls to get the audit history) and then that PCF could use some friendly React component to surface the comparison viewer like a Fluent UI Side Panel, for example.
If building UIs isn't your bag or if the audit history makes you want to cry (it does to me), then you could also create a messaging layer that preserves some history of the record. Service Bus might be a good place for this, especially if there is an explicit expiration on when your users stop caring about where a change came from (i.e. "if the change is older than 3 months, I don't care where it came from"). In this scenario, you could use Queue Sessions, with the SessionId set as the record Id (probably as it comes in from External rather than the Guid in Internal) so you could have effectively "threads" sitting out in Service Bus for as long as you care about the history and no longer, then when you wish to view that history, you would open a listener that ONLY looks at that record's session and does not Complete the messages, but instead Abandons them to stay up on the queue. Depending on your specific requirements, this might be overkill, but if you find yourself needing to deal with multiple integrated systems this way, then this messaging layer approach might scale better than building it all to run client-side on the trainwreck that is the OOB audit history.
