To find the libraries that are not used or are used only mildly, that could enable doing cleanup of the dependencies.
Open up “External” element to see what elements does it contain.
Basically those are external elements (libraries) of which code is not present in analysis. (Some of those might be also caused by errors in analysis)
If you have somewhere the full list of the libraries included in your production image, you can cross-check that list against the list of elements under External. This is where the usability is not yet in optimal level, but it is still doable already.
However, there are also sometimes corner cases: For an element that is “pulled” to the image due to arbitrary dependency (e.g. a test tool or some other “not so relevant” component uses it). Those special cases can be identified with the help of heatmap when configured to show external_incoming_dependency_count metric.
Libraries with very low external_incoming_dependency_count metric are such might be easily removable from the production deployment with relatively low work effort as there are very few users for them.
In the most recent Softagram version there is also a Page Rank based algorithm to identify indirect importance of software elements. As an alternative to external_incoming_dependency_count metric, it better shows the “real importance or connections” of an element even if it has just a few direct users (but they themselves are very important). However, that metric is still to be exposed in UI.
Note that in some rare cases, external libs might not be used directly from your code, but through another external library. Those cases can be resolved with the help of binary analysis (instead of source code analysis) that is not available in the product.