This is related to this post:
https://thwack.solarwinds.com/discussion/151805/updated-at-does-not-get-updated-when-relating-items#latest
There is currently no change signal when items are related (or unrelated) to other items (changes, tasks, releases, incidents to other incidents, etc). Because of this, solutions that incrementally poll service desk for new items will fail to catch newly created relationships between related items, unless something ELSE changes on one of the items, which would then cause the updated_at field to increment. This applies to API-based solutions that may use incremental polling to pull info from SWSD, and it may also apply to the BI connector.
Alternatively, if there were some other change signal, like an audit log, that indicated an item being related, that could also be used, although it seems to me that updating the updated_at field would be most logical.
Currently this is hindering our ability to create accurate reporting in third-party systems that use either the BI connector or custom-coded API solutions. As an example, if we create a "Release" and then periodically relate incidents or tasks to that release, our third-party reports will never see the related items contained in the Release unless something else in the parent release items change, so it appears to our third party reporting system that their may be 3 associated incidents/tickets (for example), when in reality there may be 12. That's critical to us understanding "what is in this release" in PowerBI reports, custom CMDB's, etc.
