Technisch gesehen gibt es keinen Unterschied zwischen den Referenztypen. Jeder von ihnen kann Report Revisions aufnehmen. Die Unterscheidungen sind demnach logischer Natur, um den Reportbaum nach den Bedürfnissen der Entwickler und Entwicklerinnen zu strukturieren.
Die Zusammenhänge zwischen den Referenztypen lassen sich konfigurieren, indem festgelegt wird, was für Parents und Children ein Reference Type haben kann. Sind diese Zusammenhänge definiert, lässt sich der Reportbaum einigermassen gut aufbauen und warten.
Folgende Abbildung zeigt die Konfiguration für den Reference Type des Reports. Daraus lässt sich schliessen, wie sich ein Report in die Baumstruktur einfügen lässt.
Die obige Abbildung zeigt den aktuellen Stand am 17.11.2023 und damit verbundene Probleme, denn eigentlich lässt sich fast jedes Objekt im Reports Tree als ein Child oder ein Parent nutzen. Dies erschwert die Orientierung und auch den Unterhalt der Reports.
Eine geeignetere Konfiguration zeigt die folgende Abbildung. Gemäss dieser liegt ein Report in einem Report Folder und kann selbst keine Unterobjekte aufweisen.
In der Vergangenheit wurde es versäumt, diese Konfiguration sachgemäss einzurichten, weshalb es an etlichen Stellen im Reports Tree unpassende Konstrukte gibt. Diese lassen sich aber nicht einfach durch ein Anpassen der Konfiguration aufheben. Wird das versucht, erscheint eine Fehlermeldung in der Art der folgenden Abbildung.
Es benötigt daher ein bisschen Aufwand, den derzeitigen Reports Tree in eine übersichtlichere Form zu bringen. Dazu gehört auch das Verschieben von Objekten im Reportbaum, was Auswirkungen auf Verknüpfungen im System haben kann, die nicht sofort ersichtlich sind, aber dazu führen können, dass Abläufe nicht mehr funktionieren.
Die Bereinigung des Report Trees erfolgt nach und nach. Für neue Reports ist wichtig, dass man sich an die Vorgaben in dieser Beschreibung hält.