Anders als in den meisten Automation-Objektmodellen wie z. B. dem von Microsoft Office sind die Objekte von FlexPro hierarchisch strukturiert. Hierbei werden solche Eigenschaften und Methoden, die unterschiedlichen Objekten gemeinsam sind, in einem Basisobjekt zusammengefasst. Diese Strukturierung erfolgt in mehreren Schichten vom Allgemeinen zum Speziellen hin. Die Objekthierarchie von FlexPro folgt hierbei einem leistungsfähigen Prinzip der objektorientierten Programmierung, der Vererbung. Die folgende Abbildung zeigt die Objekthierarchie des 2D-Diagramms von FlexPro.

Die Vererbung bietet eine Reihe von Vorteilen, sowohl für die Implementierung von FlexPro als auch für die Verwendung des Objektmodells von FlexPro. Bei der Implementierung von FlexPro bewirkt die Vererbung, dass die Implementierung eines Basisobjektes in allen Objekten, die auf diesem Basisobjekt aufbauen, wieder verwendet werden kann. Die Software ist hierdurch kompakter und besser wartbar. Das CursorObject auf obigem Beispiel ist z. B. Basisobjekt für das 2D-Diagramm (Diagram2D), das 3D-Diagramm (Diagram3D), das Arbeitsblatt (Worksheet) und das Dokument (Document). Eine Implementierung wird hier also für vier unterschiedliche Objekte verwendet. Je weiter man in der Objekthierarchie nach oben geht, desto größer wird diese so genannte "Code re-use". Alle Objekte, die in der FlexPro-Datenbank gespeichert werden können, sind z. B. von FpObject abgeleitet.

Auch bei der Entwicklung von Automatisierungsanwendungen, die auf das Objektmodell von FlexPro zugreifen, stellt die Objekthierarchie von FlexPro einen großen Vorteil dar. Ein Programm, dass z. B. nur die Eigenschaften und Methoden der CursorObject-Schnittstelle verwendet, läuft ohne Änderung mit allen CursorObjects von FlexPro (2D-Diagramm, 3D-Diagramm ...) und zwar auch dann noch, wenn spätere Versionen von FlexPro zusätzliche Objekte enthalten, die von CursorObject abgeleitet sind. Der zur Implementierung der Anwendung verwendete Compiler (Basic, C++, Java ...) kann dabei sehr schnellen Code erzeugen, weil alle Methoden und Eigenschaften von CursorObject schon beim Kompilieren bekannt sind. Aufrufe können also direkt in Adressen umgerechnet werden und die spätere Abarbeitung des Programms wird hierdurch sehr schnell. In Basic erzielen Sie diesen Vorteil dadurch, dass Sie die Objektvariable als vom Typ CursorObject deklarieren. Sie teilen damit dem Compiler mit, welchen Satz von Eigenschaften und Methoden er schon bei der Übersetzung des Programms als vorhanden annehmen kann.

Wenn FlexPro keine Objekthierarchie hätte, müsste eine Objektvariable, welche ein beliebiges Objekt halten soll, das Cursor unterstützt, als vom unbestimmten Typ Object deklariert werden. Ein solches Programm könnte zwar auch ohne Änderung mit neuen Objekten, die Cursor unterstützen, arbeiten. Es wird jedoch erheblich langsamer abgearbeitet. Da der Compiler beim Übersetzen des Programms die Eigenschaften und Methoden des konkreten Objektes, welches von der Objektvariable gehalten wird, nicht kennt, kann erst bei der Ausführung des Programms die Adresse, z. B. einer Methode, ermittelt werden. Hierbei wird zuerst anhand des Namens der Methode deren Index in der Schnittstelle ermittelt und dann die Methode mit einer allgemeinen Funktion Invoke aufgerufen. Alle Argumente müssen hierbei in so genannte Variants verpackt werden, da auch deren Datentypen zur Übersetzungszeit nicht bekannt waren. Ein weiterer, gravierender Nachteil dieses Verfahrens ist, dass viele Fehler, wie z. B. falscher Methodenname, falsche Argumentanzahl oder falscher Argumentdatentyp, erst zur Laufzeit des Programms erkannt werden.