Ideas
Locker entities should not retain attribute values that came from joins that have been removed
After a link join is removed using the UI a locker entity retains attribute values that were previously contributed through the link. This outcome is highly undesirable, since the locker now has information that should not be there (in my case an AD samaccountname value which is misleading, since the the AD user's adapter entity join was removed in order to allow the adapter entity to rejoin to a different locker record, but now both locker records have the same samaccountname value!) There is no way to initiate removal of this out-of-date attribute data from the locker other than joining the locker to a different adapter entity (which may not be feasible) or performing a complete data reload from scratch (which is time-consuming and an outage). Running a baseline sync on the link does not fix the problem. The attribute values on the entity should be updated appropriately when the join is removed.
Customer support service by UserEcho
Hey Adrian,
Great idea - definitely need some more deterministic behaviour here.
Just so I can confirm I understand the problem correctly, you've manually removed a join between a locker entity (L1) and adapter entity (A1) and that adapter entity (A1) has now joined to another locker entity (L2). So your L1 entity now either has no join, or has picked up another join, and L2 is now joined to A1.
In the case where L1 has joined to another adapter entity (a2), I'd expect that values from that entity should override the ones already on L1. We'll have to check whether it clears values that no longer exist (so if A1 had values that A2 does not, when A2 joins to L1 and runs a baseline sync those values should be removed).
I suspect you're probably in a scenario where L1 entity has no join and so there's nothing to populate (or clear) those values off. This is a tricky one because the baseline sync on that link won't see that entity as in scope, as there's no join for it. We'll have to do a bit of thinking around this - there may be some other join scenarios where it doesn't make sense to 'remove' the values (for example, an entity changing its joined entity in a sync cycle should already have those values re-calculated). We may need to consider this as part of the baseline or changes sync, or have some kind of locker changes operation that can handle this kind of scenario, taking into account joined and mapped fields to ensure the locker entity is kept up to date.
Yes, correct.