UNIFYConnect update threshold/safety catch

Teams conversation between Kelly Green and Matt Davis on Teams (6/6/24):

Matthew Davis:
Hey Kelly, it definitely could be on the roadmap but it wouldn't be an insignificant feature. Aside from Bob's ticket, you're the first one asking for such a feature in the last 5 years of rolling out broker plus engagements. It would need some more unpacking, figuring out the way to let it work after being stopped etc - and would probably rely on better surfacing of syncing changes.

We're currently looking at what the future of Connect is and how it fits in the ecosystem, so I'll make sure items like this get discussed. It'll really come down to how much work it would be vs how much benefit (similar to the pending exports people want integrated)

Kelly Green:
Thanks for the reply Matt, that was pretty much what I expected. I think it would be a helpful feature to prevent unwanted mass accidental changes but as you said it would depend on how much work it would be to develop. I can relay on to DCCEEW though that it is being discussed as a possible future feature of UNIFYConnect and have it descoped from the immediate project (what I had expected and prepped the client for anyway). Thanks again :)

Matthew Davis:
There might be ways that you could implement project specific ways to limit mass updates (on links or connectors potentially), but it's hard because broker runs things through in pages. It's not like MIM where you've got a staging step and then a processing step - based on the changes coming through, we process page at a time. So we might be able to know the number of changes total, but not what those changes contain - so it'd be hard to threshold those.

Also, a link change doesn't necessarily dictate a change in the adapter/connector - so 5000 changes pending for a link may result in 0 changes outgoing on a connector depending on your configuration. Definitely not a black and white problem to solve at a product level

Kelly Green:
Also, a link change doesn't necessarily dictate a change in the adapter/connector - so 5000 changes pending for a link may result in 0 changes outgoing on a connector depending on your configuration.

Hmmm that is definitely a point of concern because I have seen mass "pending changes" that I know resulted in 0 actual changes, therefore a simple X value threshold would not be a good solution. Perhaps it would be possible if the syncs did a kind of automated pending export comparison prior to actually commencing the sync changes it would be able to weed out those syncs that don't actually result in a change. It could then stop the sync if the number was over a threshold, throw an error for MSS to alert on and also export the changes to a file for review. But that could also potentially significantly increase the length of time a sync would normally take (not necessarily a bad thing though if the increase was manageable). Definitely food for thought.

Matthew Davis:
Yeah not an impossible problem to solve, but definitely not as easy as a threshold based cancellation. Changes on the adapter may also not translate to connector changes, depending on the code in the connector (rare, but can happen). It'll need a decent amount of thought and unpacking. Especially if we want to get to the point where customers can manage the instances themselves rather than needing MSS

Kelly Green:
No worries, if its OK, I will copy this conversation text and paste it in the voice ticket so we have a record of what we discussed here.