Hi Tiago,

It is not advised to use the volatile option in tables that are part of the topology because typically primary keys and foreign keys need to be maintained to preserve alarming and trending capabilities. This ensures when an element with an alarm is restarted, that existing alarm are preserved in the alarm tree. Else this could result that an alarm gets created, the operator takes ownership, or masks the alarm, but then the element gets restarted so this means that a new alarm gets generated in a new alarm tree and the operator needs to confirm the alarm again.

Note that provisioning should not assign different IDs to existing entities. Otherwise, we get into the scenario described above, compromising trending and alarming. Furthermore, smart baseline and analytics (AI) calculations cannot work optimally if a different ID is used every time for existing entities.
Also, when different IDs get generated every time and are re-used it could result into strange behaviour as typically a table is using "naming". E.g. day 1, row "A" gets ID "1", row "B" gets ID "2", row "C" gets ID "3". If on day 2 row "A" is removed and new IDs are generated then row "B" gets ID "1", row "C" gets ID "2". If then trending is requested for row "B" it will request trending for ID "2", which means a trend graph will be shown with the trending of row "A" from day 1 and trending of row "B" from day 2.

However, the volatile option may be used in tables not part of the topology and are not alarmed nor trended, such as those for downstream frequencies. In that case, do not specify the foreignkey option, but instead create a filter that displays the (frequency) table filtered on the device id column when a device gets selected from the topology UI.

Regards,