UNIFYBroker/Plus doesn't enforce managed field values during Changes Polling but does during Baseline Sync

When a lower priority incoming adapter source field value change is processed by a Changes Polling operation, higher priority field values from the target locker are not written back to the adapter entity.  When a Baseline Sync operation runs they are.  The practical outcome of this is that UNIFYBroker only enforces managed field values in downstream systems when a Baseline Sync is run.

Here's an example from a UNIFYConnect instance: MemberDNs is a multi-valued string field for managing group membership.

Incoming from Azure Cloud Groups:

Outgoing to AD Groups:

The mapping priorities in the Locker are as follows (i.e. Azure Cloud Groups is set as a higher priority mapping than AD Groups):

When the MemberDNs field of the Azure Cloud Groups entity changes (i.e. add or remove a value) that change goes through to the AD group and the AD group's membership is updated with the current values from the Azure Cloud Group and locker entity, as expected.

However, if the group membership's membership is then changed directly in AD that change then comes back as far as the adapter entity, but doesn't flow into the locker entity (and neither should it, because there are already a higher priority values mapped into the locker from the Azure Cloud Group adapter).  However, the correct values from the locker are not being written back to the adapter, which is the functionality we would like to have, so that when a change is made to a managed attribute in a downstream system UNIFYBroker/Plus will quickly revert that change and enforce the correct upstream value.

When a subsequent Baseline Sync is run on the AD Groups link the correct value from the locker is written to the adapter and the downstream system is updated to enforce the value.  This is a functional workaround, but scheduling frequent Baseline Sync operations has an operational overhead.