Side by side record comparison

[KoenJanssensPD]

Dear,

In a model-driven app, how can I have 2 (identical) forms of 2 (different) records of the same table  side by side?

Ideally, I would also like to highlight differences between the two records in the forms...

Any idea?

Thanks,

Koen

[a33ik]

Hello,

I'm afraid there is no oob way and you will have to develop it and it could be whatever - report/HtmlJS webresource/PCF.

[cchannon]

Is this for de-duplication of data? If so, then yes, records that have been flagged as potential duplicates (see your Duplicate Detection Rules) can be opened side-by-side, with differences visible so you can merge these records as appropriate.

[KoenJanssensPD]

To give some background: records are created by reading from an external source. Whenever a new record is created from the external source, a copy of that record is created to be used internally. Now, if the "external" record is being updated from the external source, the "internal" record is not up to date with the external record.

I need a way to be able to show the user the difference between the "external" record and its "internal" copy, so the user can decide whether or not the external change should be reflected in the internal record...

(maybe this way of working is not the cleanest, but I could not find another way)

[a33ik]

@KoenJanssensPD, as I mentioned - you can develop it. On a side note - I started the youtube show "You asked, I built" where I build different stuff. And your scenario looks like a perfect candidate for the show. I believe I will work on it over the weekend so if you're interested - subscribe and wait for the next episode.

@cchannon, that is a brilliant idea I haven't thought of that would definitely work for account/contact/lead. Would it work for the custom entity?

[cchannon]

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.

[DianaBirkelbach]

Hi @KoenJanssensPD , 

In case the entities are linked by a lookup (which I suppose, otherwise could be hard to  keep track of the internal and external record), maybe a Quick-View Form or the FCC (Form Component Control) can help to integrate a form on the other one, by using standard customizing. Then you have both forms shown on the same screen.

Hope this helps!

Kind regards,

Diana

[KoenJanssensPD]

Hi @DianaBirkelbach , I have been trying the FCC as you suggested.

I am a bit confused when I read the docs, the example uses "<QuickForms>" as the url to the form, but the limitations indicate it can only use main forms ("quick forms are not supported")... ?

As you said, both (external and internal) records are linked...

I guess I can use the same method with the FCC to show both the external record and the internal record?

[KoenJanssensPD]

So it seems I can show the (same) form for the related (external) record on the form of the (internal) record. Now I am trying to find a way to have two FCCs on the (internal record form) with the forms of both records... However, I cannot find how I can use the current record ID to be used as the lookup value for the FCC?

[DianaBirkelbach]

Hi @KoenJanssensPD , 

Basically I mean using the "internal" record form as a basement, and show there also the form of the "external" record  using a control (if the lookup is bound that way). So for the "internal" record you don't need to use a form component, since you are already inside the form itself.
And for the "external" record you could use (via lookup):

- As Quick View Form control: I mean the possibility to show a special form of the linked entity, like this: https://docs.microsoft.com/en-us/powerapps/maker/model-driven-apps/quick-view-control-properties-leg.... The advantage of the quick-view-form is that it is read-only by design. I suppose you would like to have the "external" record read-only.

- The other possiblity is the Form Component Control (FCC) like in the link you already found: https://docs.microsoft.com/en-us/powerapps/maker/model-driven-apps/form-component-control?WT.mc_id=B.... In this case, the user will be able to edit the "external" record too. But if you prefer this solution and want it read only, you can still use form scripting on the "external" form and disable all controls.

Hope this helps!

Kind regards,

Diana